Meu jogo foi para capa da Google, YEAH! 2018 Lindo lindo :).

Standard

Bom, é com motivo de muita alegria que o game no qual fiz parte do desenvolvimento foi parar na capa da Google.
SIMMMMMM, está lá estampadasso.

O jogo que desenvolvi (fiz parte do core de desenvolvimento) é o Magic Master -> https://play.google.com/store/apps/details?id=air.com.mopixgames.magicmaster&hl=en

Mas como cheguei lá e como é o resultado disto?
Você pode estar se perguntando:

Como faço para meu jogo ir para capa da Google Play?

Antes de mais nada quero agradecer a Deus por ter feito parte desse  projeto chamado Magic Master.
Eu não comecei a desenvolver ele do zero, muito pelo contrário, eu entrei no projeto quando o mesmo estava em andamento e teve uma baixa no core de desenvolvimento, me levando a ser o main dev do game. A empresa na qual presto serviço até a data deste post é a MOPIX (Mopix Games) de Belo Horizonte (MG). (http://www.mopix.com.br/)

O jogo é um tower defense que foi desenvolvido por 3 anos. É um jogo que tem um design diferenciado (Raoni Dorim é o artista) + uma equipe forte de animação e etc. O jogo foi para o CoreLabs (aceleradora de nível mundial) e recebeu bastante investimento.

Vamos aos pontos do que é estar na capa do Google? Ok, vamos lá!

1 – Downloads

Parece que não é tão importante estar na capa do Google, mas é, é sim, é MUITO :).
Os downloads do game que eram algo em torno de (no máximo) 50/100 por dia passaram para 2000 ao dia. É um ganho de 1000%, isso atrai mais players e consequentemente coloca mais in-app purchases em crescimento.

ATUALIZADO O POST!!!
Neste exato momento (horas após a publicação deste post) estamos em 4000 downloads / dia e subindo! YEAHH!

2 – Portifólio

Não é simples chegar lá, a jornada é forte, mas a compensação de ser destaque ali denota o quão refinado é o processo para chegar até ali. Em Minas Gerais apenas 2 empresas conseguiram tal feito, a Mopix e outra empresa. Sem dúvidas é uma coroação que recebi sem precedentes (e jamais esperei por isso mesmo sendo formado em gamedev).

3 – O processo (como chegar lá)

Bom, estar ali é extremamente sofrido, parece que não, mas é!
Para estar ali o seu game precisa de:

  • Feedback de touch (em tudo que tem button effect),
  • Pause funcionando redondamente (e não só o pause, como o pause sob HOME/Back/Lock buttons do android [botões físicos do android]),
  • No Retorno ao game pós HOME button, Back button, Lock Button o jogo deve exibir o menu de pause (hard hein???),
  • Design de certa forma atraente,
  • Gameplay de certa forma atraente,
  • Adequar seu código ao sdk da Google mais recente possível (mínimo hoje é o 26, que corresponde ao android 8),
  • Se ele realmente precisa de sleep, deve usar Dozen da Google na API level 26,
  • Não deixe bugs no game, parece claro isso, mas lá é obrigação, bugs são requests para ontem,
  • O feedback de touch é bastante estressante de se lidar :(,
  • O sdk 26 exige muito mais dos programadores, principalmente por causa das permissions (que se dividem em permissões perigosas e permissões normais). <— cuidado!

Não é uma tarefa simples e fácil, se observar a documentação da Google é extremamente pesado.
Adequando todo seu game aos pontos acima você pode entrar em contato com o representante BR ou da América Latina da Googleplay solicitando a feature do seu jogo.

Não vou detalhar tanto os procedimentos e etc porque um post seria pequeno demais para isto.

Obrigado a todos envolvidos.

Use of uninitialized value in string ne at /usr/sbin/ddclient line 1973.

Standard

Se você está usando DEBIAN-BASED (mind/debian/ubuntu) e toda vez que roda o comando ddclient ele apresenta erro SEUS PROBLEMAS “SE ACABARAM-SE”!

Para sanar, como root faça o seguinte:

rm -rf /var/cache/ddclient/ddclient.cache

Depois rode o comando ddclient, a saída vai ser algo semelhante a:
SUCCESS:  updating SEUHOST.ALGUMACOISAg: good: IP address set to IPDASUAINTERFACEWEB

 

Abraços galera

Como exibir a pasta Library do seu Home no Mac Os X Lion

Standard

E não é que a danada da Apple sumiu com a pasta library do home user?
Essa dica é simples e vale para ambientes Mac Os X Lion (Hackintosh incluso) 10.7.x.

Existem 2 formas de exibir a pasta, só que, uma é monótona, outra já é mais hard, porém resolve de imediato.

Faça o seguinte, abra o terminal do seu Lion, conforme imagem abaixo:

abrir terminal UNIX no mac

abrir terminal UNIX no mac

Pronto, assim que o terminal for aberto digite:

chflags nohidden ~/Library

 

Pronto! Deve estar acessível a pasta Library para você sem qualquer gambiarra.

Você pode abrir pelo finder, digitando ~/Library/, mas não é mais simples remover a ocultação da pasta?

 

Abraços galera e bons estudos/trabalhos para vocês.

AppUnix (Top Unix-Like Site)

Error from park wrapper: Using nameservers with the following IPs: … Tentando adicionar domínios parkeados (estacionados)

Standard

Para cpanel pt_br, o rvskin mostra esta mensagem:

 

Error from park wrapper: Usando Servidor de Nomes com os seguintes IPs: IP_DO_DNS1,IP_DO_DNS2 Sorry, the domain is already pointed to an IP address that does not appear to use DNS servers as sociated with this server. Please transfer the domain to this servers nameservers or have your administrator add one of its nameservers to /etc/ips.remotedns and make the proper A entries on that remote nameserver.

Naaaaaaaaaaaaaada de Pânico, sanar essa parada é fácil.

Abra o whm como root e em TWEAK SETTINGS clique em DOMAINS e deixe ON a opção:

Allow Remote Domains

Depois disso você vai enviar uma caixa de bis para mim ;).

Como atualizar seu Mac Os X Lion de forma simples

Standard

Bom, pessoALL, estamos colocando esse simples artigo no ar para que possa ajudar pessoas que tem dúvidas/medo de atualizar seu Mac Os X (normalmente isso acontece com quem tem hackintosh).

Esta semana que passou publicamos um artigo sobre a estabilidade pós update do mac os x lion, você pode conferir aqui, o link mostra que não há problemas em atualizar seu hackintosh para 10.7.1 (caso esteja na 10.7.0).

Bom, este artigo vai mostrar como atualizar seu mac de forma MUITO simples.
Vamo que vamo?

Abrir updates do MAC OS X LION

Abrir updates do MAC OS X LION

