Encerra com Sucesso
Caso não esteja visualizando corretamente 'acesse' 2ª Semana Internacional da Embalagem, Impressão e Logística supera expectativas dos expositores e mostra a evolução do setor, negócios e novidades das marcas de sucesso do evento. A 2ª SEMANA INTERNACIONAL DA EMBALAGEM, IMPRESSÃO E LOGÍSTICA, organizada pela Reed Exhibitions Alcantara Machado, de de 22 a 26 de março no Pavilhão Anhembi teve a marca de sucesso, refletiu a retomada do segmento no País. Indicadores dessa realidade foram as negociações realizadas e a quantidade e qualidade do público visitante, que estava focado em conhecer detalhes técnicos dos lançamentos apresentados, em fechar negócios e prospectar novos clientes. Ilha Temática A “Área Verde”, um pavilhão com 250 m², mostrou as vantagens e benefícios de utilizar materiais e processos tecnológicos ecologicamente corretos que minimizem o impacto ambiental. Participaram da ilha BERUF, CAIXAS NET, CRB, NEUPLAST, RMS, ROCHMAN e ABEAÇO. Eventos Integrados A organizadora e promotora do evento, a Reed Exhibitions Alcantara Machado, apresentou uma importante novidade a seus visitantes: a realização de uma conferência e dois seminários, que promoveram o debate de assuntos pertinentes aos segmentos gráficos, de embalagens e de ilustração e design. “Além de fomentar novos negócios, queremos também impulsionar a reflexão e discussão para temas que sejam de interesse do visitante de nossas feiras e, também, das empresas expositoras. Por isso, pretendemos continuar com essa iniciativa nas próximas edições”, destaca a Show Manager da SEMANA INTERNACIONAL, Liliane Bortoluci. A opinião de quem participou Entre os 500 expositores que participaram da 2ª SEMANA INTERNACIONAL DA EMBALAGEM, IMPRESSÃO E LOGÍSTICAS 2010, as opiniões resumem a satisfação com o retorno de um investimento que garantiu visibilidade institucional, troca de experiências profissionais e promoveu a aproximação entre as empresas, concretizando, muitas vezes, negócios lucrativos para os envolvidos. “O ótimo ambiente proporcionado pela feira foi um dos principais motivos para o lançamento da marca Strasbourg no País e de seus equipamentos. Aqui é o momento de encontrar com nossos clientes e promover nossa tecnologia e qualidade em máquinas para potenciais compradores. Nesta edição, além do público nacional, percebemos uma participação grande de executivos vindos do exterior, tanto é que nossa primeira máquina foi vendida para a Bolívia”, Alessandro Carlo Angeli, diretor da Strasbourg e presidente do Grupo Narita. “Percebemos a presença de visitantes estrangeiros nos dois primeiros dias da feira e de visitantes vindos de outros estados nos dois dias seguintes, o que foi ótimo para nós. Fechamos alguns negócios e recebemos muitas consultas desses clientes. A feira foi boa”, Maurício Maselli, gerente da Radial Tecnograf. “Participamos pela primeira vez do evento e gostamos da experiência por isso pretendemos voltar nas próximas edições. Viemos para o pavilhão com a intenção de atender as empresas de menor porte e conseguimos realizar bons negócios, superando nossas expectativas”, Leno Ribeiro, diretor-presidente da Tecmapack. “Obtivemos vendas signicativas durante o evento, superando nossas expectativas. Foi animador, após um período de crise econômica mundial. Realmente, estamos otimistas com a perspectiva de retomada de nossa indústria”, Glauco Tarrone, gerente comercial da Apolo “O público está adorando a Área Verde. Como expositores, estou surpreso com a qualificação dos visitantes que vieram para fazer negócios. Temos grandes expectativas com as futuras negociações que possam surgir”, David Romando, diretor da Caixas Net. “Logo nos primeiros dias, realizamos ótimos negócios. Foi uma ótima surpresa. Estamos satisfeitos com os resultados alcançados, certamente, superou nossas expectativas”, Natalia Lupette de Araújo, Gerente Financeira da Filpemack. “Os resultados superaram nossas melhores expectativas. Passamos dos 200 contatos cadastrados por dia e já temos solicitação de projetos em conjunto de mais de 180 empresas. Com esse resultado, pretendemos retornar nas próximas edições do evento, sempre trazendo novidades ecologicamente corretas”, Paulo Francisco da Silva, representante comercial da Neuplast. “O público da feira é comprador, por isso conseguimos ótimos prospects”, Sergio Neder, Gerente da MB Machines, empresa expositora da BrasilScreen. “Estamos muito contentes com os resultados obtidos. Diversos contratos foram fechados e já temos contatos e propostas para o pós-feira. Um dos responsáveis por nosso sucesso foi o lançamento da impressora flexográfica gear less, que segundo os visitantes foi a vedete da feira. Nosso índice de visitação girou em torno de 1200 pessoas por dia, com visitantes diretamente ligados à área”, Wagner Santos, gerente de Marketing da Furnax. “A qualidade do público visitante chamou nossa
Re: Invite to join the Release Team
Clint Adams sch...@debian.org writes: [Adding and M-F-T-ing -project] On Sun, Mar 14, 2010 at 10:04:58AM +0100, Marc 'HE' Brockschmidt wrote: I want to point out that Luk's mail was not in any way discussed in the release team. I think it is horrible. I welcome everyone to critize the release team. I would prefer help, of course, but on the other hand, I do understand that people can see a problem, but don't have the time to fix. It would be nice if such criticism would be sent directly to the release team, and bluntly point out what the problem is, as that makes it easier to work on the issue. Okay, so when there is a mysterious release team meeting in Cambridge, and there is no discussion or planning of it on debian-release, or #debian-release, or anywhere else public that I can see, and there is zero evidence that it was planned or happened on official channels, and at least two of the participants (or whom I assume were participants) tell me that transparency is either completely unimportant or low-priority, and the DPL-2IC team seems to favor the opposite of transparency, how is one supposed to know about this meeting in time to complain about it? How and why should one complain to the release team directly? Were you there? Were Debian funds spend on this endeavor? What happened there? Most importantly, why is it all so secretive? Did I miss a response to these questions? I'm interested to know the answer to at least two of them. micah -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/877hot58v2@pond.riseup.net
Re: Bug#575938: ITP: dh-autoreconf -- debhelper add-on to call autoreconf and clean up after the build
On Wed, Mar 31, 2010 at 1:03 AM, Julian Andres Klode j...@debian.org wrote: Description : debhelper add-on to call autoreconf and clean up after the build Package: dh-autoreconf I'd suggest just putting this into debhelper rather than making it a separate package. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/t2he13a36b31003302307t5202749asd2adbe6e342eb...@mail.gmail.com
Re: About new source formats for packages without patches
On Tue, 30 Mar 2010, Sven Mueller wrote: Julien BLACHE schrieb: Raphael Hertzog hert...@debian.org wrote: I expect this to be of particular interest when we'll have VCS-powered source formats (say 3.0 (git2quilt)) that generate source packages that are plain 3.0 (quilt) based on the git repository information. This is becoming crazy, really. I agree. dpkg-dev should not be depending on any VCS and it should not promote any particular VCS either. I know that git is the new black (oh, wait, that was something else), but I personally don't like it. And I especially dislike how so many git lovers are trying to push it onto others, while there are perfectly good reason (not applicable to all teams or projects of course) not to use git but some other VCS (be it distributed or not. It was an example. I have never said that dpkg-dev would support only one VCS. Cheers, -- Raphaël Hertzog Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/ My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100331061841.gf...@rivendell
Re: About new source formats for packages without patches
James Westby jw+deb...@jameswestby.net writes: The unpacked source package has no format, it's a directory on disk with certain properties. You could take that directory and produce a source package in any number of formats. The debian/source/format is then not a declaration of what format the directory is in, but what format the tools should produce when creating a source package from it. Thank you, that's a useful distinction. I'll consider it and see if I need to ask more questions, rather than making more noise in this discussion. -- \ “We must find our way to a time when faith, without evidence, | `\disgraces anyone who would claim it.” —Sam Harris, _The End of | _o__) Faith_, 2004 | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87r5n1m2rm@benfinney.id.au
Re: Naming policy for Perl modules (mass bug filing)
On Wed, Mar 31, 2010 at 3:04 AM, Luke L lukehasnon...@gmail.com wrote: Philosophical question: When does this sort of thing get taken care of? In twenty years, will Debian (if it's still going) have myriad misnamed libraries? I know one can Shouldn't housecleaning like this be of higher priority, especially say, when a new version has just been put out? That way, maintainers would have months to slowly work on one package (and its associated reverse-dependencies) at a time. I do not know the technical constraints (no autobuild, etc), but consistency is a valuable trait of an operating system. This sort of thing is automatically detectable, so there is now a wishlist bug against lintian to detect it and warn the developer. Unless people start ignoring lintian or new developers don't learn that lintian exists, that should keep this problem at bay. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/q2pe13a36b31003302325h45317970r9077d31d96e65...@mail.gmail.com
Re: Best practices for development workstations
On Tue, Mar 30, 2010 at 11:24 PM, John Goerzen jgoer...@complete.org wrote: On Tue, Mar 30, 2010 at 09:02:59AM +0800, Paul Wise wrote: On Tue, Mar 30, 2010 at 8:03 AM, John Goerzen jgoer...@complete.org wrote: 1. workstation running sid I used that until DebConf9 when I reinstalled and switched from i386 to amd64. 2. workstation running squeeze or lenny At the moment I have only one workstation (a laptop). I use testing, unstable and experimental, with pinning setup to upgrade within that suite where I've upgraded a package, until the version migrates to a lower suite. I'm having a bit of trouble visualizing how that works; can you spell out your apt settings? Something like this (not my exact settings): Package: * Pin: release a=stable Pin-Priority: 700 Package: * Pin: release a=testing Pin-Priority: 650 Package: * Pin: release a=unstable Pin-Priority: 600 Package: * Pin: release a=experimental Pin-Priority: 550 The priorities need to be 500 and 1000. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/q2we13a36b31003302344wc60b0572u507fdd57e86f9...@mail.gmail.com
Re: About new source formats for packages without patches
Le mercredi 31 mars 2010 à 08:18 +0200, Raphael Hertzog a écrit : I agree. dpkg-dev should not be depending on any VCS and it should not promote any particular VCS either. I know that git is the new black (oh, wait, that was something else), but I personally don't like it. And I especially dislike how so many git lovers are trying to push it onto others, while there are perfectly good reason (not applicable to all teams or projects of course) not to use git but some other VCS (be it distributed or not. It was an example. I have never said that dpkg-dev would support only one VCS. Supporting several ones would be even worse. What’s the point in standardizing over a common and flexible package format if it cannot be used with all other tools? -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `-[…] I will see what I can do for you.” -- Jörg Schilling signature.asc Description: This is a digitally signed message part
Re: Hardware trouble ries.debian.org - ftpmaster.debian.org / release.d.o services disabled
Now, should the technician not be able to resurrect ries, our backup plan extends to have the disks shipped over and replace the ones currently in rietz. I'm wondering if Debian has the resources (DSA, local admins and hardware) to have a hot-swappable backup machine for ftpmaster, since it does go down occasionally and when it does the downtime is fairly disruptive to Debian. Well, this would mean: a) double ftpmaster. Just as a rough number, the new machine that is currently in progress has an estimated cost of 2 Dollar (if you take prices from HP Website. This is not what it will cost in the end, but it shows what category of stuff we have to get) b) Have the double space at our hoster. c) Run it with heartbeat, drbd and all that. Point c) is actually easy enough, even though im not DSA and can't decide for them to do it. But technically it would be a working setup, provided b) works out, as you really want a *FAST* connection between the two. Which means local. The only trouble this setup has is that you have a pretty huge expensive machine always on and running, but not actually doing stuff for 99.% of the time. And usually the support pack we ordered provides a service that means getting machine back faster than this, so the question in the end is: Do we want the added complexity (and costs), or can we just stand a day or three of downtime? Its annoying, but world doesnt really die. (And note, the support has done great jobs replacing harddisks multiple times in the past already, for example) -- bye, Joerg I read the DUMP and agree to it. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87pr2l6izk@gkar.ganneff.de
Re: Best practices for development workstations
Hi, On Dienstag, 30. März 2010, Marco Túlio Gontijo e Silva wrote: squid! (Or any other normal http proxy. I don't recommend any apt-proxy solution...) Can you explain why? apt-proxy had issues when I tried (as well as others, which I cannot rememeber now), approx iirc requires to changes /etc/apt/sources list, squid always worked for me and never had issues, squid is useful for more then just proxying apt repositories, squid can be set up as a transparent proxy quite easily, updating a full/partial mirror usually takes more bandwidth then just using a proxy. cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: Bug#575938: ITP: dh-autoreconf -- debhelper add-on to call autoreconf and clean up after the build
On Wed, Mar 31, 2010 at 02:07:31PM +0800, Paul Wise wrote:
Package: dh-autoreconf
I'd suggest just putting this into debhelper rather than making it a
separate package.
Seconded. The addons looks quite general, I don't see the point of
having it in a separate package.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: About new source formats for packages without patches
Josselin Mouette wrote: Le mercredi 31 mars 2010 à 08:18 +0200, Raphael Hertzog a écrit : I agree. dpkg-dev should not be depending on any VCS and it should not promote any particular VCS either. I know that git is the new black (oh, wait, that was something else), but I personally don't like it. And I especially dislike how so many git lovers are trying to push it onto others, while there are perfectly good reason (not applicable to all teams or projects of course) not to use git but some other VCS (be it distributed or not. It was an example. I have never said that dpkg-dev would support only one VCS. Supporting several ones would be even worse. What’s the point in standardizing over a common and flexible package format if it cannot be used with all other tools? Hi I do admit I have not completely figured out how it would work and how it would help us. However, this is exactly why I am not ready to discard the idea yet. That being said, I would (as it is now) actually prefer that it was just a helper tool that from a VCS could derive a source package of existing format. That would probably also increase the adoption rate, since existing tools would work with those formats. ~Niels I reserve the right to change my opinion on this if the implementation of the VCS-based source format is awesome enough. signature.asc Description: OpenPGP digital signature
Re: Hardware trouble ries.debian.org - ftpmaster.debian.org / release.d.o services disabled
On Wed, Mar 31, 2010 at 3:35 PM, Joerg Jaspert jo...@debian.org wrote: The only trouble this setup has is that you have a pretty huge expensive machine always on and running, but not actually doing stuff for 99.% of the time. And usually the support pack we ordered provides a service that means getting machine back faster than this, so the question in the end is: Do we want the added complexity (and costs), or can we just stand a day or three of downtime? Its annoying, but world doesnt really die. Hmmm, OK. There don't seem to be any other machines hosted in the same place so having another machine that is used for other stuff most of the time and also as a backup ftp-master during outages wouldn't work, for now at least. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/u2ne13a36b31003310113q11c0b00dw34e2a55971b2b...@mail.gmail.com
Re: Best practices for development workstations
On Wed, Mar 31, 2010 at 02:44:48PM +0800, Paul Wise wrote: I'm having a bit of trouble visualizing how that works; can you spell out your apt settings? Something like this (not my exact settings): Package: * Pin: release a=stable Pin-Priority: 700 Package: * Pin: release a=testing Pin-Priority: 650 Package: * Pin: release a=unstable Pin-Priority: 600 Package: * Pin: release a=experimental Pin-Priority: 550 The priorities need to be 500 and 1000. == /etc/apt/preferences.d/experimental == Package: * Pin: release a=experimental Pin-Priority: 50 == /etc/apt/preferences.d/testing == Package: * Pin: release a=testing Pin-Priority: 800 == /etc/apt/preferences.d/unstable == Package: * Pin: release a=unstable Pin-Priority: 700 == /etc/apt/preferences.d/stable == Package: * Pin: release a=stable Pin-Priority: 500 (actually I do not have the last one: 500 is the value given to non-specified versions). If you have a default release, it is given 990 without any other intervention. What you should care for is giving priorities between 101 and 989 to non-default release. I use a script called apt-origins to check where my packages come from (for example, I only have unison-2.13.16 and xpdf installed from stable). I prefer to always rate stable lower than testing, because a package that is no more in testing but is in stable is suspicious at best (it was removed from testing at some point). And for the rest of the thread, I use pbuilder chroots. Testing of non-controversial packages goes on either my home box (unstable/testing, arch=amd64) or my lab box (testing/unstable, arch=amd64 kernel+i386 userland) or my laptop (testing/unstable, arch=i386). The more complicated things I have a kvm virtual machine for, except for drivers and such. Sincerly -- Jean-Christophe Dubacq -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100331090029.ga9...@oberon.tenebreuse.org
Re: About new source formats for packages without patches
On Wed, 31 Mar 2010, Niels Thykier wrote: That being said, I would (as it is now) actually prefer that it was just a helper tool that from a VCS could derive a source package of existing format. That would probably also increase the adoption rate, since existing tools would work with those formats. The (theoretical) format that I gave as example was precisely this: it generates a 3.0 (quilt) source package using a VCS repository as input. Cheers, -- Raphaël Hertzog Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/ My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100331091830.gb1...@rivendell
Bug#576006: ITP: qtwebkit -- Web content engine library for Qt
Package: wnpp Severity: wishlist Owner: Fathi Boudra f...@debian.org Owner: Fathi Boudra f...@debian.org * Package name: qtwebkit Version : 2.0 Upstream Author : Apple Inc. * URL : http://trac.webkit.org/wiki/QtWebKit * License : BSD Programming Lang: C++ Description : Web content engine library for Qt QtWebKit provides a Web browser engine that makes it easy to embed content from the World Wide Web into your Qt application. Note: it's shipped also from Qt 4.6.x source package. see also http://labs.trolltech.com/blogs/2010/03/03/qtwebkit-releases/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100331105818.26082.53394.report...@dc7700p
Re: Hardware trouble ries.debian.org - ftpmaster.debian.org / release.d.o services disabled
Joerg Jaspert jo...@debian.org writes: Now, should the technician not be able to resurrect ries, our backup plan extends to have the disks shipped over and replace the ones currently in rietz. I'm wondering if Debian has the resources (DSA, local admins and hardware) to have a hot-swappable backup machine for ftpmaster, since it does go down occasionally and when it does the downtime is fairly disruptive to Debian. Well, this would mean: a) double ftpmaster. Just as a rough number, the new machine that is currently in progress has an estimated cost of 2 Dollar (if you take prices from HP Website. This is not what it will cost in the end, but it shows what category of stuff we have to get) b) Have the double space at our hoster. c) Run it with heartbeat, drbd and all that. Point c) is actually easy enough, even though im not DSA and can't decide for them to do it. But technically it would be a working setup, provided b) works out, as you really want a *FAST* connection between the two. Which means local. The only trouble this setup has is that you have a pretty huge expensive machine always on and running, but not actually doing stuff for 99.% of the time. And usually the support pack we ordered provides a service that means getting machine back faster than this, so the question in the end is: Do we want the added complexity (and costs), or can we just stand a day or three of downtime? Its annoying, but world doesnt really die. Is there any way to build a distributed service instead of relying on one central machine (or two machines sitting next to each other)? I don't know exactly what services are involved, but typically and generally, when I deploy a server infrastructure, I try to setup (at least) two machines at different geographical places that each can provide the entire service. The complexity in getting a heartbeat, drbd, etc solution to work can easily eat up any downtime savings you plan to get. /Simon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fx3gg3dn@mocca.josefsson.org
Re: Hardware trouble ries.debian.org - ftpmaster.debian.org / release.d.o services disabled
On Wed, Mar 31, 2010 at 09:35:59AM +0200, Joerg Jaspert wrote: I'm wondering if Debian has the resources (DSA, local admins and hardware) to have a hot-swappable backup machine for ftpmaster, since it does go down occasionally and when it does the downtime is fairly disruptive to Debian. Well, this would mean: [...] c) Run it with heartbeat, drbd and all that. Point c) is actually easy enough, even though im not DSA and can't decide for them to do it. But technically it would be a working setup, provided b) works out, as you really want a *FAST* connection between the two. Which means local. What is it that ftp-master does that can only run on one computer at a time? If most of the services it provides could be distributed, you could spread the load to multiple machines, and get redundancy at the same time. -- Met vriendelijke groet / with kind regards, Guus Sliepen g...@debian.org signature.asc Description: Digital signature
Re: About new source formats for packages without patches
Hi, On Wed, Mar 31, 2010 at 11:18:30AM +0200, Raphael Hertzog wrote: On Wed, 31 Mar 2010, Niels Thykier wrote: That being said, I would (as it is now) actually prefer that it was just a helper tool that from a VCS could derive a source package of existing format. That would probably also increase the adoption rate, since existing tools would work with those formats. The (theoretical) format that I gave as example was precisely this: it generates a 3.0 (quilt) source package using a VCS repository as input. I guess what we should have is additional line in it or additional file to record vcs used for packaging which will not interface with the basic operation of other tools. We have now (as I know from typical packages.): debian/source/format debian/source/lintian-override what's wrong with having another. Some tool may use it ... some can just ignore... Anyway, with 3.0 format, we are moving away from diff format to allow binary image without awkward hack. This is good. We now have packaging data stored in separated and standardized for easy inspection with intuitive structure. These are the plus for everyone who have extra time to update package. (We should not force such update because we are Debian ...) Osamu PS: Making distribution wise change for consistency has been challenge for Debian. We have been slow. That is good in some way... -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100331114728.ga4...@osamu.debian.net
Hadoop in Debian, was:Re: Hardware trouble ries.debian.org
Joerg Jaspert: SNIP The only trouble this setup has is that you have a pretty huge expensive machine always on and running, but not actually doing stuff for 99.% of the time. /SNIP Hadoop is now in Debian: http://packages.qa.debian.org/h/hadoop.html Hadoop is an Open Source implementation of Google's File System, MapReduce and BigTable (HBase, not yet packaged). The idea behind Google's infrastructure and therefor Hadoop is: Have many cheap comodity servers that together form a powerful cluster. Each node of the cluster is redundant and can be replaced without downtime. I believe, but can't know for sure, that everything what FTP-Master does, could be implemented on top of hadoop. However it means for sure a lot of work and many hardcore sysadmins will feel very uncomfortable to use Java, the language Hadoop is written in. I'm planning to give a presentation of hadoop at the DebConf in Bosnia and maybe then we may discuss, if hadoop should have a place in Debian's infrastructure. - For now I'm happy, if somebody became curious. :-) http://en.wikipedia.org/wiki/Hadoop Best regards, Thomas Koch, http://www.koch.ro -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003311442.09336.tho...@koch.ro
Re: Bug#575938: ITP: dh-autoreconf -- debhelper add-on to call autoreconf and clean up after the build
On Wed, Mar 31, 2010 at 02:07:31PM +0800, Paul Wise wrote: On Wed, Mar 31, 2010 at 1:03 AM, Julian Andres Klode j...@debian.org wrote: Description : debhelper add-on to call autoreconf and clean up after the build Package: dh-autoreconf I'd suggest just putting this into debhelper rather than making it a separate package. Well, Joey wrote the following: Regarding including these commands in debhelper, I am uncertian because these commands would not be included in the default dh sequences, or the example rules files, and that would be a first -- currently every command in debhelper is included in the dh sequences and all except dh_auto_* are included in the longer example rules files. Adding an optional command to debhelper that likely does not do the right thing for a fairly large percentage of packages (my experience with running autoreconf and having it actually work, in the real world, is not exactly stellar) would be a departure. -- Julian Andres Klode - Debian Developer, Ubuntu Member See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/. pgpDdmQXsVJhe.pgp Description: PGP signature
Re: About new source formats for packages without patches
On Wed, Mar 31, 2010 at 08:47:28PM +0900, Osamu Aoki wrote: Hi, On Wed, Mar 31, 2010 at 11:18:30AM +0200, Raphael Hertzog wrote: On Wed, 31 Mar 2010, Niels Thykier wrote: That being said, I would (as it is now) actually prefer that it was just a helper tool that from a VCS could derive a source package of existing format. That would probably also increase the adoption rate, since existing tools would work with those formats. The (theoretical) format that I gave as example was precisely this: it generates a 3.0 (quilt) source package using a VCS repository as input. I guess what we should have is additional line in it or additional file to record vcs used for packaging which will not interface with the basic operation of other tools. You mean Vcs-* in debian/control? -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@debian.org signature.asc Description: Digital signature
Re: Bug#575938: ITP: dh-autoreconf -- debhelper add-on to call autoreconf and clean up after the build
On Wed, Mar 31, 2010 at 03:13:14PM +0200, Mehdi Dogguy wrote: Paul Wise wrote: On Wed, Mar 31, 2010 at 1:03 AM, Julian Andres Klode j...@debian.org wrote: Description : debhelper add-on to call autoreconf and clean up after the build Package: dh-autoreconf I'd suggest just putting this into debhelper rather than making it a separate package. Is there any advantage to have it packaged? AIUI, you have to add a build-dependency anyway and change at least one line in the debian/rules to call dh-autoreconf. Well, that line could simply call autoreconf (or whatever) which even makes debian/rules clearer. The difference is that dh_autoreconf calls autoreconf and stores a list of the changes and the changed files are then removed in the clean target. If you just call autoreconf, the changes end up in the diff; and this is not what we want. BTW; The code is now available at http://git.debian.org/?p=collab-maint/dh-autoreconf.git and also features a CDBS rule for those maintainers still using it and a --mode parameter with a 'timesize' mode to use size+timestamp instead of an md5sum to detect changes. -- Julian Andres Klode - Debian Developer, Ubuntu Member See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/. pgpVgB1XevI8j.pgp Description: PGP signature
Re: Bug#575938: ITP: dh-autoreconf -- debhelper add-on to call autoreconf and clean up after the build
Paul Wise wrote:
On Wed, Mar 31, 2010 at 1:03 AM, Julian Andres Klode j...@debian.org wrote:
Description : debhelper add-on to call autoreconf and clean up after
the build
Package: dh-autoreconf
I'd suggest just putting this into debhelper rather than making it a
separate package.
Is there any advantage to have it packaged?
AIUI, you have to add a build-dependency anyway and change at least one
line in the debian/rules to call dh-autoreconf. Well, that line could
simply call autoreconf (or whatever) which even makes debian/rules clearer.
Cheers,
--
Mehdi Dogguy مهدي الدڤي
me...@{dogguy.org,debian.org}
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4bb34a6a.3050...@debian.org
Re: Bug#575938: ITP: dh-autoreconf -- debhelper add-on to call autoreconf and clean up after the build
Julian Andres Klode wrote: On Wed, Mar 31, 2010 at 03:13:14PM +0200, Mehdi Dogguy wrote: Paul Wise wrote: On Wed, Mar 31, 2010 at 1:03 AM, Julian Andres Klode j...@debian.org wrote: Description : debhelper add-on to call autoreconf and clean up after the build Package: dh-autoreconf I'd suggest just putting this into debhelper rather than making it a separate package. Is there any advantage to have it packaged? AIUI, you have to add a build-dependency anyway and change at least one line in the debian/rules to call dh-autoreconf. Well, that line could simply call autoreconf (or whatever) which even makes debian/rules clearer. The difference is that dh_autoreconf calls autoreconf and stores a list of the changes and the changed files are then removed in the clean target. If you just call autoreconf, the changes end up in the diff; and this is not what we want. I do use autoreconf and I don't have these changes in my diff. IMO, a backup/restore script (where you specify the list of files to backup) may be more useful. It would be called before build and when cleaning. Cheers, -- Mehdi Dogguy مهدي الدڤي http://dogguy.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bb351ea.3000...@dogguy.org
Re: Bug#575938: ITP: dh-autoreconf -- debhelper add-on to call autoreconf and clean up after the build
Am Mittwoch, den 31.03.2010, 15:45 +0200 schrieb Mehdi Dogguy: Julian Andres Klode wrote: On Wed, Mar 31, 2010 at 03:13:14PM +0200, Mehdi Dogguy wrote: Paul Wise wrote: On Wed, Mar 31, 2010 at 1:03 AM, Julian Andres Klode j...@debian.org wrote: Description : debhelper add-on to call autoreconf and clean up after the build Package: dh-autoreconf I'd suggest just putting this into debhelper rather than making it a separate package. Is there any advantage to have it packaged? AIUI, you have to add a build-dependency anyway and change at least one line in the debian/rules to call dh-autoreconf. Well, that line could simply call autoreconf (or whatever) which even makes debian/rules clearer. The difference is that dh_autoreconf calls autoreconf and stores a list of the changes and the changed files are then removed in the clean target. If you just call autoreconf, the changes end up in the diff; and this is not what we want. I do use autoreconf and I don't have these changes in my diff. IMO, a backup/restore script (where you specify the list of files to backup) may be more useful. It would be called before build and when cleaning. I prefer the removal over the restoring the old files. You remove .o files on clean, so why not remove the other auto-generated files on clean? -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Bug#575938: ITP: dh-autoreconf -- debhelper add-on to call autoreconf and clean up after the build
On Wed, Mar 31, 2010 at 03:45:14PM +0200, Mehdi Dogguy wrote: Julian Andres Klode wrote: On Wed, Mar 31, 2010 at 03:13:14PM +0200, Mehdi Dogguy wrote: Paul Wise wrote: On Wed, Mar 31, 2010 at 1:03 AM, Julian Andres Klode j...@debian.org wrote: Description : debhelper add-on to call autoreconf and clean up after the build Package: dh-autoreconf I'd suggest just putting this into debhelper rather than making it a separate package. Is there any advantage to have it packaged? AIUI, you have to add a build-dependency anyway and change at least one line in the debian/rules to call dh-autoreconf. Well, that line could simply call autoreconf (or whatever) which even makes debian/rules clearer. The difference is that dh_autoreconf calls autoreconf and stores a list of the changes and the changed files are then removed in the clean target. If you just call autoreconf, the changes end up in the diff; and this is not what we want. I do use autoreconf and I don't have these changes in my diff. A 'debuild; debuild' should have a different result than a single debuild then. If you build from a clean directory, the first build will contain no changes. But after the build, the directory is not clean anymore and debian/rules clean does not do enough to keep the changes from appearing in the source package if you build again. IMO, a backup/restore script (where you specify the list of files to backup) may be more useful. It would be called before build and when cleaning. I don't think so, it requires you to keep track of the files and you may miss some. -- Julian Andres Klode - Debian Developer, Ubuntu Member See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/. pgpmgpo89uZbA.pgp Description: PGP signature
Re: Bug#575938: ITP: dh-autoreconf -- debhelper add-on to call autoreconf and clean up after the build
On 31/03/2010 15:45, Mehdi Dogguy wrote: I do use autoreconf and I don't have these changes in my diff. Do you remove the modified files in your clean target ? (removed files will be ignored when creating the diff but you need to list them explicitely in debian/rules: this is what I do currently) Or do you never build your package twice in a row (ie called dpkg-buildpackage twice in the same directory) ? IMO, a backup/restore script (where you specify the list of files to backup) may be more useful. It would be called before build and when cleaning. The proposed solution avoid to explicitely list the modified files and avoid a backup of the full source tree. Regards, Vincent Cheers, -- Vincent Danjean GPG key ID 0x9D025E87 vdanj...@debian.org GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87 Unofficial packages: http://moais.imag.fr/membres/vincent.danjean/deb.html APT repo: deb http://perso.debian.org/~vdanjean/debian unstable main -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bb35553.7030...@free.fr
Bug#576018: ITP: narval -- An Ada framework for Distributed Acquisition Systems
Package: wnpp Severity: wishlist Owner: xavier xavier.gr...@ipno.in2p3.fr * Package name: narval Version : 1.10.1 Upstream Author : Xavier Grave xavier.gr...@ipno.in2p3.fr * URL : http://narval.in2p3.fr * License : GPL v2+ Programming Lang: Ada Description : An Ada framework for Distributed Acquisition Systems NARVAL is a framework that eases setting up of experimental data taking. It is written in Ada, enables users' plugins (written in C or C++). Using NARVAL, one can distribute many processes across network to take, process, store data online. Processes are of four types : producer (injects data in NARVAL framework), consumer (end of the data flow), intermediary (act as NxM switches) and stand alone actor (no data flow handling, can be used for survey). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100331131623.1568.51687.report...@alopex-lagopus.acq.ami
Re: Bug#575938: ITP: dh-autoreconf -- debhelper add-on to call autoreconf and clean up after the build
On Wed, 31 Mar 2010, Julian Andres Klode wrote: IMO, a backup/restore script (where you specify the list of files to backup) may be more useful. It would be called before build and when cleaning. I don't think so, it requires you to keep track of the files and you may miss some. OTOH, such a dh_backup could be integrated in debhelper since it would be a no-op unless you provide a list of files to backup/restore (and hence could be integrated in the default sequence without creating problems). Cheers, -- Raphaël Hertzog Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/ My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100331142841.gb2...@rivendell
Re: Bug#575938: ITP: dh-autoreconf -- debhelper add-on to call autoreconf and clean up after the build
Julian Andres Klode wrote: A 'debuild; debuild' should have a different result than a single debuild then. If you build from a clean directory, the first build will contain no changes. But after the build, the directory is not clean anymore and debian/rules clean does not do enough to keep the changes from appearing in the source package if you build again. I should have done that earlier (but didn't see the git repo, only now). I had a look at dh-autoreconf's code and the difference between what I do and what your script does is that I manually specify a list of files to monitor while you monitor all files. IMO, dh-autoreconf may be not specific to autoreconf but all same kind of tools and thus, can be enhanced by making, for example, the command to execute an argument which could be the command true (and keep autoreconf as a default) because, sometimes, it may be needed to make debian/autoreconf.after a bit later than just after executing autoreconf. Hopefully, we can do that by overriding the file. If you have these options, dh-autoreconf becomes nothing more than a call to autoreconf if we have dh_backup (name proposed by buxy in the same thread). dh_backup can be integrated to debhelper and all that remains to be done is a call to autoreconf (depending on the implementation of dh_backup). -- Mehdi Dogguy مهدي الدڤي http://dogguy.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bb36028.7020...@dogguy.org
Bug#576029: ITP: angband-audio -- Non-free sound files for the angband game
Package: wnpp Severity: wishlist Owner: Chris Carr ranting...@gmail.com * Package name: angband-audio Version : 3.1.0 Upstream Author : Dubtrain angb...@dubtrain.com * URL : http://www.dubtrain.com/angband * License : CC BY-NC-SA Programming Lang: n/a Description : Non-free sound files for the angband game Dubtrain has produced free high quality audio files for use with the angband package. His choice of licence means that they must be provided in Debian's non-free section. Since great efforts have been made to ensure that the main angband game can be provided under the GPL, it seems sensible to package the non-free sounds separately. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100331143027.17346.12476.report...@baba.sadnet
Re: About new source formats for packages without patches
Steve Langasek wrote: On Thu, Mar 25, 2010 at 02:03:09PM +0100, Raphael Hertzog wrote: [...] In the general case, switching is a small effort for sure, but in the case pointed out by Neil (he won't convert packages with no patches because he doesn't see the benefit) the effort is almost null, just create the file debian/source/format with 3.0 (quilt) and you're done. Aside from all the packaging tools that aren't quite there yet with 3.0 support, 3.0 packages break two cheap generic tools that I used to be able to use to inspect source packages: zless, and interdiff. While this loss doesn't outweigh the benefits, this is certainly not win-win, and I would appreciate it if you would try to be more understanding of developers' natural resistance to this change. Hi I recently created a script to diff two 3.0 source packages, which I am submitting to devscripts (see #575395). It is also able to diff 1.0 vs 3.0 (quilt) by converting the latter to an 1.0 like format and interdiff'ing them for you. If you are interested in it, you can prefetch it from [1]; I certainly could use some feedback on it. I will also be looking into providing a way to easily review a single 3.0 package (which would be #575394); suggestions are also welcome for that. ~Niels [1] Script: http://www.student.dtu.dk/~s072425/debian/qdebdiff Doc: http://www.student.dtu.dk/~s072425/debian/qdebdiff.html signature.asc Description: OpenPGP digital signature
Re: Bug#575938: ITP: dh-autoreconf -- debhelper add-on to call autoreconf and clean up after the build
On Wed, Mar 31, 2010 at 04:46:00PM +0200, Mehdi Dogguy wrote:
Julian Andres Klode wrote:
A 'debuild; debuild' should have a different result than a single
debuild then. If you build from a clean directory, the first build
will contain no changes. But after the build, the directory is not
clean anymore and debian/rules clean does not do enough to keep the
changes from appearing in the source package if you build again.
I should have done that earlier (but didn't see the git repo, only now). I
had a look at dh-autoreconf's code and the difference between what I do
and what your script does is that I manually specify a list of files to
monitor while you monitor all files.
IMO, dh-autoreconf may be not specific to autoreconf but all same kind of
tools and thus, can be enhanced by making, for example, the command to
execute an argument which could be the command true (and keep
autoreconf as a default) because, sometimes, it may be needed to make
debian/autoreconf.after a bit later than just after executing
autoreconf. Hopefully, we can do that by overriding the file.
The idea is that I want to keep debian/autoreconf.{before,after}
only related to the autoreconf run.
If you have these options, dh-autoreconf becomes nothing more than a call
to autoreconf if we have dh_backup (name proposed by buxy in the same
thread). dh_backup can be integrated to debhelper and all that remains to
be done is a call to autoreconf (depending on the implementation of
dh_backup).
A backup and restore approach is a completely different and more
complicated (in I/O sense) way than just deleting the files; e.g.
for a single file:
dh_backup:
1. mkdir() - Create the backup directory
2. read() - Read the original source
3. write() - Write the backup file
4. rename() - Rename backup to source
dh_autoreconf:
1. read() - Create md5sum before (unneeded if --mode=timesize)
2. read() - Create md5sum after (unneded if --mode=timesize)
3. unlink() - Unlink the changed file
Furthermore, the second read() in dh_autoreconf could also be in
the cache already.
--
Julian Andres Klode - Debian Developer, Ubuntu Member
See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.
pgpIEcWQ493Ey.pgp
Description: PGP signature
Advice needed on howto take care about /usr/share/pyshared/scikits
Dear Debianizers,
NB. I have asked similar question at debian-python [1] but had no
replies, so re-posting to -devel now
I am ITPing python-scikits-learn and possibly few other python-scikits-*
packages in the future. All of the packages would have 1 peculiarity,
they all would rely on having
$ cat /usr/share/pyshared/scikits/__init__.py
__import__('pkg_resources').declare_namespace(__name__)
As a resolution I am planing to package some silly Debian-native
(there is no per se the upstream for this single file) package
python-scikits-common
which would provide that base directory with __init__.py
Am I missing possible other alternative (I think that unpleasant and evil
diverts, or inappropriate for this case alternatives aren't real choices
here, right)?
[1] http://lists.debian.org/debian-python/2010/03/msg00034.html
--
.-.
=-- /v\ =
Keep in touch// \\ (yoh@|www.)onerussian.com
Yaroslav Halchenko /( )\ ICQ#: 60653192
Linux User^^-^^[17]
signature.asc
Description: Digital signature
Re: Hadoop in Debian, was:Re: Hardware trouble ries.debian.org
On Wed, Mar 31, 2010 at 2:42 PM, Thomas Koch tho...@koch.ro wrote: Joerg Jaspert: SNIP The only trouble this setup has is that you have a pretty huge expensive machine always on and running, but not actually doing stuff for 99.% of the time. /SNIP Hadoop is now in Debian: http://packages.qa.debian.org/h/hadoop.html Hadoop is an Open Source implementation of Google's File System, MapReduce and BigTable (HBase, not yet packaged). The idea behind Google's infrastructure and therefor Hadoop is: Have many cheap comodity servers that together form a powerful cluster. Each node of the cluster is redundant and can be replaced without downtime. I believe, but can't know for sure, that everything what FTP-Master does, could be implemented on top of hadoop. However it means for sure a lot of work and many hardcore sysadmins will feel very uncomfortable to use Java, the language Hadoop is written in. Isn't there /some/ python/jython support ? Would you co-mentor such a project as part of a Summer of Code project ? Do you know someone who would ? It need not be ftpmaster. There are probably other critical debian infrastructure which could use this. I'm planning to give a presentation of hadoop at the DebConf in Bosnia and maybe then we may discuss, if hadoop should have a place in Debian's infrastructure. - For now I'm happy, if somebody became curious. :-) http://en.wikipedia.org/wiki/Hadoop Best regards, Thomas Koch, http://www.koch.ro Cheers Arthur -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/g2vc09ddae71003310920icba0397au58fa97f4ebfb7...@mail.gmail.com
Re: Bug#575938: ITP: dh-autoreconf -- debhelper add-on to call autoreconf and clean up after the build
Julian Andres Klode wrote: A backup and restore approach is a completely different and more complicated (in I/O sense) way than just deleting the files; e.g. for a single file: … except that they do not operate on the same set of files. dh_backup's list would be a lot smaller than dh_autoreconf's one. Besides, dh_backup (or whatever its name is) could also delete files upon request (dh_backup --remove would then be dh_autoreconf minus autoreconf). dh_backup: 1. mkdir() - Create the backup directory you can use then debian/ directory here (provided you add a suffix to backup's name). And, dh_autoreconf also creates a directory for excluded files (if any). So, I don't think that this part is really relevant for the comparison. I think that all arguments in favour or against have been mentioned. I don't have anything to add. If it really makes you happy to have this package, then so be it :) Cheers, -- Mehdi Dogguy مهدي الدڤي http://dogguy.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bb37759.3070...@dogguy.org
Bug#576079: ITP: ngsolve -- Finite Element Library on top of Netgen
Package: wnpp Severity: wishlist Owner: trophime troph...@calcul8.lcmi.local * Package name: ngsolve Version : 4.9.12 Upstream Authors : Joachim Schöberl et al. * URL : http://www.mathcces.rwth-aachen.de/netgen/doku.php * License : LGPL Programming Lang: C++ Description : Finite Element Library on top of Netgen This package was part of netgen but is no longer distributed with netgen. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100331164329.5641.75607.report...@calcul8.lcmi.local
Bug#576080: general: missing ftp://ftp.upload.debian.org/pub/UploadQueue/README
Package: general Severity: normal We have moved UploadQueue to: ftp://ftp.upload.debian.org/pub/UploadQueue/ But new URL is missing ftp://ftp.upload.debian.org/pub/UploadQueue/README Thus poliy document has missing link. Osamu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100331164228.ga7...@osamu.debian.net
Re: Best practices for development workstations
Hi, On Mon, Mar 29, 2010 at 07:03:00PM -0500, John Goerzen wrote: 2a. pbuilder pbuilder, or some other chroot such as schroot, can help. In theory, it is a good plan. I don't have to dedicate a lot of RAM to it. The problem is that a chroot doesn't establish terribly strict separation from the main environment. Despite promises to the contrary, I've had weird things happen; for instance, an MTA, database server, or some other daemon process might try to fire up from within the chroot, which can result in highly confusing situations. I am therefore somewhat uncomfortable with this prospect. pbuilder sets up /usr/sbin/policy-rc.d to exit 101 so if a daemon starts out of your control (e.g. with /etc/init.d/daemon start) you have found a bug somewhere in a package, no? I've not seen daemons randomly starting lately. FWIW I'm using cowbuilder for the most used chroots as others have suggested and regular tar.gz with pbuilder for the less used chroots. The ability to easily rebuild a chroot is appealing. However, I do not have a fast mirror at home; my broadband connection is just barely broadband. pbuilder highly recommends a local or a fast mirror. So I am concerned about this approach for security reasons as well. I'm using apt-cacher-ng for both my laptop (sid) and the chroots I use to build packages in (lenny, squeeze, sid both x86 and x86-64) which has the nice side effect of being able to downgrade packages offline (and not keeping /var/cache/apt/archives/ around). 2b. Xen, KVM, qemu, or VirtualBox The advantage of this approach is that it provides more complete isolation from the host workstation. I need not worry about it firing up a second copy of cron, for instance. On the other hand, it will have less perfect integration with the host environment (though NFS and ssh could probably let me write a script like pdebuild). It will also consume more resources, and especially more RAM and disk space, neither of which can be as easily scaled up and down in this setup. On the side of isolation without too much overhead you could try also lxc with a recent kernel, it seems like a viable solution already. filippo -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100331083920.gm15...@esaurito.net
Re: Best practices for development workstations
[Filippo Giunchedi] pbuilder sets up /usr/sbin/policy-rc.d to exit 101 so if a daemon starts out of your control (e.g. with /etc/init.d/daemon start) you have found a bug somewhere in a package, no? I've not seen daemons randomly starting lately. Well, one point of a non-sid system with a sid chroot is to shield the host system from bugs in sid. And John is right that chroots are imperfect for this, and that the problems are not just theoretical but have happened many times in practice. I agree with you, though, that as a heavy user of pbuilder/cowbuilder, I haven't seen such problems on _my_ systems in a fairly long time. 2b. Xen, KVM, qemu, or VirtualBox The advantage of this approach is that it provides more complete isolation from the host workstation. I need not worry about it firing up a second copy of cron, for instance. On the other hand, it will have less perfect integration with the host environment (though NFS and ssh could probably let me write a script like pdebuild). These platforms support some form of hostfs, don't they? I thought they did, anyway. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100331183657.gw18...@p12n.org
Re: Hardware trouble ries.debian.org - ftpmaster.debian.org / release.d.o services disabled
Replying to three in one. Well, this would mean: a) double ftpmaster. Just as a rough number, the new machine that is currently in progress has an estimated cost of 2 Dollar (if you take prices from HP Website. This is not what it will cost in the end, but it shows what category of stuff we have to get) b) Have the double space at our hoster. c) Run it with heartbeat, drbd and all that. Point c) is actually easy enough, even though im not DSA and can't decide for them to do it. But technically it would be a working setup, provided b) works out, as you really want a *FAST* connection between the two. Which means local. Is there any way to build a distributed service instead of relying on one central machine (or two machines sitting next to each other)? Not currently, no. The actions in the archive can not split in a way this would make sense to place on various machines. That is, not those that are the important ones here (upload processing, mirrortree updating, that parts all around it). I don't know exactly what services are involved, but typically and generally, when I deploy a server infrastructure, I try to setup (at least) two machines at different geographical places that each can provide the entire service. ... The complexity in getting a heartbeat, drbd, etc solution to work can easily eat up any downtime savings you plan to get. It is actually a very easy setup and I am running multiple of them. The complexity is mainly in the double rackspace, double internet connection, *FAST* inter-machine connection, not in the bit drbd stuff. On 12071 March 1977, Guus Sliepen wrote: What is it that ftp-master does that can only run on one computer at a time? If most of the services it provides could be distributed, you could spread the load to multiple machines, and get redundancy at the same time. Thank you, we never thought of that... On 12071 March 1977, Thomas Koch wrote: Joerg Jaspert: SNIP The only trouble this setup has is that you have a pretty huge expensive machine always on and running, but not actually doing stuff for 99.% of the time. /SNIP Hadoop is now in Debian: http://packages.qa.debian.org/h/hadoop.htmlHadoop is an Open Source implementation of Google's File System, MapReduce and BigTable (HBase, not yet packaged). The idea behind Google's infrastructure and therefor Hadoop is: Have many cheap comodity servers that together form a powerful cluster. Each node of the cluster is redundant and can be replaced without downtime. I believe, but can't know for sure, that everything what FTP-Master does, could be implemented on top of hadoop. However it means for sure a lot of work and many hardcore sysadmins will feel very uncomfortable to use Java, the language Hadoop is written in. I'm planning to give a presentation of hadoop at the DebConf in Bosnia and maybe then we may discuss, if hadoop should have a place in Debian's infrastructure. - For now I'm happy, if somebody became curious. :-) The idea behind hadoop and stuff is certainly a nice one. Yet, I do believe it has an entirely different target and can not easily be adopted to the tasks ftp-master does. There simply are things you can not, in a sensible way, make distributed. On 12071 March 1977, Obey Arthur Liu wrote: Isn't there /some/ python/jython support ? Would you co-mentor such a project as part of a Summer of Code project ? Do you know someone who would ? It need not be ftpmaster. There are probably other critical debian infrastructure which could use this. I do not think changing dak and all it does to hadoop and distributed is possible within gsoc. Nor within ten of it. I wont block any who tries though, so have fun. :) -- bye, Joerg andreasj Also diese neuen Spam-Mails muten an wie Blog-Posts von Clint Adams andreasj irgendwie ist es eine Geschichte, aber ich versteh sie nicht -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87bpe471t0@gkar.ganneff.de
Bug#576088: ITP: libphp-swiftmailer -- component-based library for sending e-mails
Package: wnpp Severity: wishlist Owner: Nicolas Roudaire nikro...@gmail.com Owner: Nicolas Roudaire nikro...@gmail.com * Package name: libphp-swiftmailer Version : 4.0.6 Upstream Author : Chris Corbyn * URL : http://swiftmailer.org/ * License : LGPL Programming Lang: PHP Description : component-based library for sending e-mails Swift Mailer is component based mailing solution for PHP 5 Send emails using SMTP, sendmail, postfix or a custom Transport implementation of your own. It Supports servers that require username and password and/or encryption. . Features: - SMTP authentication - event-driven plugins to customize the library - MIME compliant HTML/multipart emails - large attachments and inline/embedded images with low memory use -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100331190442.6704.79337.report...@localhost
Re: Bug#575938: ITP: dh-autoreconf -- debhelper add-on to call autoreconf and clean up after the build
Julian Andres Klode wrote: Is there any advantage to have it packaged? AIUI, you have to add a build-dependency anyway and change at least one line in the debian/rules to call dh-autoreconf. Well, that line could simply call autoreconf (or whatever) which even makes debian/rules clearer. The difference is that dh_autoreconf calls autoreconf and stores a list of the changes and the changed files are then removed in the clean target. If you just call autoreconf, the changes end up in the diff; and this is not what we want. Indeed. I recently just implemented a similar but less sophisticated feature for one of my packages by more or less copying away all relevant files and restoring them in the clean target. I'd really like to see such a feature in Debian! Regards, Axel -- ,''`. | Axel Beckert a...@debian.org, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE `-| 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100331195526.gy3...@sym.noone.org
Re: Best practices for development workstations
On Wed, Mar 31, 2010 at 08:46:01AM +0100, Holger Levsen wrote: On Dienstag, 30. März 2010, Marco Túlio Gontijo e Silva wrote: squid! (Or any other normal http proxy. I don't recommend any apt-proxy solution...) Can you explain why? apt-proxy had issues when I tried (as well as others, which I cannot rememeber now), approx iirc requires to changes /etc/apt/sources list, squid always worked for me and never had issues, squid is useful for more then just proxying apt repositories, squid can be set up as a transparent proxy quite easily, updating a full/partial mirror usually takes more bandwidth then just using a proxy. Among specific deb repos proxies, people seem to be happy with apt-cacher-ng (at least on debian-mirr...@ldo), and popcon confirms this impression (best progression): http://qa.debian.org/popcon-graph.php?packages=apt-cacher-ng%2Capt-cacher%2Capprox%2Capt-proxy%2Cdebmirror%2Capt-mirrorshow_vote=onwant_legend=onwant_ticks=onbeenhere=1 -- Simon Paillard -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100331204738.gk1...@dedibox.ebzao.info
Processed: reassign 576080 to ftp.debian.org
Processing commands for cont...@bugs.debian.org: reassign 576080 ftp.debian.org Bug #576080 [general] general: missing ftp://ftp.upload.debian.org/pub/UploadQueue/README Bug reassigned from package 'general' to 'ftp.debian.org'. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.127006787428464.transcr...@bugs.debian.org
Re: Hadoop in Debian, was:Re: Hardware trouble ries.debian.org
This one time, at band camp, Obey Arthur Liu said: On Wed, Mar 31, 2010 at 2:42 PM, Thomas Koch tho...@koch.ro wrote: I believe, but can't know for sure, that everything what FTP-Master does, could be implemented on top of hadoop. However it means for sure a lot of work and many hardcore sysadmins will feel very uncomfortable to use Java, the language Hadoop is written in. Isn't there /some/ python/jython support ? Would you co-mentor such a project as part of a Summer of Code project ? Do you know someone who would ? It need not be ftpmaster. There are probably other critical debian infrastructure which could use this. Hadoop is not a POSIX file system, as far as I'm aware. As ftp-master makes heavy use of things like file locks and hard links, I doubt hadoop would work without a significant rewrite of the software. It would probably be helpful to take a look at the dak codebase before coming up with other solutions to this - any sort of clustering has to take the software that actually runs the archive into account. Cheers, -- - | ,''`.Stephen Gran | | : :' :sg...@debian.org | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100331224108.ga9...@varinia.lobefin.net
Re: About new source formats for packages without patches
On 30 March 2010 16:46, Sven Mueller deb...@incase.de wrote: My main reason for not yet switching is that hg-buildpackage and svn-buildpackage don't completely support the 3.0 format yet as far as I can tell. You can try out mercurial-buildpackage, where I have tried to support 3.0 (quilt) as good as I could: the default branch contains the fully patched source code as well as the explicit debian/patches. That way you can just hack away anywhere in your package and repeatedly run mercurial-buildpackage until you are satisfied, and then finally rename the dpkg-source autogenerated patch to something meaningful. But I would like to hear suggestions for improvements... Ohh, and thanks to Raphael Hertzog for doing all the hard work on the new formats! Cheers, -- Jens Peter Secher. _DD6A 05B0 174E BFB2 D4D9 B52E 0EE5 978A FE63 E8A1 jpsecher gmail com_. A. Because it breaks the logical sequence of discussion. Q. Why is top posting bad? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/x2wc4f47b5b1003311704w73e6efafha33f5ecfd4d88...@mail.gmail.com
Bug#576128: ITP: otcl -- an extension to Tcl/Tk for object-oriented programming
Package: wnpp Severity: wishlist Owner: syq wzss...@gmail.com * Package name: otcl Version : 1.13 Upstream Author : David Wetherall d...@lcs.mit.edu * URL : http://otcl-tclcl.sourceforge.net/otcl/ * License : BSD, MIT/X Programming Lang: C, TCL Description : an extension to Tcl/Tk for object-oriented programming OTcl, short for MIT Object Tcl, is an extension to Tcl/Tk for object-oriented programming. It shouldn't be confused with the IXI Object Tcl extension by Dean Sheenan. (Sorry, but we both like the name and have been using it for a while.) . Some of OTcl's features as compared to alternatives are: designed to be dynamically extensible, like Tcl, from the ground up builds on Tcl syntax and concepts rather than importing another language compact yet powerful object programming system fairly portable implementation (2000 lines of C, without core hacks) . OTcl was created by David Wetherall as part of the VUsystem project at MIT. Since 1997, OTcl has been maintained as part of the Mash and VINT/ns efforts (with David's blessing). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100401045253.9745.24543.report...@syq-laptop
