Re: Misc developer news (#21)
On Fri, 19 Feb 2010 18:51:11 +0100, Raphael Hertzog wrote: >On Fri, 19 Feb 2010, Marc Haber wrote: >> On Fri, Feb 19, 2010 at 12:08:16PM +0100, Raphael Hertzog wrote: >> > * More than 1000 source packages[4] are already using the new source >> > formats "3.0 (quilt)" and "3.0 (native)". Have you updated your own >> > packages already? >> >> Why should I? > >http://wiki.debian.org/Projects/DebSrc3.0#WhyshouldIconvertmypackageto3.0.28quilt.29format.3F I don't see any valid reason to convert packages which already use a patch system such as dpatch to the new thing. Debian is in dire need of manpower taking care of our core infrastructure, converting dpatch-based packages to quilt is a total waste of manpower. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834 -- 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/e1nikiw-00070m...@swivel.zugschlus.de
Re: Misc developer news (#21)
Marc Haber writes: > I don't see any valid reason to convert packages which already use a > patch system such as dpatch to the new thing. Debian is in dire need > of manpower taking care of our core infrastructure, converting > dpatch-based packages to quilt is a total waste of manpower. This ignores the drain on manpower represented by maintaining disparate patch systems. To the contrary, I expect having Quilt as a common patch format will make application of existing manpower more efficient. -- \ “Courage is resistance to fear, mastery of fear — not absence | `\ of fear.” —Mark Twain, _Pudd'n'head Wilson_ | _o__) | 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/87tytc727l@benfinney.id.au
Re: Misc developer news (#21)
On Sat, Feb 20, 2010 at 09:03:10AM +0100, Marc Haber wrote: > On Fri, 19 Feb 2010 18:51:11 +0100, Raphael Hertzog > wrote: > >On Fri, 19 Feb 2010, Marc Haber wrote: > >> On Fri, Feb 19, 2010 at 12:08:16PM +0100, Raphael Hertzog wrote: > >> > * More than 1000 source packages[4] are already using the new source > >> > formats "3.0 (quilt)" and "3.0 (native)". Have you updated your own > >> > packages already? > >> > >> Why should I? > > > >http://wiki.debian.org/Projects/DebSrc3.0#WhyshouldIconvertmypackageto3.0.28quilt.29format.3F > > I don't see any valid reason to convert packages which already use a > patch system such as dpatch to the new thing. Debian is in dire need > of manpower taking care of our core infrastructure, converting > dpatch-based packages to quilt is a total waste of manpower. If your dpatches are simply patches and not scripts, converting to 3.0 (quilt) is a few minutes job: rename the files, rename 00list to series, adapt its content, remove your patch system from debian/rules, change the build-deps accordingly, write a debian/source/format file containing 3.0 (quilt). Done. Mike -- 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/20100220082514.ga30...@glandium.org
Re: Changes in dpkg Pre-Depends
On Sat, Feb 20, 2010 at 12:15:10AM +0100, Guillem Jover wrote:
> First, I'd like to change the dpkg Pre-Depends from lzma to xz-utils,
> the latter is a bit bigger in size (lzma 172 KiB; xz-utils 504 KiB,
> 160 KiB in share/doc/ and liblzma2 304 KiB, 124 KiB in share/doc/) but
This just seems the obvious right thing™ to do, given the fate of lzma
itself.
> Second, I'd like to switch from statically to dynamically linking
> against zlib and libbz2, eventually liblzma too (affecting dpkg-deb)
> and libselinux (affecting dpkg itself only on Linux). Here's the
> arguments I know of against and in favour, with rebuttals:
I'm personally convinced by your arguments. Still, I'd like if you
consider the transitional idea of having---say, for a release---two
different binary packages shipping dpkg: "dpkg" (essential: yes) and
"dpkg-static" (essential: no), the latter containing a fully statically
linked version of dpkg, coming as /usr/bin/dpkg-static.
I've seen this for other safety-critical tools, e.g. the dar backup tool
which comes both as "dar" and "dar-static". I personally don't believe
there would be *much* use of "dpkg-static", but having it around for a
release would enable to see if/how many (paranoid) people actually
install it. Would that make sense in your opinion? Would it be worth?
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
converting from dpatch to quilt (was: Misc developer news (#21))
On Saturday 20 February 2010, Mike Hommey wrote: > > I don't see any valid reason to convert packages which already > > use a patch system such as dpatch to the new thing. Debian is in > > dire need of manpower taking care of our core infrastructure, > > converting dpatch-based packages to quilt is a total waste of > > manpower. > > If your dpatches are simply patches and not scripts, converting to > 3.0 (quilt) is a few minutes job: rename the files, rename 00list > to series, adapt its content, remove your patch system from > debian/rules, change the build-deps accordingly, write a > debian/source/format file containing 3.0 (quilt). Done. BTW, does anybody have suggestions how to handle cases where the dpatches are scripts? For example 1) patch some files, including foo.c 2) copy foo.c to bar.c 3) patch bar.c some more 4) build (using both foo.c and bar.c) Do I have to reimplement a patch system for 3) in my rules file or can I somehow also use quilt for that, too? Or would it be best to simply keep dpatch? Disclaimer: My experience with quilt so far is limited to adding new patches to existing packages. Cheers, Stefan -- 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/201002201054.18170...@sfritsch.de
Re: klibc only initramfs
Goswin von Brederlow wrote: > Hi, > > I googled a bit and found this old mail about a klibc only initramfs: > > http://lists.debian.org/debian-kernel/2006/07/msg00400.html > > I would really like to do this and it has been close to 4 years since > that mail. But it doesn't look like there has been much progress or not > in the right direction. Looking at my initramfs I see: > > % ls lib > cryptsetup/libm.so.6 > klibc-zUXi_KjK5ZQAIyc8jlwme9T6a4U.so* libncurses.so.5 > ld-linux.so.2* libpopt.so.0 > libc.so.6* libreadline.so.5 > libcfont.so.0 libselinux.so.1 > libconsole.so.0libuuid.so.1 > libctutils.so.0libvolume_id.so.0 > libdevmapper.so.1.02.1 modules/ > libdl.so.2 udev/ Apparently the initramfs contains _two_ different libc implementations. ... [] > Could we build stripped down versions of those tools (and libs as > required) build against klibc? I certainly see no need for ncurses in my > initramfs. Building a klibc based initramfs that then includes libc6 > (and even busybox) as well seems rather stupid. One without klibc would > be smaller then. May I ask this question the other way around: Why maintain two sets of tools and libraries while one set is more than enough already? Why we need/want klibc to start with, while regular glibc and regular tools do the work just fine? I use glibc-based initramfs (with busybox) since first days when initramfs were introduced in kernel. I booted even the less capable machines (i486 with 16Mb memory) with it without any issues. I don't see any reason to maintain another set of tools just for initramfs. In previous life there was an argument about whole thing fitting a single floppy drive. But nowadays a) floppies are gone, and b) kernel itself does not fit in a floppy anymore. Also, I heard people saying that klibc-based initramfs is somehow faster than glibc-based. Maybe this is partially true, because the bigger the initramfs is, the more time it requires to load by a relatively dumb and slow boot loader (esp. for slow network-based boots). But even here, in most cases the difference is small and does not justify the amount of work needed to support the second set of tools/libraries. Just an opinion /mjt -- 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/4b7fb03d.2090...@msgid.tls.msk.ru
Re: converting from dpatch to quilt
Stefan Fritsch writes: > On Saturday 20 February 2010, Mike Hommey wrote: >> > I don't see any valid reason to convert packages which already >> > use a patch system such as dpatch to the new thing. Debian is in >> > dire need of manpower taking care of our core infrastructure, >> > converting dpatch-based packages to quilt is a total waste of >> > manpower. >> >> If your dpatches are simply patches and not scripts, converting to >> 3.0 (quilt) is a few minutes job: rename the files, rename 00list >> to series, adapt its content, remove your patch system from >> debian/rules, change the build-deps accordingly, write a >> debian/source/format file containing 3.0 (quilt). Done. > > BTW, does anybody have suggestions how to handle cases where the > dpatches are scripts? For example > > 1) patch some files, including foo.c > 2) copy foo.c to bar.c > 3) patch bar.c some more > 4) build (using both foo.c and bar.c) > > Do I have to reimplement a patch system for 3) in my rules file or can > I somehow also use quilt for that, too? Or would it be best to simply > keep dpatch? > > Disclaimer: My experience with quilt so far is limited to adding new > patches to existing packages. > > Cheers, > Stefan Keep your patch system and document it properly. You can mix this to some degree if you mv debian/patches debian/dpatches (or any other name) but I think mixing patch systems will be even more confusing. MfG Goswin -- 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/87r5og6vtc@frosties.localdomain
Request for volunteers for symfony packaging
Hi all, I'm in the process of packaging the 1.4 branch of symfony [1], [2], an open source php framework for creating web applications. It embeds copies of code of php-based software not present in the archive, in particular propel, doctrine, swift and phing. I am currently working in one of them [3] and it would be great to get some help with the others. Moreover, the symfony package itself is quite complex and it could be better to comaintain it than to try to do it on my own. So, what do you think, is someone interested in teamup at alioth to take care of this, and related, packages? There have been efforts to package previous branches of symfony [4], [5] and, recently, the maintainer of the 1.0 branch has filed an RFA [6], perhaps the group could manage other branches as well. Any thoughts are more than welcome. Cheers, Federico [1] http://bugs.debian.org/562167 [2] http://mentors.debian.net/debian/pool/main/s/symfony1.4/symfony1.4_1.4.1-1.dsc [3] http://bugs.debian.org/568501 [4] http://bugs.debian.org/513646 [5] http://bugs.debian.org/533343 [6] http://bugs.debian.org/568737 -- 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/4a79814f1002200227r869ca1ercdbb370b8d978...@mail.gmail.com
Re: klibc only initramfs
Michael Tokarev writes: > Goswin von Brederlow wrote: >> Hi, >> >> I googled a bit and found this old mail about a klibc only initramfs: >> >> http://lists.debian.org/debian-kernel/2006/07/msg00400.html >> >> I would really like to do this and it has been close to 4 years since >> that mail. But it doesn't look like there has been much progress or not >> in the right direction. Looking at my initramfs I see: >> >> % ls lib >> cryptsetup/libm.so.6 >> klibc-zUXi_KjK5ZQAIyc8jlwme9T6a4U.so* libncurses.so.5 >> ld-linux.so.2* libpopt.so.0 >> libc.so.6* libreadline.so.5 >> libcfont.so.0 libselinux.so.1 >> libconsole.so.0libuuid.so.1 >> libctutils.so.0libvolume_id.so.0 >> libdevmapper.so.1.02.1 modules/ >> libdl.so.2 udev/ > > Apparently the initramfs contains _two_ different libc implementations. > ... > > [] >> Could we build stripped down versions of those tools (and libs as >> required) build against klibc? I certainly see no need for ncurses in my >> initramfs. Building a klibc based initramfs that then includes libc6 >> (and even busybox) as well seems rather stupid. One without klibc would >> be smaller then. > > May I ask this question the other way around: > > Why maintain two sets of tools and libraries while one set is more > than enough already? Why we need/want klibc to start with, while > regular glibc and regular tools do the work just fine? > > I use glibc-based initramfs (with busybox) since first days when > initramfs were introduced in kernel. I booted even the less capable > machines (i486 with 16Mb memory) with it without any issues. I don't > see any reason to maintain another set of tools just for initramfs. > > In previous life there was an argument about whole thing fitting a > single floppy drive. But nowadays a) floppies are gone, and b) > kernel itself does not fit in a floppy anymore. > > Also, I heard people saying that klibc-based initramfs is somehow > faster than glibc-based. Maybe this is partially true, because the > bigger the initramfs is, the more time it requires to load by a > relatively dumb and slow boot loader (esp. for slow network-based > boots). But even here, in most cases the difference is small and > does not justify the amount of work needed to support the second > set of tools/libraries. > > Just an opinion > > /mjt The reason would be size. I don't see anything else there. For network based boots, specifically high performance cluster, the size can make a real difference. When you turn the cluster on it is not just one system downloading an extra meg but 100+ nodes. That largely increases the network collisions, errors and dropped packages. Something that can even make systems fail to boot. MfG Goswin -- 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/87bpfk6ugv@frosties.localdomain
Re: Misc developer news (#21)
Hi, On Fri Feb 19, 2010 at 18:51:11 +0100, Raphael Hertzog wrote: > On Fri, 19 Feb 2010, Marc Haber wrote: > > On Fri, Feb 19, 2010 at 12:08:16PM +0100, Raphael Hertzog wrote: > > > * More than 1000 source packages[4] are already using the new source > > > formats "3.0 (quilt)" and "3.0 (native)". Have you updated your own > > > packages already? > > > > Why should I? > > http://wiki.debian.org/Projects/DebSrc3.0#WhyshouldIconvertmypackageto3.0.28quilt.29format.3F This wiki page still misses a "Disadvantages of new format" section. Greetings Martin -- Martin Zobel-Helas | Debian System Administrator Debian & GNU/Linux Developer | Debian Listmaster Public key http://zobel.ftbfs.de/5d64f870.asc - KeyID: 5D64 F870 GPG Fingerprint: 5DB3 1301 375A A50F 07E7 302F 493E FB8E 5D64 F870 -- 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/20100220112658.ga23...@ftbfs.de
Re: Misc developer news (#21)
Mike Hommey schrieb am Saturday, den 20. February 2010: > On Sat, Feb 20, 2010 at 09:03:10AM +0100, Marc Haber wrote: > > On Fri, 19 Feb 2010 18:51:11 +0100, Raphael Hertzog > > wrote: > > >On Fri, 19 Feb 2010, Marc Haber wrote: > > >> On Fri, Feb 19, 2010 at 12:08:16PM +0100, Raphael Hertzog wrote: > > >> > * More than 1000 source packages[4] are already using the new source > > >> > formats "3.0 (quilt)" and "3.0 (native)". Have you updated your own > > >> > packages already? > > >> > > >> Why should I? > > > > > >http://wiki.debian.org/Projects/DebSrc3.0#WhyshouldIconvertmypackageto3.0.28quilt.29format.3F > > > > I don't see any valid reason to convert packages which already use a > > patch system such as dpatch to the new thing. Debian is in dire need > > of manpower taking care of our core infrastructure, converting > > dpatch-based packages to quilt is a total waste of manpower. > > If your dpatches are simply patches and not scripts, converting to 3.0 > (quilt) is a few minutes job: rename the files, rename 00list to series, > adapt its content, remove your patch system from debian/rules, change > the build-deps accordingly, write a debian/source/format file containing > 3.0 (quilt). Done. I think dpatch is much easier to use and simpler to debug than quilt (yes I use both systems). So I still don't see a reason to convert. For many packages (one upstream, already working patch system) converting to quilt just means more work. source 3.0 (quilt) is still missing tools to make it working out of the box. If you quilt not only in debian packages its fucking annoying that you need to change to patch of your patches from patches/ to debian/patches depending on what you are working on. IMHO 3.0 would have been much more successfull if it wouldn't have called quilt and dpkg would have all tools needed to work with the system (push, pop, create patch and so on). The way it is now, I don't see a reason to invest the extra work. Just my 2 cent Alex -- 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/20100220113343.ga20...@apu.snow-crash.org
Re: klibc only initramfs
On Feb 20, Goswin von Brederlow wrote: > For network based boots, specifically high performance cluster, the size > can make a real difference. When you turn the cluster on it is not just > one system downloading an extra meg but 100+ nodes. That largely > increases the network collisions, errors and dropped packages. Something > that can even make systems fail to boot. Goswin, meet mtftp. mtftp, meet Goswin. Also: if the network fabric of your cluster cannot handle an extra 100 MB of boot downloads then it looks badly broken to me. Do you have any better argument or at least better data? If nobody does, then I agree with Michael than klibc should be dropped (this way we *would* save space...). -- ciao, Marco signature.asc Description: Digital signature
Re: Misc developer news (#21)
Alexander Wirt schrieb am Saturday, den 20. February 2010: > Mike Hommey schrieb am Saturday, den 20. February 2010: > > > On Sat, Feb 20, 2010 at 09:03:10AM +0100, Marc Haber wrote: > > > On Fri, 19 Feb 2010 18:51:11 +0100, Raphael Hertzog > > > wrote: > > > >On Fri, 19 Feb 2010, Marc Haber wrote: > > > >> On Fri, Feb 19, 2010 at 12:08:16PM +0100, Raphael Hertzog wrote: > > > >> > * More than 1000 source packages[4] are already using the new > > > >> > source > > > >> > formats "3.0 (quilt)" and "3.0 (native)". Have you updated your > > > >> > own > > > >> > packages already? > > > >> > > > >> Why should I? > > > > > > > >http://wiki.debian.org/Projects/DebSrc3.0#WhyshouldIconvertmypackageto3.0.28quilt.29format.3F > > > Please forget my previous mail, after reading it again I detected some lack of coffee in my english (in fact weasel detected it). So let me rephrase my thoughts. Currently I don't see much reasons to convert most 1.0 packages to 3.0. I don't see any advantages for packages which already have a patchsystem and which only have one upstream source. I'm still looking for reasons to convert to 3.0. Things would be much easier for starters if dpkg would ship its own patch helpers like push, pop and create patch. A 3.0 format which is working out of the box without installing quilt and without the need to set QUILT_PATCHES would be a real benefit for everybody. Also the dpkg maintainer shouldn't beg maintainers to switch 3.0. If the format has advantages and works without problems people will switch automatically. And the last thing I want to see is that NMUs (or binNMUs) convert a package to 3.0 unless the maintainer explicitly agreed to it. Alex -- 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/20100220120755.gb20...@apu.snow-crash.org
Re: klibc only initramfs
On Sat, Feb 20, 2010 at 12:02:24PM +0100, Goswin von Brederlow wrote: > Michael Tokarev writes: > > Goswin von Brederlow wrote: > >> I googled a bit and found this old mail about a klibc only initramfs: > >> > >> http://lists.debian.org/debian-kernel/2006/07/msg00400.html > >> > >> I would really like to do this and it has been close to 4 years since > >> that mail. But it doesn't look like there has been much progress or not > >> in the right direction. Looking at my initramfs I see: [...] > >> Could we build stripped down versions of those tools (and libs as > >> required) build against klibc? I certainly see no need for ncurses in my > >> initramfs. Building a klibc based initramfs that then includes libc6 > >> (and even busybox) as well seems rather stupid. One without klibc would > >> be smaller then. > > > > May I ask this question the other way around: > > > > Why maintain two sets of tools and libraries while one set is more > > than enough already? Why we need/want klibc to start with, while > > regular glibc and regular tools do the work just fine? [...] > The reason would be size. I don't see anything else there. How about another idea: take advantage of our switch to eglibc and offer a stripped-down (no i18n, unicode, funky string handling, whatever) flavour of glibc which could be used in place for this. Another use-case might be the udeb for debian-installer (though I guess i18n is important there). Maybe this has been pondered already or maybe it is already in place, CCing -glibc. Michael -- 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/20100220122448.gb21...@nighthawk.chemicalconnection.dyndns.org
Re: Misc developer news (#21)
On Sat, 20 Feb 2010 09:25:14 +0100, Mike Hommey wrote: > > I don't see any valid reason to convert packages which already use a > > patch system such as dpatch to the new thing. Debian is in dire need > > of manpower taking care of our core infrastructure, converting > > dpatch-based packages to quilt is a total waste of manpower. > If your dpatches are simply patches and not scripts, converting to 3.0 > (quilt) is a few minutes job: rename the files, rename 00list to series, > adapt its content, remove your patch system from debian/rules, change > the build-deps accordingly, write a debian/source/format file containing > 3.0 (quilt). Done. Or run /usr/share/doc/quilt/examples/dpatch2quilt.sh to cover the first steps (i.e. not the format 3.0). Cheers, gregor -- .''`. http://info.comodo.priv.at/ -- GPG Key IDs: 0x8649AA06, 0x00F3CFE4 : :' : Debian GNU/Linux user, admin, & developer - http://www.debian.org/ `. `' Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe `-NP: Peter Ratzenbeck: Avalon signature.asc Description: Digital signature
Bug#570644: ITP: virtualenvwrapper -- extension to virtualenv for managing multiple virtual Python environments
Package: wnpp Severity: wishlist Owner: Jan Dittberner * Package name: virtualenvwrapper Version : 1.24.2 Upstream Author : Doug Hellmann * URL : http://www.doughellmann.com/projects/virtualenvwrapper/ * License : ISC Programming Lang: Python Description : extension to virtualenv for managing multiple virtual Python environments virtualenvwrapper is a set of extensions to Ian Bicking's virtualenv tool. The extensions include wrappers for creating and deleting virtual environments and otherwise managing your development workflow, making it easier to work on more than one project at a time without introducing conflicts in their dependencies. signature.asc Description: Digital signature
Re: Misc developer news (#21)
On Sat, 20 Feb 2010, Alexander Wirt wrote: > Things would be much easier for starters if dpkg would ship its own patch > helpers like push, pop and create patch. A 3.0 format which is working out of > the box without installing quilt and without the need to set QUILT_PATCHES > would be a real benefit for everybody. quilt will be working out-of-the box on unpacked 3.0 (quilt) with the next dpkg release, see http://bugs.debian.org/557619 for details. dpkg-source will create .pc/.quilt_patches and .pc/.quilt_series to indicate where the patches and series are stored. Thus you don't need to set QUILT_PATCHES in that case. Furthermore, if you let dpkg-source create the first patch (debian-changes-) quilt will also be autoconfigured for you (you can then use quilt to rename the patch). > And the last thing I want to see is that NMUs (or binNMUs) convert a > package to 3.0 unless the maintainer explicitly agreed to it. There nothing like that planned. I haven't decided yet if I will change dpkg-source to build 3.0 (quilt) by default at some point or not. It will depend on how many package have an explicit debian/source/format, that's also a reason why I requested the lintian tag. Feedback welcome at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=557459 and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=553928 BTW a binNMU do not rebuild the source package so it can't convert them. 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/2010022013.gc10...@rivendell
Re: Changes in dpkg Pre-Depends
On Feb 20, Stefano Zacchiroli wrote: > I've seen this for other safety-critical tools, e.g. the dar backup tool > which comes both as "dar" and "dar-static". I personally don't believe > there would be *much* use of "dpkg-static", but having it around for a > release would enable to see if/how many (paranoid) people actually > install it. Would that make sense in your opinion? Would it be worth? I don't think so. Can you think of some real life disaster scenarios which would benefit from a static dpkg? And in that case, why it would not be simpler to copy the dpkg binary and the few libraries it depends on from another system? -- ciao, Marco signature.asc Description: Digital signature
Re: Misc developer news (#21)
On Sat, 20 Feb 2010, Martin Zobel-Helas wrote: > Hi, > > On Fri Feb 19, 2010 at 18:51:11 +0100, Raphael Hertzog wrote: > > On Fri, 19 Feb 2010, Marc Haber wrote: > > > On Fri, Feb 19, 2010 at 12:08:16PM +0100, Raphael Hertzog wrote: > > > > * More than 1000 source packages[4] are already using the new source > > > > formats "3.0 (quilt)" and "3.0 (native)". Have you updated your own > > > > packages already? > > > > > > Why should I? > > > > http://wiki.debian.org/Projects/DebSrc3.0#WhyshouldIconvertmypackageto3.0.28quilt.29format.3F > > This wiki page still misses a "Disadvantages of new format" section. It's a wiki, feel free to add it. I know some people unhappy with the new format but I don't know many technical disadvantages. 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/20100220132516.gd10...@rivendell
Re: Misc developer news (#21)
Hi Alexander. Excerpts from Alexander Wirt's message of Sáb Fev 20 10:07:55 -0200 2010: > Alexander Wirt schrieb am Saturday, den 20. February 2010: (...) > > > > >http://wiki.debian.org/Projects/DebSrc3.0#WhyshouldIconvertmypackageto3.0.28quilt.29format.3F > > > > > And the last thing I want to see is that NMUs (or binNMUs) > convert a package to 3.0 unless the maintainer explicitly agreed to it. The pages suggests the maintainer to do the conversion so that, if someone wants include a patch in a NMU, (s)he won't need to change the build system. It's not suggesting that people should convert the package when doing NMUs. Greetings. -- marcot http://marcot.iaaeee.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/1266672758-sup-3...@zezinho
Re: klibc only initramfs
On 2010-02-20, Goswin von Brederlow wrote: > For network based boots, specifically high performance cluster, the size > can make a real difference. When you turn the cluster on it is not just > one system downloading an extra meg but 100+ nodes. That largely > increases the network collisions, errors and dropped packages. Something > that can even make systems fail to boot. Network collisions? That sounds so half duplex and wrong to me. Nowadays we have switches. Kind regards, Philipp Kern -- 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/slrnhnvq19.6s4.tr...@kelgar.0x539.de
Bug#570673: ITP: enforcer -- Maven build rule execution framework
Package: wnpp Severity: wishlist Owner: Gabriele Giacone <1o5g4...@gmail.com> * Package name: enforcer Version : 1.0~beta2 Upstream Author : Brian Fox * URL : http://maven.apache.org/enforcer/ * License : Apache 2.0 Programming Lang: java Description : Maven build rule execution framework Enforcer is a Maven build rule execution framework. Maven Enforcer Plugin provides goals to control certain environmental constraints such as Maven version, JDK version and OS family along with many more standard rules: * alwaysPass - Always passes... used to test plugin configuration. * alwaysFail - Always fail... used to test plugin configuration. * bannedDependencies - enforces that excluded dependencies aren't included. * evaluateBeanshell - evaluates a beanshell script. * requireReleaseDeps - enforces that no snapshots are included as dependencies. * requireReleaseVersion - enforces that the artifact is not a snapshot. * requireMavenVersion - enforces the Maven version. * requireJavaVersion - enforces the JDK version. * requireOS - enforces the OS / CPU Archictecture. * requirePluginVersions - enforces that all plugins have a specified version. * requireProperty - enforces the existence and values of properties. * requireFilesDontExist - enforces that the list of files do not exist. * requireFilesExist - enforces that the list of files do exist. * requireFilesSize - enforces that the list of files exist and are within a certain size range. Custom rules are easy to make with the maven-enforcer-rule-api. -- 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/20100220163455.10927.172.report...@phenomenon.
How to track patches and debian versions of packages
Hello. In the process of converting my packages to the new 3.0 source format, I'd like to log somewhere that a certain patch was applied for the first time in a certain debian version of a given package. Is there a DEP3 header for that, or maybe such information is not supposed to be in the patches themselves? May I use "X-whatever:" for non-standard headers, in the RFC2822 spirit? Thanks. -- 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/pine.lnx.4.64.1002201816570.13...@cantor.unex.es
Bug#570691: ITP: libstatistics-online-perl -- pure Perl implementation of the on-line algorithm to produce statistics
Package: wnpp Severity: wishlist Owner: Joenio Costa * Package name: libstatistics-online-perl Version : 0.02 Upstream Author : Francesco Nidito * URL : http://search.cpan.org/dist/Statistics-OnLine/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : pure Perl implementation of the on-line algorithm to produce statistics Statistics::OnLine implements a tool to perform statistic operations on large datasets which, typically, could not fit the memory of the machine, e.g. a stream of data from the network. -- 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/20100220183618.5371.27878.report...@case.neuromancer
Re: How to track patches and debian versions of packages
On Sat, 20 Feb 2010, Santiago Vila wrote: > Hello. > > In the process of converting my packages to the new 3.0 source format, > I'd like to log somewhere that a certain patch was applied for the > first time in a certain debian version of a given package. > > Is there a DEP3 header for that, or maybe such information is not > supposed to be in the patches themselves? There's no dedicated field for that but I suppose you can put it in the description if you wish. Note however that I expect the maintainer adding a new patch to say it explicitly in the changelog. Of course editing old entries to give the new name of the patch file might be overkill however. > May I use "X-whatever:" for non-standard headers, in the RFC2822 spirit? Sure. 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/20100220193755.ga13...@rivendell
Re: Misc developer news (#21)
On Sat, 2010-02-20 at 14:25 +0100, Raphael Hertzog wrote: > > > This wiki page still misses a "Disadvantages of new format" > section. > > It's a wiki, feel free to add it. I know some people unhappy with the > new > format but I don't know many technical disadvantages. The primary one I'm unhappy with is its deleting part of the upstream tarball with (AFAIK) no warning and no control. (That is, if upstream have a debian dir, it gets nuked, rather than us collaborating on it). -Rob signature.asc Description: This is a digitally signed message part
Re: klibc only initramfs
On Sat, Feb 20, 2010 at 12:02:24PM +0100, Goswin von Brederlow wrote: > The reason would be size. I don't see anything else there. > For network based boots, specifically high performance cluster, the size > can make a real difference. When you turn the cluster on it is not just > one system downloading an extra meg but 100+ nodes. That largely > increases the network collisions, errors and dropped packages. Something > that can even make systems fail to boot. Has anyone tried using library reduction to get a stripped down eglibc for inclusion in initramfs at runtime, using the same techniques as d-i to get a library that contains only those symbols needed by the included utilities? I think that's going to be a more maintainable solution than continually chasing the curve with klibc, both because mklibs is already maintained by the installer team and because there are always going to be new features that users are trying to include in their initramfs that will undermine the effectiveness of the klibc strategy. With mklibs, if you add more utils to the initramfs the size degrades gracefully; if you use klibc, you get a sudden jump the first time you have to include something that needs glibc, and then klibc itself becomes dead weight. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#570729: ITP: libmoosex-types-json-perl -- module providing JSON-constrained strings
Package: wnpp Owner: Jonathan Yu Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libmoosex-types-json-perl Version : 0.02 Upstream Author : Michael Langner * URL : http://search.cpan.org/dist/MooseX-Types-JSON/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : module providing JSON-constrained strings MooseX::Types::JSON is a Moose extension that provides type constraints that validate strings in the JavaScript Object Notation (JSON) format. It can use either the JSON or relaxed JSON specifications and depends on JSON::XS to do the heavy lifting (see libjson-xs-perl for details). -- 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/d1b732a71002201621y2297f2bdh806ac1fc28c45...@mail.gmail.com
Re: Flag images
On Wed, Feb 17, 2010 at 06:05:41PM +0100, Christian PERRIER wrote: > Quoting Dmitry E. Oboukhov (un...@debian.org): > > PW> As an example of the practical effects of flags in the context of > > PW> Debian; a number of years ago we lost our kernel maintainer, partially > > PW> because KDE in Debian included a flag of a country the maintainer (and > > PW> his government) disapproved of. A team formed to replace him, but > > PW> losing contributors still sucks. > > Hgm.. > > When I saw KDE (it was 1.xx version) it contained lang switcher which > > used flags as language indicator. What happened to it? How is this task > > resolved now? > Paul is slightly wrong in his example. We lost the kernel maintainer > because he was thinking that using a compromise in the iso-codes > package to have a common name for TW that is "Taiwan" and not the > official "Taiwan, Province of China" namewas offensive for him and > China "mainland" people (while having "Taiwan, Province of China" > only was offensive to citizens of the island that everybody in the > world names "Taiwan"). > So, nothing to do with flags, indeed. But, besides the underlying > problem (that has no "good" solution), that example shows that > anything related to political geography is highly sensitive. And, for > this, Paul's example is correct. Herbert's resignation mail is here: http://lists.debian.org/debian-devel/2004/05/msg00276.html I've always found it ambiguous what Herbert was referring to when he said "this is too much" - the use of the Taiwanese flag? The original listing of Taiwan as a country that started the thread? Denis rudely telling Herbert that he should resign and join Fedora? - but I don't conclude that his resignation had nothing to do with flags. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Misc developer news (#21)
On Feb 20, Alexander Wirt wrote: > source 3.0 (quilt) is still missing tools to make it working out of the box. > If you quilt not only in debian packages its fucking annoying that you need > to change to patch of your patches from patches/ to debian/patches depending > on what you are working on. What is fucking annoying is that people who should know better still do not know about the simple solution which has been mentioned here multiple times and is even documented in /usr/share/doc/quilt/README.source. -- ciao, Marco signature.asc Description: Digital signature
Re: Misc developer news (#21)
Hi, On Sun, 21 Feb 2010, Robert Collins wrote: > On Sat, 2010-02-20 at 14:25 +0100, Raphael Hertzog wrote: > > > > > This wiki page still misses a "Disadvantages of new format" > > section. > > > > It's a wiki, feel free to add it. I know some people unhappy with the > > new > > format but I don't know many technical disadvantages. > > The primary one I'm unhappy with is its deleting part of the upstream > tarball with (AFAIK) no warning and no control. (That is, if upstream > have a debian dir, it gets nuked, rather than us collaborating on it). That's a feature and an advantage in many situations. It really doesn't forbid you to reuse the upstream dir nor does it forbid you to collaborate with upstream to update it. 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/20100221075352.gb16...@rivendell
Re: Misc developer news (#21)
On Sun, 2010-02-21 at 08:53 +0100, Raphael Hertzog wrote: > > The primary one I'm unhappy with is its deleting part of the upstream > > tarball with (AFAIK) no warning and no control. (That is, if upstream > > have a debian dir, it gets nuked, rather than us collaborating on it). > > That's a feature and an advantage in many situations. It really doesn't > forbid you to reuse the upstream dir nor does it forbid you to collaborate > with upstream to update it. So how do you do that? -Rob signature.asc Description: This is a digitally signed message part