Clicando no menu principal (Aquela mação linda que fica no canto esquerdo superior do seu Desktop (Apple chama o trem de mesa, pode? [lol])

Feito isto, clicando em ATUALIZAÇÃO DO SOFTWARE ele vai abrir aquela caixa de diálogo central e irá fazer busca por update.

Lembre-se de estar conectado na internet com o Mac que você quer atualizar.

Assim que terminar a busca por updates a mesma caixa de diálogo vai mostrar o que precisa ser atualizado, veja abaixo:

Mostrar Detalhes

Mostrar Detalhes

Nós do AppUnix sempre gostamos de observar DETALHES da update (a Apple não vai roubar seu pc, lol, não precisa olhar), mas, se você for cabreiro pode clicar em detalhes.
No nosso caso só tinha 1 update disponível, a qual marcamos e instalamos numa boa, vejam:

Instalar updates marcadas

Instalar updates marcadas

Assim que clicar em Instalar 1 Item (se marcar mais vai ser exibido Instalar X itens). A Aparência da instalação é simples e mostra uma barra de progresso, veja as imagens abaixo:

Progresso de instalação das updates

Progresso de instalação das updates

Agora veremos a conclusão da update, veja abaixo:

Status de completo (update)

Status de completo (update)

Antes de concluirmos nosso arti queremos lhe notificar que algumas updates críticas (de segurança) requerem o reboot da máquina, se for uma tela aparecerá mandando reiniciar o PC, reinicie sem problemas.
Veja bem, se houver erro pós reboot poderá ocorrer a tela abaixo:

erro no hack

erro no mac

Se este tipo de erro ocorrer basta um simples reboot e o sistema de inicialização vai corrigir o erro de permissões/grupos informado acima.

RESSALTAMOS que em caso de ambientes Hackintosh tome muito cuidado com updates de firmware, pois elas podem ferrar seu ambiente e tchau mac :(.

Desejamos-lhes um excelente final de semana.
Se gostar do artigo dê share, recomende, comente…

Abração galera.
Att: Portal AppUNIX

Mysql não aceita senha de root no Mac os X Lion, o que fazer? (serve para o snow leopard)

Standard

Bom, pessoal, nós do app gostaríamos de detalhar algo.
NÃO precisa ter senha de root para operar o mysql, isto dá-se em detrimento ao poder de root, porém com certas restrições que cada usuário do sistema possui.

Se eu quiser entrar no mysql para criar base de dados e trabalhar com o bd (após seguir nosso how to de instalação do apache, php, e mysql no mac os x lion ou instalação do apache, php, e mysql no mac os x snow leopard

mysql

mysql

) basta fazer o seguinte:

Mac-Pro-de-little-oak:etc little_oak$ sudo /usr/local/mysql/bin/mysql –user=little_oak

Pronto, você precisa lembrar que –user=little_oak deve ser susbsituído por –user=usuário_do_SEUMAC

Depois disso trabalhe normalmente.

Perceba uma coisa forte, o MAC OS X não precisa de root para fazer as coisas (dentro do mysql), ele já sabe que você, usando sudo É O CARA, por isso basta rodar este comando no terminal:

Little-oaks-appunixlabs: /usr/local/mysql/bin/mysql –user=little_oak

Troque o little_oak por seu usuário. Depois disso é só alegria.

Abraços galera e clique em SHARE, please!

Como instalar android 2.3 milestone 2 (passo a passo)

Standard

Tutorial Gingerbread 2.3.4 no Milestone 2 “MS2GingerBeta5 RC1” Atualizado 24/08/11

 

PARA acompanhar o artigo completo e mais atualizado sobre atualização do android milestone 2 rodando gingerbread 2.3.7 clique em ->

http://www.appunix.com.br/howto/linux/como-instalar-android-2-3-7-no-milestone-2-sem-perder-dados-e-de-forma-rapida/

Nessa versão alguns bugs foram resolvidos o principal foi o teclado físico que agora podemos utilizar as letras e números normalmente, a ROM em si esta mais rápida e estável só alguns bugs ainda continuam o principal é o problema de não podemos adicionar novas contas além do Google e do Motoblur, fora isso estou gostando muito dessa rom, vamos ao tutorial:

Temos que rootear o aparelho primeiro com o Gingerbreak  (se você já tem root em seu telefone pule esse passo) para fazer ele funcionar vá em “configurações”, “aplicativos”, “desenvolvimento” e ative a “depuração de usb” agora instale o Gingerbreak e aperte em root device após isso o celular ira reiniciar rooteado.

Agora temos que baixar os seguintes arquivos MS2GingerBeta5 RC1,sensorsMS2patchMilestone2SenorandKeyboardCWM2-bootstrap,Milestone2patchforMS2Ginger.zip e ms2patchcwm2.zip.

Agora devemos instalar no aparelho os seguintes aplicativos Clockworkmod e Droid 2 Recovery Bootstrap.

Com os arquivos baixados devemos descompactar somente o arquivo MS2GingerBeta5 RC1, passe para a pasta clockworkmod/backup (se não tiver crie as pastas) do seu cartão de memoria somente a pasta MS2GingerBeta5 RC1 que se encontra na pasta Nanodroid do arquivo MS2GingerBeta5 RC1.

Devemos também descompactar a pasta Milestone2-fixsbf esse arquivo vai ser usado mais para frente.
Agora devemos colocar na pasta clockworkmod/updates os seguintes arquivos sensorsMS2patch, Milestone2SenorandKeyboardCWM2-bootstrap, Milestone2patchforMS2Ginger.zip e ms2patchcwm2.zip, lembrando de não descompactar esses arquivos.
Agora entre no aplicativo Droid2RecoveryBootstrap e aperte Bootstrap recovery depois em permitir e por ultimo Reboot Recovery.
O celular reiniciará, agora com os botões de volumes podemos ir para cima ou para baixo nesse menu e o botão da câmera serve para dar ok, agora vamos selecionar “Backup and Restore”, depois “Restore” e selecione “MS2GingerBeta5 RC1” depois de acabar de restaurar devemos ir em “install zip from sdcard” e depois selecionar “choose zip from sdcard” e navegar até /sdcard/clockworkmod/updates/ms2patchcwm2.zip e confirma a instalação.Agora faça o mesmo caminho e escolha os arquivos Milestone2SenorandKeyboardCWM2

-bootstrap, Milestone2patchforMS2Ginger.zip e sensorsMS2patch depois aperte em “reboot”. Atenção é muito importante não esquecer de nenhum dos arquivos.Agora devemos instalar o Rsd Lite em nosso computador para colocar o fixed_sbf_newleak.SBF em seu celular.

Após selecionar arquivo por arquivo e dar “reboot” pode aparecer uma tela preta se aparecer tire a bateria e coloque novamente, ligue novamente o celular segurando o botão “Power”(o botão de ligar) e a “seta para cima” do teclado depois de entrar na tela de bootload conecte o celular no PC, agora no PC entre no Rsd Lite esperar o Windows encontrados os drives do celular e aperte em “…”  escolha o arquivo descompactado da pasta Milestone2-fixsbf ( o fixed_sbf_newleak.SBF) após isso basta apertar em “start” e esperar aparecer “finish”.

O celular irá reiniciar normalmente e funcionando, lembrando que pode demorar até 10 minutos para reiniciar o telefone.

Aproveite que esta versão esta muito funcional e a duração da bateria esta bem  melhor comparada com a “MS2GingerBeta5”.

Atualização para quem o sensor de movimento não esta funcionando temos que fazer alguns passos a mais, primeiro temos que baixar o Bootmenu v0.8.6-v2.zip e colocar na pasta clockworkmod/updates, entre no aplicativo Droid2RecoveryBootstrap e aperte Bootstrap recovery depois em permitir e por ultimo Reboot Recovery.

Na tela de boot devemos ir em “install zip from sdcard” e depois selecionar “choose zip from sdcard” e navegar até /sdcard/clockworkmod/updates/Bootmenu v0.8.6-v2.zip e confirma a instalação e aperte em reboot.

O celular irá reiniciar em uma nova tela de boot nessa tela a tecla de dar ok é o “power” selecione “boot” e depois “set default: [boot Menu]” e escolha “normal” agora aperte em “Go back” 2 vezes e depois “Recovery” e “custom recovery”.

Agora na nova tela de boot o “ok” é o botão da câmera, no menu aperte em “install zip from sdcard” e depois selecionar “choose zip from sdcard” e navegar até /sdcard/clockworkmod/updates/sensorsMS2patch e confirme a instalação após isso aperte em “reboot system now” o celular reiniciará sozinho, pode demorar um pouco mais basta esperar e curti seu celular com o sensor de movimento funcionando.

Créditos ao amigo Marcos Gonçalves

http://ajudandroid.blogspot.com/2011/08/tutorial-gingerbread-234-no-milestone-2.html?showComment=1314471600595#c3813666722992208249


Luis Fernando

Grupo Android Brasil
http://groups.google.com/group/androidbrasil?hl=pt-BR

 

Como instalar o Adobe AIR e TweetDeck mais recentes no OpenSuse 11.4

Standard

Bom, pessoal, nós do AppUnix decidimos fazer um simples How to (bem easy-to-use mesmo) para que você possa instalar facilmente o Adobe Air junto com Tweetdeck sob OpenSuse 11.4. Sobre as notas de distribuição e hardware, nada tão gritante. Antes damos um alerta para quem “viaja” demais e instala Sistemas Operacionais Linux 64 bits quando NÃO SE TEM MAIS DE 4 gb de ram. Evite isto, pois Kernel PAE dá conta do recado e reconhece os 4gb de ram sob 32 bits com MUITO louvor.

Voltando ao ponto de specs, seguem abaixo:

Notebook Testado

Acer 7745 -> i3 350M, 4gb de ram.

Opensuse 11.4 32 bits.

Vamos que vamos?

Nosso primeiro passo é instalar o pacote RPM que está disposto no site da Adobe (pacote adobe air), Para baixar DIRETAMENTE acesse o link abaixo:

http://get.adobe.com/br/air/thankyou/?installer=Adobe_AIR_2.6_for_Linux_%28.rpm%29

Isto vai cair no site já para download.

Siga os passos abaixo:

adobeair passo 1

adobeair passo 1

Primeiro passo é dizer que queremos abrir o pacote com o gestor de pacotes RPM (mostrado acima).

adobeair passo 2

adobeair passo 2

Acima vemos o download prosseguindo (mesmo escolhendo ABRIR com gestor de pacotes RPM).

adobeair passo 3

adobeair passo 3

No passo acima vemos a execução do pacote baixado. Devemos clicar em INSTALAR para prosseguir.

adobeair passo 4

adobeair passo 4

No passo acima devemos confirmar que queremos instalar o pacote.

adobeair passo 5

adobeair passo 5

Devemos confirmar com nossa senha (senha de root do seu OpenSUSE 11.4) para autorizar a instalação do pacote.

adobeair passo 6

adobeair passo 6

Acima vemos o processo de instalação do adobe air rodando normalmente.

adobeair FINAL

adobeair FINAL

Para conferir que a instalação ocorreu filé clique em COMPUTADOR -> MAIS APLICATIVOS. Deve aparecer idêntico a foto acima.

Pronto, agora que metemos bala no Adobe Air, teremos de meter pólvora  (ou POIVA -> no interiorzão) no TweetDeck. Bora? Vamos na velocidade do dragão branco?

Primeiro passo é acessar o site oficial: http://www.tweetdeck.com/

tweetdeck passo 1

tweetdeck passo 1

Devemos clicar no menu COMPUTADOR para podermos baixar a versão DESKTOP.

tweetdeck passo 2

tweetdeck passo 2

Clicando em DOWNLOAD NOW iremos ativar o bichão (download dele). Devemos fazer isto para prosseguir com a instalação.

tweetdeck passo 3

tweetdeck passo 3

Veja o carregamento do arquivo direto no site.

tweetdeck passo 4

tweetdeck passo 4

Agora devemos clicar em ABRIR para baixar e usar o Adobe Air automaticamente na abertura dos arquivos.

tweetdeck passo 5

tweetdeck passo 5

Estamos terminando o download, falta pouco.

tweetdeck passo 6

tweetdeck passo 6

Agora iremos autorizar o Adobe Air a instalar o TweetDeck.

tweetdeck passo 7

tweetdeck passo 7

Estamos acima definindo o ponto de instalação do TweetDeck. Deveremos deixar o padrão, só confirme isto.

tweetdeck passo 8

tweetdeck passo 8

Acima devemos concordar com os termos da Adobe.

tweetdeck passo 9

tweetdeck passo 9

Conforme imagem acima, devemos colocar a senha de root do OpenSuse 11.4 afim de que seja autorizada a instalação/conclusão da instalação.

tweetdeck passo 10

tweetdeck passo 10

Depois disso é só ENJOY véi!

 

Curtiu? Aplique um SHARE nisso e se lhe salvou o dia comenta aí, please!

 

4ppUn1x agradece sua visita :P.

Broadcom Corporation BCM43225 802.11b/g/n no OpenSuse 11.4 (Acer 7745)

Standard

Antes de mais nada quero agradecer a Deus por estar usando este notebook, pois, sinceramente acho punk demais programar em monitores de alta resolução (1600×900).
Outro ponto importante para este artigo é que estou encantado com o nível de estabilidade do OpenSuse 11.4 neste notebook, que desde já deixo claro no mini overview que:

1 – Placa de rede está operando com eficiência (sim, pacotes sendo enviados usando GB),
2 – Som do Notebook alto pra caramba (e com qualidade),
3 – Brilho do monitor MUITO bem trabalhado (lembram do esquema de brilhos no ubuntu e mint, que o pau comeu pro nosso lado? http://www.appunix.com.br/howto/linux/resolvendo-problema-de-brilho-ubuntu-10-04-10-10-11-04-e-linux-mint-9-e-10-julia/),
4 – Reconhecimento de memória ram foi MUITO interessante (vide:

appunix-labs:~ # uname -a

Linux appunix-labs.site 2.6.37.6-0.5-desktop #1 SMP PREEMPT 2011-04-25 21:48:33 +0200 i686 i686 i386 GNU/Linux

appunix-labs:~ # free -m
total used free shared buffers cached
Mem: 3639 1118 2521 0 45 726
-/+ buffers/cache: 346 3293
Swap: 2058 0 2058

appunix-labs:~ #
)

5 – Repositórios para quem usa Velox estão muito rápidos (1 mb de link compartilhado aqui no labs, avephoenix… 🙁 ).

No mais o sistema em si é um tesão, Gnome 2.x, LibreOffice e etc.

Segue um lspci do Hardware testado:

00:00.0 Host bridge: Intel Corporation Core Processor DRAM Controller (rev 12)
00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 12)
00:16.0 Communication controller: Intel Corporation 5 Series/3400 Series Chipset HECI Controller (rev 06)
00:1a.0 USB Controller: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller (rev 06)
00:1b.0 Audio device: Intel Corporation 5 Series/3400 Series Chipset High Definition Audio (rev 06)
00:1c.0 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 1 (rev 06)
00:1c.5 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 6 (rev 06)
00:1d.0 USB Controller: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller (rev 06)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev a6)
00:1f.0 ISA bridge: Intel Corporation Mobile 5 Series Chipset LPC Interface Controller (rev 06)
00:1f.2 SATA controller: Intel Corporation 5 Series/3400 Series Chipset 4 port SATA AHCI Controller (rev 06)
00:1f.3 SMBus: Intel Corporation 5 Series/3400 Series Chipset SMBus Controller (rev 06)
00:1f.6 Signal processing controller: Intel Corporation 5 Series/3400 Series Chipset Thermal Subsystem (rev 06)
02:00.0 Ethernet controller: Atheros Communications AR8151 v1.0 Gigabit Ethernet (rev c0)
09:00.0 Network controller: Broadcom Corporation BCM43225 802.11b/g/n (rev 01)
ff:00.0 Host bridge: Intel Corporation Core Processor QuickPath Architecture Generic Non-core Registers (rev 02)
ff:00.1 Host bridge: Intel Corporation Core Processor QuickPath Architecture System Address Decoder (rev 02)
ff:02.0 Host bridge: Intel Corporation Core Processor QPI Link 0 (rev 02)
ff:02.1 Host bridge: Intel Corporation Core Processor QPI Physical 0 (rev 02)
ff:02.2 Host bridge: Intel Corporation Core Processor Reserved (rev 02)
ff:02.3 Host bridge: Intel Corporation Core Processor Reserved (rev 02)

Pronto, vamos meter o pau e resolver logo essa parada com a velocidade do dragão?

Em primeiros passos DEVEMOS habilitar alguns repositórios que por default (mantidos pela comunidade) não estão ativos, porém, para que tudo funfe ok precisam estar instalados. Primeiro devemos abrir o YAST2 (Meu computador -> SISTEMA -> YAST), devemos seguir exatamente conforme a tela abaixo, para clicar nos repositórios afim de localizarmos o trecho para add repositórios:

Yast2

Yast2

Pronto, feito isto devemos selecionar os repositórios principais, mas para isso iremos avançar menu por menu até chegar na hora fatal :P, veja as imagens abaixo:

clicar em adicionar OPENSUSE

clicar em adicionar OPENSUSE

Veja que, conforme o print, na tela, devemos clicar em ADICIONAR afim de que adicionemos repositórios pelo gestor, veja a imagem abaixo que mostra a tela seguinte:

Escolher Repositórios da COMUNIDADE

Escolher Repositórios da COMUNIDADE

Assim que clicarmos em adicionar nos será dado um leque de opções, devemos escolher adicionar um repositório da comunidade, que como podem ver marcamos Mozilla Beta, Packman (sem este não conseguiremos colocar a Wifi para  moer), Mozilla e o Contrib, veja os prints seguintes:

Processando Escolha da comunidade

Processando Escolha da comunidade

Listas de Repositórios disponíveis

Listas de Repositórios disponíveis

Terminando Marcações de Repositórios

Terminando Marcações de Repositórios

 

Depois disto, quando clicarmos em OK o sistema vai processar nossas escolhas, porém, ele reclamará de chaves não válidas, devemos ignorar tais mensagens aceitando tais chaves gpg, veja a imagem abaixo:

Importar Chaves Problemáticas

Importar Chaves Problemáticas

 

Estamos perto da glória e neste instante não vamos perder o fôlego, antes devemos receber uma notificação do que foi mudado, veja nosso print:

Status de Mudanças Realizadas

Status de Mudanças Realizadas

 

Agora é hora de console 😛

Devemos impor as mãos e meter o pau no negócio, vamo que vamo?

Devemos rodar todos os comandos abaixo como ROOT afim de nem perdermos tempo com autorizações, para isto digite su – e coloque a senha do sistema para ganhar direitos globais como root e use os seguintes comandos abaixo:

appunix-labs:~ # lsmod | grep “b43|ssb|wl”
appunix-labs:~ # rmmod b43
appunix-labs:~ # rmmod ssb
appunix-labs:~ # zypper remove b43-fwcutter
appunix-labs:~ # echo “blacklist ssb” >> /etc/modprobe.d/50-blacklist.conf
appunix-labs:~ # echo “blacklist bcm43xx” >> /etc/modprobe.d/50-blacklist.conf
appunix-labs:~ # echo “blacklist b43” >> /etc/modprobe.d/50-blacklist.conf
appunix-labs:~ # echo “blacklist ndiswrapper” >> /etc/modprobe.d/50-blacklist.conf
appunix-labs:~ # zypper in broadcom-wl broadcom-wl-kmp-desktop
appunix-labs:~ # modprobe wl

 

Por fim dê um reboot:

appunix-labs:~ # reboot

 

Assim que seu S.O. voltar você deverá apertar FN + F3 para habilitar sua WIFI, dando tudo ok o resultado deve ser parecido com a foto abaixo:

wifi no opensuse

wifi no opensuse

 

Rolou ok aí?

Se ficar uma mini gamb de não aceitar sua WIFI pass, faça o seguinte, reinicie o pc, DESCONECTE qualquer cabo de rede e tente conectar-se via WIFI.

Rolou ok agora?

Tudo certinho?

Curtiu?

Use uma tática chamada SHARE, compartilhe.
Quer agradecer?
Comenta aí!
AppUnix agradece sua visita -> ENJOY!

Liberado: Lion 10.7.1 UPDATE oficial Apple

Standard

Para a felicidade geral dos early users a Apple acaba de liberar o 10.7.1. O update já está disponível via Software update para os usuários do Lion e possui uma versão especial para os Mac mini e MacBooks Air modelos 2011.

Vejam as mudanças trazidas pela atualização:

The OS X Lion v10.7.1 Update is recommended for all users running OS X Lion and includes general operating system fixes that enhance the stability and compatibility of your Mac, including fixes that:

Address an issue that may cause the system to become unresponsive when playing a video in Safari.
Resolve an issue that may cause system audio to stop working when using HDMI or optical audio out.
Improve the reliability of Wi-Fi connections.
Resolve an issue that prevents transfer of your data, settings, and compatible applications to a new Mac running OS X Lion.
Resolve an issue in which an admin user account could be missing after upgrading to OS X Lion.

Serviço:

Link para download da versão Client: OS X Lion Update 10.7.1 (Client)
Link para download da versão Client para Mac mini 2011 e Macbook Air 2011: OS X Lion 10.7.1 Update for MacBook Air and Mac mini 2011 (Client)
Link para download da versão server: OS X Lion Update 10.7.1 (Server)

 

Fonte 100% copiada de: http://www.applespotlight.com.br/2011/08/16/10-7-1/

Android 2.3 no Milestone 2 (Motorola Owned) LOL

Standard

Quanto mais a motorola se faz de cadeado mais hackers de verdade trabalham e ownam tudo que querem. Ownaram a zé bestona recentemente e o método de rodar a SBF rooteada segue-se de 3 formas abaixo:

 

 

Lembrando que os métodos acima só rodam para o MILESTONE 2 (A953) da Motorola (vulgo Zé BESTÃO).
Good LUCK!

Como descobrir qual processador roda no seu Mac Os X de forma simples.

Standard

Galera, vamos rodar simples comandos para colhermos informações sobre nossos macs, ok?

Primeiro teremos de abrir nosso terminal, para isto clique em Aplicativos-> Utilitários -> Terminal:

abrir terminal UNIX no mac

abrir terminal UNIX no mac

Dentro do terminal você digitara os seguintes comandos:

 

Little-oaks-iMac:~ little_oak$ sysctl -n machdep.cpu.brand_string

A saída deve parecer com esta da imagem abaixo (que é Intel(R) Pentium(R) Dual CPU E2160 @ 1.80ghz —> Perceba que varia de cada processador, com certeza o seu deve ser core i5 e etc):

Lendo info da CPU

Lendo info da CPU

Temos outra alternativa VIÁVEL :P, bora ver?

 

Little-oaks-iMac:~ little_oak$ system_profiler | grep Processor

A saída deve se parecer muito com:

Processor Name: Intel Core 2 Duo
Processor Speed: 1.8 GHz
Number Of Processors: 1

Lendo info da CPU EXTRA

Lendo info da CPU EXTRA

Curtiu?

Use uma mágica chamda SHARE!

😛

 

Fonte: http://osxdaily.com

Como criar pendrive bootável do Mac OS X Lion

Standard

Olá galera tudo tranqüilo?
Com a chegada da nossa versão final do Mac OS X Lion pairou sobre nossas cabeças como seria se precisácemos fazer uma instalação do ZERO em nossos iGadgets… Com o upgrade sendo feito através do App Store fica essa dúvida na cabeça dos usuários… De acordo com a Apple caso o usuário queira uma instalação Limpa, o mesmo terá que instalar o Snow Leopard fazer update até a versão 10.6.6 e ai, só depois dessa trabalheira toda você será capaz de subir para o Lion (o que na verdade já não é mais uma instalação limpa.. venhamos e convenhamos Apple, isso não é instalação limpa)… mas deixemos de mazela e vamos ao que interessa…. hoje vou ensinar como criar um pendrive bootável com a versão Build final (11A494) do Mac OS X Lion….
O que você precisará:

—> 1 computador rodando Mac OS X Snow Leopard (pode ser Hackintosh)
—> o .app do Mac OS X Lion (isso mesmo galera… o Sistema operacional vem como .app)
—> 1 pendrive de no mínimo 8GB (poderia ser 6Gb, mas como nunca ví estou indicando um de 8)
—> 15 minutos pra ler esse artigo

Galera primeira coisa a se fazer é preparar o pendrive… vá até o Utilitário de Disco, no painel superior | Ir/Utilitários

Lion

Entre em Utilitário de Disco
Lion_1

Chegando ao Utilitário verá uma tela mais ou menos assim
Lion_2

No painel da esquerda selecione o disco onde deseja que o Lion faça sua moradia… No caso um Kingston Datatraveler de 8.01 GB
Lion_3

Na aba de ações escolha Particionar
Lion_4

Em esquema de volume e Informações de Volume coloquei respectivamente 1 Partição e nome coloquei Lion (pode se usar qualquer nome, pois o mesmo será substituído posteriormente)
Lion_5

No canto inferior direito clique em Aplicar
Lion_6

Será notificado sobre as notificações no Disco
Lion_7

Mande particionar. Acabamos a primeira etapa….
Agora pra adiantar as coisas baixe o aplicativo ShowAllFiles
Executeo e claque em Show

Lion_8

Agora vá até seu .app que baixou da App Store, claque com o botão direito do mouse e claque em Mostrar Conteúdo do Pacote
Lion_9

Como na imagem entre na pasta Contents depois na pasta SharedSupport chegará até nosso primeiro arquivo importante…. execute o arquivo de imagem InstallESD.dmg
Lion_10

Ao executá-lo verá uma tela semelhante a essa
Lion_11

Agora execute o BaseSystem.dmg
Lion_12

Chegará a essa tela
Lion_13

Agora volte ao Utilitário de Disco, na guia onde usamos para Particionar o disco de destino do Lion, clique em Restaurar
Lion_14

Em Fonte arraste Mac OS X Base System (que foi montado quando executamos o BaseSystem.dmg)
Lion_15

Em destino arraste seu pendrive para label (em nosso caso o chamamos de Lion)
Lion_16

Ficando assim a tela completa
Lion_17

Clique em Restaurar no canto inferior Direito
Lion_18

Será notificado, clique em Apagar
Lion_19

Digite sua senha
Lion_20

Todo o processo demora em torno de 5 minutos…. agora falta pouco galera… muito pouco… Agora amigos vá até o disco Mac OS X Install ESD
Lion_21

Agora copie a pasta Packages para a área de transferência (Command+C)
Lion_22

Agora vá no pendrive (que agora chama-se Mac OS X Base System)… pra facilitar na identificação do local correto, aconselho verificar a ordem dos dispositivos montados (em todos meus teste por ter sido o ultimo a ser montado em todo o processo o pendrive fica como sendo o ultimo da lista)
Lion_23

No seu pendrive vá em System/Installation
Lion_24

Exclua o atalho para  a pasta Packages que ali se encontra
Lion_25

Lembram da pasta Packages que copiamos lá do Mac OS X Install ESD?
é pra cá que vamos copialo, é uma cópia um pouquinho demorada (já que estamos falando de 3.26 GB e para um dispositivo com velocidade de gravação baixa)
Lion_26

Agora é só correr para o abraço… pode usar tanto no seu Mac verdadeiro quanto no seu Hackintosh (com o devido CdBoot… Aconselho CdBoot feito pelo André do HMBT…que funciona desde de o DP4 do Mac OS X Lion)…
Abraço a todos… Espero que ajude a todos… Obrigado aos vários fóruns sobre Mac OS, OSX86 que existem por ai… em especial à toda staff do HMBT (http://www.hmbt.org/forum)
Fui!!!! 😀

Gostou? Comente, complemente e espalhe!

[Dica] Como limpar o seu Macbook White

Standard

E ai galera tudo tranqüilo?
Hoje, vou tocar em um assunto não muito comum nas rodas de amigos e usuários do sistema Mac OS X e que aterroriza todos os usuários deste fabuloso iGadget…..Que atire a primeira pedra que nunca se perguntou como deve limpar seu Macbook White…. eu digo…. encontrei a solução…. quase que perfeita…
Pessoas como eu, que andam com seu iGadget pra todos os lados… atende cliente aqui… corre ali…. com o tempo você perceberá que seu belo Macbook branquinho já não está tão branquinho e vai perdendo a cada semana aquela beleza inconfundível no Gadgets da Apple… então está aqui a solução ilustrada de como limpar seu Macbook para garantir que ele fique sempre lindo e o principal… Branquinho como era quando você o comprou…..
Vejam as fotos dele antes da limpeza…..

Antes

Antes_1

Antes_2

Vocês devem estar pensando, Doooguinha onde você usa seu Macbook? Parecer esta usando-o em lugares sujos, com a mão suja, ou então não tem aceio algum com seu Gadgets…. Não meus amigos, nada disso…. quem tem Macbook sabe que é algo inevitável quando se trabalha/vive a todo tempo com seu Macbook em Mãos… É o preço que paga (vale cada centavo)…..  Infelizmente alguns Gadgets da Apple não têm classe no processo de envelhecimento… mas vamos ao que interessa…..
Aqui consegui grande sucesso ao limpar meu Macbook com esse produto

Produto

UAU Cloro Ativo… já usei com a mesma eficiência Agua Sanitária…. Esses somados a um pano branco (usei pano de prato, se não souberem sua mãe sabe bem o que é….) bem limpo; agora basta tirar 20/25 minutos do seu precioso tempo e fazer a faxina no seu branquinho….. Na tela use somente algodão, somente…. puro… nada mais…. você com um pouco de paciência conseguirá deixar sua bela tela de LED ou LCD (nos branquinhas mais antigos) livre de manchas e marcas…. agora vejam como ficou meu lindo Macbook após a faxina que demorou em torno de 25 minutos….

Depois
Depois_1

Vejam que ficou como novo, muito bom mesmo…. tomem cuidado com a quantidade de produto (UAU Cloro Ativo) no momento em que forem limpar o teclado…. muito cuidado mesmo, para que o excesso de produto não escorra para a parte interna do teclado…. Por hoje é isso galera….
Abraço a todos…. 😀

Como verificar versões de CMS de maneira rápida e prática

Standard

Para verificar devemos baixar a seguinte ferramenta em um dos dois endereços abaixo:

root@appunix:˜#wget http://server.cmsversion.com/checktest.sh

ou

root@appunix:˜#wget http://www.libphp.net/checktest.sh

Em seguida fazer o seguinte

root@appunix:˜#chmod +x checktest.sh

root@appunix:˜#./checktest.sh -u logindeumacontanomeuserver

A saída deverá assemelhar-se com:

Latest Joomla: 1.5.23
Installed Version: 1.5.20
Installed Location: /home/logindeumacontanomeuserver/public_html/pathdocms/

Essa dica funciona para Joomla, WordPress, WHMCS e etc.

How to sobre como usar o Subversion (usuário)

Standard

Prefácio

Lancei este tutorial sobre o Subversion, originalmente, no dia 30 de maio de 2005 ainda pelo PATUX – Projeto de Aprendizado Tecnológico Universitário, na Universidade de Brasília (UnB), a partir de traduções e adaptações do manual oficial do mesmo (http://svnbook.red-bean.com). Tinha como objetivo explicar o funcionamento deste sistema de versionamento (com documentação deficitária, em português, à época), e ensinar os membros do projeto a acessar os repositórios e contribuir para o desenvolvimento de software livre.Desde então, muita coisa mudou: o projeto terminou, o Subversion (que na período estava na versão 1.0.8 e era visto com certa desconfiança em relação ao já estabelecido CVS) já chegou à versão 1.5.4, vários novos front-ends foram lançados, suporte às mais populares IDEs (Eclipse, Visual Studio, entre outras) foi adicionado e, não menos importante (pelo menos para mim :P), pude alcançar um sonho particular: trabalhar e liderar conjuntamente uma empresa que verdadeiramente representa e trabalha em prol do software livre, a PWSys – Soluções em Tecnologia.

Assim sendo, creio ser de grande valia o relançamento deste documento, revisado e generalizado para utilização em cenários menos específicos que os que imaginei inicialmente. Reforça, ainda, a posição de comprometimento da PWSys com relação ao software livre e sua comunidade: outros documentos como este serão lançados, estando dispostos para auxiliar a propagação da cultura open source no Brasil.

Dito isso, sigam com o prefácio original deste tutorial.

Este tutorial visa dar uma introdução rápida sobre como utilizar o sistema de controle de versões Subversion. Este tutorial consistirá basicamente de quatro capítulos (clique nos links para ir diretamente):

  1. O que é o Subversion?
  2. Conceitos básicos de versionamento
  3. Comandos do Subversion
  4. Front-ends
Espero que com o que for explicado aqui o leitor possa utilizar de pronto e sem maiores problemas qualquer repositório Subversion. Esta é uma leitura altamente recomendada para os iniciantes em sistemas de versionamento, porém se quiser obter mais informações consulte o site oficial do Subversion (http://subversion.tigris.org) e o manual oficial (http://svnbook.red-bean.com), que contém muito mais detalhes do que este documento. Quaisquer dúvidas ou sugestões busque diretamente o autor, em seu e-mail (
<!–
var prefix = ‘ma’ + ‘il’ + ‘to’;
var path = ‘hr’ + ‘ef’ + ‘=’;
var addy72051 = ‘fbscarel’ + ‘@’;
addy72051 = addy72051 + ‘pwsys’ + ‘.’ + ‘com’ + ‘.’ + ‘br’;
document.write( ‘<a ‘ + path + ‘” + prefix + ‘:’ + addy72051 + ‘’>’ );
document.write( addy72051 );
document.write( ‘</a>’ );
//–>n fbscarel@pwsys.com.br
<!–
document.write( ‘<span style=’display: none;’>’ );
//–>
). Boa leitura!Felipe Scarel, 10 de dezembro de 2008.

Licença

Copyright (c)  2008  Felipe Brant Scarel e PWSys – Soluções em Tecnologia
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license can be read at http://www.gnu.org/copyleft/fdl.html

Histórico de Revisões

Versão Data Autor Comentários
1.1 2008-12-10 11:25:26 Felipe Scarel Novo prefácio, Reescrita do Cap. 4
1.0 2005-05-30 01:30:04 Felipe Scarel Versão inicial do documento

O que é o Subversion?

O Subversion é um sistema de controle de versões livre, ou opensource. Com “sistema de controle de versões” queremos dizer que ele é capaz de gerenciar arquivos e diretórios ao longo do tempo. Basicamente, os arquivos são guardados em um repositório central e são servidos aos clientes. Muito embora isto se assemelhe a um servidor de arquivos, a diferença fundamental do Subversion é que ele guarda todas as modificações feitas nos arquivos e diretórios ao longo do tempo. Isso nos permite recuperar versões antigas dos dados ou simplesmente verificar o histórico destes. Por este motivo, é comum pensar nos sistemas de versionamento como “máquinas do tempo”. Para compreender melhor o Subversion é interessante que conheçamos um pouco da sua história:

No mundo do software livre, desde o início fez-se necessária uma ferramenta que pudesse controlar o aparente “caos” com que os programas são desenvolvidos. Para que todos pudessem desenvolver simultaneamente e sem prejuízo à organização foram criadas ferramentas de versionamento livres, sendo a mais bem-sucedida delas o Concurrent Versioning System (CVS), que logo se tornou o padrão em projetos opensource, e assim permanece até hoje. E com toda a razão, pois o fato de ser software livre, ter um design não-restritivo e bom suporte a rede permitem que vários programadores ao redor do mundo compartilhem seu código e construam softwares em conjunto. Porém, dada a sua idade, o CVS está se tornando ultrapassado, e muitos recursos modernos dos sistemas de versionamento não podem nele ser encontrados.

No início de 2000, a CollabNet (http://www.collab.net) comecou a buscar programadores para desenvolver um substituto ao CVS, que pudesse implementar o que ele apresenta de melhor mas sem copiar suas falhas mais evidentes. Eles então buscaram Karl Fogel (também um dos autores do livro do Subversion), que já vinha discutindo idéias semelhantes com seu amigo Jim Blandy. Este último inclusive já havia tido não apenas a idéia do nome “Subversion” bem como feito o layout básico de um repositório Subversion. Chamado pela CollabNet, Karl imediatamente foi trabalhar no projeto e Jim fez com que sua companhia, a conhecida Red Hat, praticamente o doasse ao projeto. Fortalecidos ainda pela contratação de Ben Collins-Sussman, eles iniciaram a codificação, e, após catorze meses, mais precisamente a 31 de Agosto de 2001, o Subversion passou a versionar seu próprio código e tornou-se uma realidade.

Muito embora os sistemas de versionamento, e por conseguinte o Subversion, sejam mais comumente usados para auxiliar programadores em seu desenvolvimento, é importate frisar que o Subversion não é limitado a ajudar programadores e pode ser utilizado para versionar qualquer tipo de dado. Para esclarecer os conceitos por trás dos sistemas de versionamento leia o próximo capítulo, que tratará precisamente deste tema. Se já estiver acostumado com estes conceitos e quiser apenas ver como o Subversion os implementa, pode seguir diretamente para o capítulo 3. Caso queira começar realmente rápido, mas provavelmente sem uma base teórica necessária, siga para o capítulo 4.

Conceitos Básicos de Versionamento

O Subversion é um sistema centralizado para compartilhar informações e dados. Ele é baseado em um repositório central, onde os dados ficam guardados sob a forma típica de uma árvore de arquivos e diretórios. Um número qualquer de clientes conectam-se ao repositório e lêem (recebendo as informações dos outros) ou escrevem (disponibilizando a informação aos demais) nestes dados. Até o momento isto não seria muito diferente de um servidor de arquivos normal, mas como foi explicado no primeiro capítulo, o Subversion tem a capacidade de guardar todas as alterações feitas aos arquivos, permitindo que elas sejam observadas, comparadas entre si, e eventualmente sobrescritas umas sobre as outras.Já sabemos o principal objetivo dos sistemas de versionamento. Porém, como faríamos para que todos pudessem trabalhar colaborativamente mas sem que ocorresse uma eventual sobrescrita, acidental, em nosso repositório? Vamos primeiramente apresentar o problema:

  • Suponhamos que dois usuários leiam as informações do repositório e iniciem a fazer modificações para posteriormente submeter suas contribuições. Se um usuário mandar suas modificações, e, logo depois, o outro também tiver a mesma idéia, o que ocorrerá é que as modificações do primeiro usuário não serão visualizadas ou aproveitadas, pois serão substituídas pelas alterações do segundo (uma vez que o padrão é visualizar a versão mais recente).

Para este problema temos duas soluções que são largamente utilizadas pelos sistemas de versionamento: a “Lock-Modify-Unlock” (Trancar-Modificar-Destrancar) e a “Copy-Modify-Merge” (Copiar-Modificar-Unir). Vamos apresentar separadamente cada uma delas:

  • “Lock-Modify-Unlock”:

Muitos sistemas de versionamento utilizam esta solução, que consiste basicamente em um sistema  parecido com o aluguel de livros em uma biblioteca: um usuário tranca o arquivo para edição, e enquanto ele faz suas modificações os demais não podem acessar o arquivo para escrita; se tentarem fazê-lo, o servidor irá negar a requisição. Logo após o primeiro usuário encerrar sua edição, ele irá destrancar o arquivo, e agora sim os demais poderão acessá-lo. Os problemas desta solução logo aparecem, pois ela é muito restritiva: se o primeiro usuário, por exemplo, sair de férias e esquecer o arquivo trancado, os demais terão que esperar até que ele volte ou contatar um administrador do sistema, o que não é desejável. Outro fator: suponhamos que dois usuário queiram editar o mesmo arquivo; isto não será um problema se um deles quiser editar o começo do arquivo e o outro quiser editar o final deste, e neste caso a solução tornaria o processo burocrático. Finalmente, esta solução cria um falso senso de segurança, pois se dois usuários trancarem arquivos diferentes, porém dependentes entre si, eles poderão modificá-los de forma a torná-los incompatíveis. Neste caso o sistema não teve poder para impedir que tal fato prejudicial ocorresse.

  • “Copy-Modify-Merge”:
O Subversion, CVS, e outros sistemas de versionamento preferem utilizar esta solução como uma alternativa ao trancamento dos arquivos. Neste modelo, cada usuário contata o repositório e copia para si a chamada “working copy”, que é uma cópia fiel da estrutura de arquivos e diretórios do servidor. Esses usuários trabalham em suas cópias particulares em paralelo, e finalmente suas modificações são unidas em uma versão final. Na maioria das vezes o repositório cuida do trabalho de fazer a união ocorrer corretamente, mas em última instância um ser humano deve cuidar desse processo. Na prática, suponhamos que dois usuários obtivessem working copies para si e comecassem a editá-las. Se um deles submeter suas modificações primeiro, quando o outro tentar mandar suas alterações o repositório lhe retornará um erro de “out-of-date” (arquivo antigo). Neste caso, o usuário receberá uma cópia do arquivo novo e deverá comparar esta nova versão com a sua, alterada localmente. Há uma boa chance de que as modificações não sejam conflitantes, e ele então poderá unir suas modificações com as de seu colaborador e submeter uma nova versão, com ambas as contribuições. Mas e se as alterações forem conflitantes? Como o próprio nome indica, nesse caso temos um “conflict” (conflito), e este deverá ser resolvido pelo usuário (uma vez que o programa não é capaz de tomar as decisões inteligentemente). Após resolver o conflito preexistente, possivelmente após uma conversa com o outro usuário, ele poderá então mandar a versão final e funcional.

O modelo utilizado pelo Subversion pode parecer caótico, mas quando vamos observá-lo mais de perto veremos que ele funciona de forma transparente; conflitos são infrequentes, e, quando ocorrem, são resolvidos rapidamente. Isso depende, contudo, de uma comunidade comunicativa e responsiva.

Comandos do Subversion

Vamos ver agora o Subversion em ação. Utilizaremos nos exemplos o cliente de linha de comando do Subversion, “svn”. No quarto capítulo apresentarei ainda alguns clientes gráficos do Subversion para poupar aqueles de vocês que não apreciam a interface de texto.

Primeiramente, suponhamos que iremos acessar um repositório exemplo. Vamos cuidar então da primeira parte, que será obter nossa working copy. Talvez fosse uma boa idéia ver a estrutura de diretórios do repositório exemplo na web, através de um visualizador como o WebSVN; digamos que a estrutura dos diretórios no servidor fosse a seguinte:

svn/
.
. exemplo/
. tags/
. branches/
. trunk/
. README
.
. outros/
. x/
. y/
. z/

Vamos começar então com o comando mais importante de todos – como obter ajuda:

[shell]$ svn help

O comando acima mostraria todos os complementos possíveis ao “svn”, e poderíamos então descobrir qual comando é o mais apropriado para o nosso problema. Supondo agora que gostaríamos de obter uma working copy do repositório exemplo, digitaríamos então o seguinte comando:

[shell]$ svn checkout http://www.foo.bar/svn/exemplo
A  exemplo
A  exemplo/tags
A  exemplo/branches
A  exemplo/trunk
A  exemplo/trunk/README
Checked out revision 1.

Este comando faria o checkout, ou cópia, da pasta “exemplo”, com todo o seu conteúdo, para o diretório atual. Isto quer dizer que, com este comando, obteríamos uma working copy para edição local, possibilitando-nos que trabalhássemos nela de pronto.

Podemos observar naquela última linha “Checked out revision 1″; vejamos o que ela exatamente quer nos dizer: ela nos informa que acabamos de fazer o checkout (ou cópia) dos arquivos do servidor pertencentes à revisão 1. Quando dizemos “revisão 1″, estamos nos referindo ao estado exato do repositório quando este se encontrava na referida revisão 1. Após alguém mandar alterações ao repositório, este passará à revisão 2, que será a mais recente (também conhecida como HEAD). Mas a revisão 1 ainda estará lá, e podemos vê-la ou recuperá-la com os comandos nativos do subversion, normalmente adicionando o switch “-r” ou “–revision”.

Podemos nos referir às revisões de três formas: a mais comum é através do número, que é único e crescente (como em “revision 1″); outra forma é através de palavras-chave que o Subversion nos fornece, como por exemplo HEAD (que se refere à revisão mais recente no repositório); finalmente, podemos nos utilizar ainda de datas em formatos predefinidos.

Expliquemos ainda a estrutura de diretórios dividida em trunk/, branches/ e tags/, largamente utilizada como padrão em repositórios: o diretório trunk/ contém a linha principal de desenvolvimento do projeto, e é nela que boa parte do código é desenvolvido. Pode ser necessário, no entanto, que se desenvolva uma nova capacidade ou característica de um programa, por exemplo. Tal desenvolvimento potencialmente tornaria o código da linha trunk/ instável, e, para evitar esse fato criaríamos um branch do projeto, focado unicamente em desenvolver essa característica específica que seria posteriormente portada de volta à árvore trunk/. Esta é superficialmente a função do diretório branches/.

É também perfeitamente possível que um programa, documento, etc, chegue em um nível de estabilidade tal que poderia ser liberado ao público e no qual não seria desejável nenhuma alteração. Essa é a função do diretório tags/, no qual residem as denominadas versões “estáveis” do projeto em questão.

Retornando aos comandos do Subversion, suponhamos agora que você deixou sua working copy parada por uns tempos e agora resolveu voltar a trabalhar nela. É possível, na verdade provável, que o estado do repositório tenha sido alterado desde sua última conexão. Para trabalhar em cima das versões mais recentes, é necessário que baixemos as modificações, e o faremos através do svn update:

[shell]$ svn update
U  exemplo/trunk/README
U  exemplo/trunk/novo.txt
Updated to revision 2.

Este comando deverá ser executado sob o diretório em que se encontra a working copy, obviamente. Ele irá buscar no servidor as modificações ocorridas em relação à versão local e aplicá-las de imediato.

A esta altura você deve ter notado as letras que apareceram nos últimos comando, A e U. Mas o que elas querem dizer? Vamos ver a seguir:

  • U: o arquivo foi “Updated” (atualizado) a partir do servidor
  • A: o arquivo ou diretório foi “Added” (adicionado) à sua working copy
  • D: o arquivo ou diretório foi “Deleted” (deletado) da sua working copy
  • R: o arquivo ou diretório foi “Replaced” (substituído) em sua working copy, ou seja, um elemento foi deletado e posteriormente outro com o mesmo nome foi adicionado; embora tenham o mesmo nome o repositório consegue percebê-los como arquivos diferentes
  • G: o arquivo no servidor recebeu alterações, mas sua cópia local tinha as suas modificações; ou as alterações não interceptavam ou eram idênticas às suas, então o Subversion conseguiu colocá-las em  estado de “merGed” (união) sem problemas
  • C: o arquivo recebeu alterações “Conflicting” (conflitantes) com as suas, ou seja, na mesma seção do arquivo; trataremos deste caso mais adiante no capítulo

Agora que já temos nossa working copy, podemos começar a trabalhar nela. Temos a possibilidade de fazer dois tipos de mudança: em arquivos específicos ou em diretórios (adicionando e removendo arquivos, por exemplo). No primeiro caso, não é necessário informar o Subversion com algum comando específico, pois ele será capaz de perceber quais arquivos foram mudados e submeter essas alterações ao servidor. Já no segundo caso, poderemos usar um dos quatro comandos básicos para manipulação de arquivos, explicados abaixo:

  • svn add

[shell]$ svn add novo.txt
A novo.txt

Este comando irá adicionar o arquivo “novo.txt” ao sistema de controle de versões, e ele também passará a ser versionado pelo repositório Subversion. Isto quer dizer que o arquivo existia para o seu computador mas era ignorado pelo Subversion, e, ao usar o “svn add”, você informou o Subversion que ele deve agora ser versionado. Se fosse um diretório, ele e todos os seus arquivos subjacentes seriam também adicionados. Vale lembrar que este passo não é opcional: não basta criar o arquivo, o “svn add” é fundamental.

  • svn delete

[shell]$ svn delete novo.txt
D novo.txt

Este outro comando irá agendar “novo.txt” para deleção do repositório. Se este fosse um arquivo ou link simbólico, ele seria imediatamente deletado da sua working copy; se fosse um diretório, seria deletado apenas após mandarmos as alterações ao servidor. É importante frisar que, após mandarmos as mudanças de volta ao repositório, o arquivo será deletado apenas da revisão mais recente, mas ainda estará presente nas revisões anteriores.

  • svn copy

[shell]$ svn copy novo.txt velho.txt
A velho.txt

O “svn copy” acima irá copiar o arquivo “novo.txt”, juntamente com seu histórico, para um arquivo denominado “velho.txt”, que será imediatamente agendade para adição no repositório. O histórico do arquivo criado irá indicar que ele é proveniente de um outro.

  • svn move

[shell]$ svn move novo.txt velho.txt
A velho.txt
D novo.txt

Como pode ser visto acima, o “svn move” irá apenas fazer o papel de “svn copy” e “svn delete” em um só comando; ele irá copiar o arquivo com um outro nome e depois irá deletar o original, o que seria basicamente o equivalente a renomear um arquivo qualquer.

Agora que já editamos o que fosse necessário ou desejável, seria interessante verificar o que foi modificado antes de mandar nossas alterações ao repositório, criando uma nova revisão. Podemos fazê-lo através do svn status (certamente o comando que você deve, espera-se, mais utilizar no Subversion):

[shell]$ svn status
M      bar.c
?      foo.o
!      qq_dir
I      .screenrc
A  +   moved_dir
M  +   moved_dir/README
D      outros/teste.c
A      outros/calc/soma.h
C      outros/calc/divide.c
R      xyz.c
S  outros/game

Temos acima um possível exemplo de saída do comando “svn status”, que nos ajudará a explicar os status mais importantes a serem compreendidos. Na primeira coluna, temos:

  • A: o arquivo/diretório foi agendado para adição no repositório
  • C: o arquivo está em estado de conflito e será necessário resolvê-lo antes de mandar as alterações ao servidor
  • D: o arquivo/diretório foi agendado para deleção no repositório
  • M: o conteúdo do arquivo foi modificado
  • R: o arquivo foi agendado para substituição no repositório, com o mesmo nome de um que foi deletado
  • ?: o arquivo em questão não está sob controle de versão (possivelmente foi criado e não foi utilizado o “svn add”)
  • !: o arquivo não está presente por algum motivo, possivelmente tendo sido deletado sem o uso de um comando Subversion
  • I: o arquivo foi configurado para ser ignorado pelo sistema de controle de versões;

Na coluna seguinte poderemos ver um “+” ou não, indicando que um arquivo foi agendado para adição no repositório com a preservação de seu histórico. Isso provavelmente nos dirá que ele é proveniente de uma cópia com o “svn copy” (A+), ou, além de ter sido copiado também foi modificado localmente (M+). A última coluna nos dirá se um arquivo ou diretório foi deslocado do caminho do restante de sua working copy, com o comando “svn switch”, para um branch ou tag (explicados mais à frente). Para a referência completa dos possíveis outputs do “svn status” consulte o manual oficial do Subversion.

Adicionando o switch “-u” ou “–show-updates” ao “svn status”, juntamente com a opção “-v” ou “–verbose” (para maior detalhamento), ele irá contatar o servidor e comparar suas modificações com as revisões que lá se encontram, e irá informar sobre arquivos antigos (out-of-date):

[shell]$ svn status –show-updates –verbose
M      *        44        23    john      README
M               44        20    david     bar.c
*        44        35    susan     outros/teste.c
Status against revision:   46

Os asteriscos acima nos indicam que caso fosse utilizado o “svn update” neste ponto os arquivos “README” e “teste.c” receberiam modificações. Isto quer dizer que nossa revisão local está desatualizada e devemos fazer um update para receber as modificações nestes arquivos e conferir se estas conflitam com a versão local.

Digamos agora que queremos saber exatamente quais modificações fizemos aos arquivos antes de mandá-las ao servidor; esta seria uma boa hora para usar o svn diff, que mostrará as diferenças entre a nossa versão modificada e a versão obtida inicialmente (que fica no diretório oculto .svn):

[shell]$ svn diff
Index: teste.c
===================================================================
— teste.c (revision 3)
+++ teste.c (working copy)
@@ -1,7 +1,12 @@
+#include
+#include
+#include
+
+#include

int main(void) {
–  printf(“Ola mundon”);
+  printf(“Ola de novo mundon”);
return 0;
}

As modificações são mostradas em formato diff unificado, sendo as linhas adicionadas mostradas com um “+” antes e as deletadas mostradas com um “-”. É interessante notar que podemos facilmente produzir um patch (arquivo incluido apenas as modificações em um arquivo) com o auxílio do svn diff, como no exemplo abaixo:

[shell]$ svn diff > patchfile

Suponhamos então que você descobrisse que as suas alterações ao “teste.c” acima foram feitas por engano, e que portanto você gostaria de retornar este arquivo ao seu estado original; é um bom momento para utilizar o svn revert:

$ svn revert teste.c
Reverted ‘teste.c’

Isto retornará nosso arquivo “teste.c” ao seu estado original, quando fizemos nosso último checkout a partir do repositório. É um processo semelhante ao utilizado para recuperar eventuais modificações mandadas ao servidor mas que foram desastrosas.

Neste último caso, bastaria dar um checkout em uma revisão anterior e funcional (usando o switch “–revision”), e posteriormente mandar esta revisão correta ao servidor novamente, se tornando HEAD.

Vale lembrar ainda que estes trás últimos comandos, muito embora lidem diretamente com os arquivos antigos, dispensam uma conexão com a rede, pois o Subversion inteligentemente mantém uma cópia imodificada dos arquivo em uma pasta oculta “.svn”, e depois apenas compara o conteúdo desta pasta com as modificações feitas pelo usuário.

Já estamos praticamente finalizados com nossa tarefa diária: sabemos adicionar e deletar arquivos, verificar as modificações feitas, conferir se estas estão desatualizadas e resolver conflitos simples, processo automatizado pelo Subversion. Mas ainda resta uma dúvida: e se nossas modificações não resultarem em um conflito simples, no qual nossa alteração intercepta diretamente a de um colaborador? Vejamos a saída de um svn update que causará esse problema:

[shell]$ svn update
U  INSTALL
G  README
C  teste.c
Updated to revision 46.

As letras U e G caem naqueles casos estudados anteriormente: no primeiro foi feito um update simples e no segundo o Subversion conseguiu unir as modificações locais e remotas sem maiores problemas. Já a terceira ocorrência poderá nos causar um problema, pois indica um conflito (C). Neste caso surgirão três arquivos no diretório de trabalho: [ARQUIVO].mine (com as alterações locais), [ARQUIVO].r[OLD] (arquivo imodificado desde o último update) e [ARQUIVO].r[NEW] (o arquivo proveniente do update, diretamente do repositório). Serão ainda colocados marcadores de conflito no arquivo original, a fim de auxiliar o processo de análise. Poderemos resolver o conflito de três formas:

  • Unir os arquivos manualmente:

Pode parecer ameaçador, mas fazer a união dos arquivos é na verdade realmente simples: analisar-se-á as alterações feitas remotamente e estas serão comparadas às locais. O usuário deverá decidir qual delas é a melhor, ou então poderá juntar ambas as soluções. De qualquer maneira, é imprescindível que haja uma boa comunicação entre os colaboradores, pois seria conveniente que houvesse uma discussão entre eles para decidir o melhor caminho.

  • Escolher uma das opções:

Pode-se ainda optar por simplesmente copiar uma das soluções inteiramente, ou a local ou a remota. Nesse caso, bastaria um “cp” simples dos sistemas UNIX-like para resolver o conflito.

  • Descartar as edições locais:

Finalmente, é também possível perceber que as alterações feitas localmente não deveriam ser mandadas ao repositório. Neste último caso, bastaria um “svn revert” para encerrar o conflito e retornar os arquivos aos seus estados originais.

Uma vez resolvidos todos os conflitos, devemos informar o Subversion, e o faremos com o comando svn resolved:

[shell]$ svn resolved teste.c

Com este comando os arquivos extras que haviam sido criados serão excluídos e a condição de conflito desaparecerá. Agora sim poderemos mandar nossas modificações ao repositório (finalmente!), e o faremos com o comando svn commit:

[shell]$ svn commit -m “Algumas modificacoes simples no arquivo teste.c”
Sending        teste.c
Transmitting file data .
Committed revision 47.

O comando acima submeterá nossas modificações locais ao repositório, e a mensagem passada através do switch “–message” ou “-m” será a mensagem de log do commit. É importantíssimo que essa mensagem descreva precisamente o que foi modificado, assim ficará muito mais fácil recuperar o repositório após um engano, além de ajudar os usuário a utilizar o sistema com mais eficiência. Essa mensagem pode ser ainda passada através de um arquivo, com o switch “–file”.

Existem ainda muitos outros comandos que este tutorial não cobriu, afinal o seu foco é de que seja uma fonte rápida para consulta e aprendizado. Dentre estes encontram-se comandos de pesquisa e administrativos. É altamente recomendada a leitura, complementar, do manual oficial do Subversion.

Front-ends

Desde a versão original deste documento, o número de front-ends disponíveis para o Subversion aumentou drasticamente, exigindo total reformulação desta seção. Aos programas descritos originalmente (RapidSVN, WebSVN e TortoiseSVN), juntaram-se vários outros dignos de nota e de usos variados, e que tornam esse sistema de controle de versão ainda mais interessante de ser utilizado. De clientes stand-alone até aqueles integrados ao desktop, passando por aplicações para browsing via web ou IDE, o número de opções para acessar e operar repositórios SVN é tanto que seria até injusto eleger alguns poucos para figurar neste tutorial.

Assim sendo, irei utilizar o mesmo approach da página de links do site oficial do Subversion (http://subversion.tigris.org/links.html): por categorias, cada aplicação e um link para sua página será apresentado, bem como uma breve descrição do programa. Sem mais delongas, vamos à lista:

  1. Cornerstone: cliente gráfico Subversion para Mac OS X. Não é open source, mas possui versão trial gratuita disponível
  2. eSvn: cliente gráfico multiplataforma baseado em QT para o Subversion
  3. FSVS: rápido cliente de linha de comando para o Subversion centrado em implantação de software
  4. KDESvn: cliente Subeversion para o KDE
  5. QSvn: cliente gráfico multiplataforma para o Subversion
  6. RapidSVN: cliente gráfico multiplataforma para o Subversion
  7. RSVN: script Python que permite múltiplas operações de repositório em uma única transação atômica
  8. SmartSVN: cliente gráfico multiplataforma para o Subversion. Não é open source, mas está disponível em versões gratuita e comercial
  9. Subcommander: cliente gráfico multiplataforma para o Subversion, inclui ferramenta para merge textual
  10. SvnX: cliente gráfico multiplataforma para Mac OS X Panther
  11. Syncro SVN Client: cliente gráfico multiplataforma para o Subversion. Não é open source, mas possui versão trial disponível para Mac OS X, Windows e Linux
  12. WorkBench: ambiente de desenvolvimento multiplataforma utilizando Subversion, escrito em Python
  13. Versions: cliente gráfico Subversion para Mac OS X. Não é open source; requer licença comercial
  14. ZigVersion: interface Subversion para Mac OS X. Interface voltada a workflows típicos de programadores. Não é open source
  1. Cascade: driver de sistema de arquivos multiplataforma para o Subversion, tanto gráfico quanto em linha de comando. Também provê outras funcionalidades de alto nível. Não é open source; gratuito para uso pessoal
  2. KSvn: cliente Subversion para o KDE; um plugin para o Konqueror
  3. SCPlugin: integração Subversion para o Finder do Mac OS X
  4. TortoiseSVN: um cliente Subversion, implementado como extensão do shell do Windows
  • Plugins para IDEs (vale lembrar que muitas IDEs suportam o Subversion nativamente ou por plugins inclusos; esta seção lista os plugins não-inclusos com as IDEs)
  1. Aigenta Unified SCC: plugin Subversion/CVS para programas compatíveis com MSSCCI, incluindo o Microsoft Visual Studio e outros. Não é open source, mas possui versão trial gratuita disponível
  2. AnkhSVN: integração Subversion para o Microsoft Visual Studio
  3. CW Subversion: plugin VCS para o Metrowerks CodeWarrior
  4. Subclipse: plugin Subversion para o Eclipse
  5. Subversive: plugin Subversion para o Eclipse
  6. SVN SCC Proxy: plugin SCC para SVN. Este não é um projeto open source
  7. VisualSVN: integração Subversion para o Visual Studio .NET 2003, 2005 & 2008. Este é um produto comercial de código fechado
  8. WLW-SVN: extensão Subversion para o WebLogic Workshop (8.1.3/8.1.4)
  1. psvn.el: interface Subversion para o emacs
  2. Vcscommand.vim: plugin de integração CVS/SVN/SVK para o editor vim
  1. Trac: o Trac é um sistema web minimalista para gerenciamento de projetos e tracking de bugs e requisições. Ele provê uma interface ao sistema de controle de versões (Subversion), um Wiki integrado e funcionalidades de report
  2. Collaboa: browser de repositório e tracker de requisições, similar ao Trac
  1. SVN::Web
  2. ViewVC (previamente conhecido como ViewCVS)
  3. WebSVN
  4. Insurrection: Repositório em http://svn.sinz.com/svn/Insurrection/
  5. Chora
  6. SVN::RaWeb::Light
  7. FlexySvn
  8. perl_svn
  9. mod_svn_view
  10. bsSvnBrowser
  11. sventon
  12. WebClient for SVN

Conclusão

Espero que este documento tenha sido de ajuda para o seu aprendizado, leitor, e através dele estou certo de que foi possível aprender os passos fundamentais para um dia de trabalho completo em um repositório Subversion. Agradeço a leitura e boa utilização dos repositórios!

fonte: http://pwsys.com.br/index.php?option=com_content&view=article&id=67:tutorial-usuario-subversion&catid=41:tutoriais&Itemid=66

Lamp2: Ubuntu Server APACHE 2 Mysql 5 PHP 5 phpmyadmin

Standard

Um ambiente LAMP2 (apache 2 mysql 5 php 5 e phpmyadmin) é fundamental para quem desenvolve e deseja testar sua app antes de envia-la para web, sem mais, vamos aos passos:

1 – Clique em Aplicativos->Acessórios->Terminal OU CASO ESTEJA USANDO QUALQUER OUTRA VERSÃO SERVER SEM X, CTRL + ALT + F2.
2 – rode o comando:

sudo apt-get install apache2

Este comando serve para instalar o apache 2. Ressalto que usei o gestor de pacotes e habilitei o suporte a pacotes instáveis e também o repositório partner (mais abaixo posto como fazer).

Ainda no console use o comando abaixo:

sudo apt-get install php5 libapache2-mod-php5
Isto servirá para instalar o php5 e ainda integra-lo como DSO no apache (como módulo).

Já que estamos na metade do caminho o ideal seria dar um restart no apache para garantir que ele leu seu conf.
Use o comando:

sudo /etc/init.d/apache2 restart

A saída deverá ser parecida com:

* Restarting web server apache2 apache2: Could not reliably determine the server’s fully qualified domain name, using 127.0.1.1 for ServerName
… waiting apache2: Could not reliably determine the server’s fully qualified domain name, using 127.0.1.1 for ServerName
[ OK ]

Para garantir que o apache está interpretando códigos php (fazendo uso do interpretador como módulo) podemos editar um arquivo e testa-lo. use o comando abaixo:

sudo vi /var/www/index.php

Dentro deste arquivo informe:

echo 'APPUNIX é um lab de nerds!';
?>

escreva : e depois escreva wq! e pressione enter, ficando algo como :wq! , você salvará o arquivo e sairá do vi.
Feito isto acesse o arquivo para ver se a mensagem APPUNIX é um lab de nerds! aparece, caso sim, sucesso total! Do contrário releia este manual!
Este teste pode ser feito em http://localhost/index.php

Para instalar o mysql como servidor de banco de dados devemos usar o seguinte comando:
sudo apt-get install mysql-server


No meio desse esquema todo serão exibidas janelas que solicitarão a senha de administrador do mysql, semelhantes as imagens abaixo:

senha mysql root

senha mysql root

Outra tela:

senha root mysql 2

senha root mysql 2

Estas telas pedem para que você dê uma senha para o usuário root do mysql, escolha uma senha ao seu gosto e depois repita a mesma.

Agora iremos integrar o php + apache + mysql + phpmyadmin, para isto precisaremos usar o comando:

sudo apt-get install libapache2-mod-auth-mysql php5-mysql phpmyadmin

Neste meio tempo uma tela para escolher entre apache e lighttpd aparecerá, escolha apache. Veja:

escolha apache

escolha apache

Na primeira tela escolha OK e dê um tab para confirmar que aceita a opção.

phpmyadm

phpmyadm

A próxima tela pedirá uma senha de admin para o phpmyadmin, para isto defina algo seu. Veja a tela:

pass phpmyadm

pass phpmyadm

Costumo, após terminar uma instalação de integração como esta utilizar-me de lago, insira as seguintes linhas naquela página index.php usando sudo vim /var/www/index.php
Informe dentro dela o seguinte:

mysql_connect(‘localhost’, ‘root’, ‘suaSENHA’) or die(mysql_error());
?>

Acesse http://localhost/index.php

Se nada ocorrer tudo está 100%.

Quando terminar use o comando:
sudo /etc/init.d/apache2 restart

Isto vai fazer o apache reler todos os confs.

Para concluir precisamos levar o phpmyadmin para a pasta web afim de que possamos editar nossos bds. Para isto precisamos copiar o phpmyadmin para dentro do /var/www usando o comando:

cp -rp /usr/share/phpmyadmin /var/www

Sendo assim, para acessar somente precisamos de um http://localhost/phpmyadmin

Mudando encoding do Postgres para poder usar banco de dados latin1 ou outro e mudar o encoding do Ubuntu ou Debian

Standard

Algo simples que desejamos e a trabalheira grandiosa :(. O que queremos? Mudar o encoding default para Latin1 (se bem que o mundo hoje gira em torno de utf8), assim como mudar locales para PT_BR.

1 – Encoding do Sistema Operacional Debian/Ubuntu Ferrados (sim, você brasileiro e a droga do locale te mostrando coisas de americanos, pode uma coisa destas?)

2 – Mudar o Encoding do Postgres.

Vamos ao ataque

Antemão você precisa saber que o seu sistema foi configurado por algum bestão, isto mesmo, o cara instalou o sistema americano sendo brasileiro.

Ter um porstgres que não aceita nem a pau um encoding diferente (padrão dessa tosquisse sempre é UTF8).

Locale do Sistema

Mãos-a-Obra

Todas as configurações e comandos foram executados como usuário root.

Existem vários arquivos que fazem a configuração do locale, precisamos configurar todos eles e depois executar alguns comandos, vamos lá.

Edite o arquivo /etc/environment e altere os campos LANG e LANGUAGE de forma que fiquem iguais ao abaixo, se não existir, acrescente:

LANG="pt_BR"
LANGUAGE="pt_BR:pt:en"

O arquivo /etc/default/locale também deve ser editado e seu conteúdo deve ser:

LANG="pt_BR"
LANGUAGE="pt_BR:pt:en"

Execute o seguinte comando:

# echo "pt_BR pt_BR.ISO-8859-1" >> /etc/locale.alias

Este arquivo grava os aliases para os locales, isso é para facilitar as configurações.

No diretório /var/lib/locales/supported.d alguns arquivos que configuram os locales que serão gerados, por padrão existem três arquivos “en”, “pt” e “local”. Para nosso caso, pode apagar o “en” e o “pt” deixando apenas o “local”.

Feito isso, edite o arquivo local e deixe seu conteúdo como abaixo:

pt_BR.ISO-8859-1 ISO-8859-1
en_US.ISO-8859-1 ISO-8859-1

Muito bem, configuramos os arquivos necessários para a geração dos locales, agora vamos reconfigurar.

Os comandos abaixo fazem o serviço:

# localedef pt_BR -i pt_BR -f ISO-8859-1
# localedef pt_BR.ISO-8859-1 -i pt_BR -f ISO-8859-1
# localedef pt_BR.ISO8859-1 -i pt_BR -f ISO-8859-1
# dpkg-reconfigure locales
# locale-gen --purge
# locale-gen

###### SE HOUVER ERRO USE:
localedef pt_BR -i pt_BR -f UTF-8
localedef pt_BR -i pt_BR -f LATIN1

Acredito que apenas um desses três comandos fariam o serviço, mas como eu executei os três quando estava configurando o sistema não vou tirar algum deles, é melhor executar a mais e funcionar do que executar a menos e não funcionar.

Reinicie o sistema e execute o comando abaixo para termos certeza que está tudo conforme o desejado.

# locale
LANG=pt_BR
LANGUAGE=pt_BR:pt:en
LC_CTYPE="pt_BR"
LC_NUMERIC="pt_BR"
LC_TIME="pt_BR"
LC_COLLATE="pt_BR"
LC_MONETARY="pt_BR"
LC_MESSAGES="pt_BR"
LC_PAPER="pt_BR"
LC_NAME="pt_BR"
LC_ADDRESS="pt_BR"
LC_TELEPHONE="pt_BR"
LC_MEASUREMENT="pt_BR"
LC_IDENTIFICATION="pt_BR"
LC_ALL=

# locale -a
C
en_US.iso88591
POSIX
pt_BR.iso88591

Agora sim, está tudo como deveria estar. Nosso sistema já está usando ISO-8859-1.

(ISO-8859-1é LATIN1)

Corrigindo o Encoding do Postgres

Bem, esta é a hora do quebra-quebra, vamos lá:

1 – Crie uma nova instância (cluster) de gestão do Postgres:

sudo pg_createcluster -e LATIN1 -d /caminho/do/novoSGDB 8.3
cluster-8.3-2

Feito isto, a porta que o postgres vai operar neste novo SGDB será 5433

Criando SuperUser para administrar o Postgres

[root@appunixlabs:~] # su – postgres

[postgres@appunixlabs:~] $ createuser -P

Digite o nome da role a ser adicionada: pglinux
Digite a senha para a nova role:
Digite-a novamente:
A nova role poderá criar um super-usuário? (s/n) s
CREATE ROLE

Quer ver os users?

[postgres@appunixlabs:~] $ psql
postgres=# du
Lista de roles
Nome da role | Super-usuário | Cria role | Cria BD | Conexões  | Membro de
————–+—————+———–+———+———–+———–
pglinux       | sim                    | sim            | sim         | ilimitado    |
postgres         | sim                    | sim            | sim         | ilimitado    |
(2 registros)

postgres=# q

 

Obs: Se estiver usando Debian 4 mude o path para aceitar corretamente todas as mudanças

PATH=”/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games”

 

 

Caso seus locales estejam 100% ajustados antes mesmo deste How To você pode usar outros meios, uma vez criado um banco com uma encoding (LATIN1, SQL_ASCII, UTF8), só é possível mudá-lo fazendo um backup e recriando o banco. Embora a documentação do PostgreSQL informe sobre a opção -E no pg_dump, falta um “pulo do gato”, que é o que vai ser apresentado neste passo a passo.

1. Se for migração de servidor, altere o arquivo pg_hba.conf (geralmente em /etc/postgresql/8.x/main/pg_hba.conf) do servidor antigo para incluir a linha:

hostnossl all postgres ipnovoservidor/32 trust

2. Reinicie o PostgreSQL no servidor antigo:

# service postgresql-8.3 restart

3. Faça um “su” para o usuário postgres no servidor novo:

# su postgres

4. Gere o backup no servidor novo (se for o mesmo servidor, a opção h é desnecessária) . UTF8 é um exemplo de encoding, mas de qualquer forma é recomendado como padrão):

$ pg_dump -h hostanti -C -E UTF8 -U postgres bancodedados > bancodedados.sql

5. O pulo do gato: a opção -E do pg_dump gera o ARQUIVO no encoding desejado. Mas a opção -C (que copia a estrutura original), copia fielmente, a ponto de gerar a linha:

CREATE DATABASE foh WITH TEMPLATE = template0 ENCODING = ‘LATIN1’;

com o encoding original, o que gera erro na importação.

O MACETE É TROCAR O ENCODING PARA O CORRETO:

CREATE DATABASE foh WITH TEMPLATE = template0 ENCODING = ‘UTF8’;

Obs.: Se o arquivo for grande, o “mcedit” (que uso muito), não dá conta de abrir, mas o “joe” não reclama.

6. Agora é só rodar:

$ psql -f bancodedados.sql