Re: Apologies, false alarm
Tomas Fasth: > Hi Thomas, > > I sent you an answer 7th of May, see below. > > Regards, Tomas I'm sorry. Please accept my appologies for this false alarm! 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/201205230802.03911.tho...@koch.ro
Re: zlib and biarch/triarch
On Tue, May 22, 2012 at 12:14:49PM +, Thorsten Glaser wrote: > I thought one is supposed to use Multi-Arch now, and that > biarch/triarch can finally go away. > Seeing the trouble broonie has with zlib, why are those > packages still built anyway? Can’t they please go away? zlib is rather low in the stack, so is going to be one of the last packages to drop biarch support. Currently, ia32-libs, wine, lsb, nvidia-graphics-drivers, and zsnes all depend on biarch zlib packages. Of course, all of these packages appear to be specific to amd64, so I don't know why Mark would be adding new biarch packages for s390. You should probably ask him. -- 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: amd64 as default architecture
Le Tue, May 22, 2012 at 04:01:29PM +0100, Ben Hutchings a écrit : > On Tue, May 22, 2012 at 01:25:21PM +, Thorsten Glaser wrote: > > Ben Hutchings dixit: > > > > >> > Eventually (wheezy+2? +3?) we would stop building a kernel package for > > >> > i386. > > >> > > >> As in drop the i386 arch? > > > > > >No, keep i386 userland only. > > > > Oh, definitely not! Please keep this runnable on at least > > machines such as Soekris (486-compatible), Pentium-M, etc. > > For ever and ever and ever? Obviously, if there are no skilled volunteers to maintain the current i386 kernel, there is no way to support it. But in case the user base is too large compared to the developer base, perhaps users can self-organise and gather donations to pay for the work ? I would definitely prefer to spend the price of a new hardware as ~5 years of donations instead of replacing it as long as it is performant enough for its task (I bought mine a few months ago). What do you think would be the cost to keep a good-shaped i386 kernel package in wheezy+2 ? Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20120522231603.ga28...@falafel.plessy.net
Assumptions when processing triggers (was [pkg-mono-group] Bug#671711: monodoc-browser: fails to upgrade) from 'testing'
Greetings, [ I already asked this on d-dpkg, but go no response, so am "re-posting" this question to -devel. The original report along with full log is in #671711 ] On Sun, May 06, 2012 at 10:37:53AM +0200, Andreas Beckmann wrote: > […] > Hi, > > during a test with piuparts I noticed your package fails to upgrade from > 'testing'. > It installed fine in 'testing', then the upgrade to 'sid' fails. > > >From the attached log (scroll to the bottom...): > > Preparing to replace monodoc-clutter-manual > 1.0.0~alpha3~git20090817.r1.349dba6-7 (using > .../monodoc-clutter-manual_1.0.0~alpha3~git20090817.r1.349dba6-8_all.deb) ... > Unpacking replacement monodoc-clutter-manual ... > Processing triggers for monodoc-browser ... > generating monodoc search index... > grep: /etc/gre.d/*.conf: No such file or directory > > Unhandled Exception: System.IO.FileNotFoundException: Could not load file > or assembly 'gtk-sharp, Version=2.12.0.0, Culture=neutral, > PublicKeyToken=35e10195dab3c99f' or one of its dependencies. > File name: 'gtk-sharp, Version=2.12.0.0, Culture=neutral, > PublicKeyToken=35e10195dab3c99f' > [ERROR] FATAL UNHANDLED EXCEPTION: System.IO.FileNotFoundException: Could > not load file or assembly 'gtk-sharp, Version=2.12.0.0, Culture=neutral, > PublicKeyToken=35e10195dab3c99f' or one of its dependencies. > File name: 'gtk-sharp, Version=2.12.0.0, Culture=neutral, > PublicKeyToken=35e10195dab3c99f' > dpkg: error processing monodoc-browser (--unpack): >subprocess installed post-installation script returned error exit status 1 > configured to not write apport reports > Errors were encountered while processing: >monodoc-browser It's because libgtk2.0-cil (on which monodoc-browser depends) has been unpacked but not configured at this point. I thought (from reading /usr/share/doc/dpkg-dev/triggers.txt.gz): , | Packages in t-awaited and t-pending demand satisfaction of their | dependencies just like packages in installed. ` that I could assume this would be the case when running the trigger, but apparently not. What am I guaranteed here? I spoke to Colin Watson about this at UDS and he suggested that perhaps the postinst trigger could register gtk-sharp into the GAC itself, which would be somewhat unfortunate but would probably work if it is guaranteed that libgtk2.0-cil will be unpacked or better when the trigger is activated. In general, what assumptions is it valid to make about the state of depended-on packages of a package in t-pending when the trigger is finally processed? Or, can anyone suggest a nice solution to this bug? :-) Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] PhD student [ i...@cs.nott.ac.uk ] signature.asc Description: Digital signature
Re: [MIA?] Tomas Fasth, Maintainer of Termit et al
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thomas Koch skrev 2012-05-22 09:18: > Hi, > > I'm not sure, whether I should ask here. I already wrote a mail to Tomas Fasth > some weeks ago (I believe, can't find it anymore). I'd like to fix some of the > issues in the termit package. > > But there's no sign of life of him. > > Regards, > > Thomas Koch, http://www.koch.ro Hi Thomas, I sent you an answer 7th of May, see below. Regards, Tomas - Ursprungligt meddelande Ämne: Re: NMU for termit Debian package? Datum: Mon, 07 May 2012 13:58:06 +0200 Från: Tomas Fasth Svar till: to...@debian.org Organisation: Debian Till: tho...@koch.ro Kopia: Nobuhiro Iwamatsu , Julian Taylor , Martintxo , Tomas Fasth Den Mon May 7 06:58:10 2012 skrev Thomas Koch: > Hi Tomas, > > the termit Debian package maintained by you has accumulated a few easy issues > and could also be updated. Would you mind me preparing an NMU? > Did you use a VCS for the packaging? The VCS-* fields in debian/control point > to the upstream's Git repository, not to the repository used for the > packaging. > > Regards, > > Thomas Koch, http://www.koch.ro Hi Thomas, I don't mind you preparing a NMU at all. I welcome your initiative. As a matter of fact, I'm considering to put the package out for adoption, since I have don't have time to actively maintain it. I uploaded the package at first to bring it into the Debian proper. It deserve a DD with more time at hand. Regards - -- Tomas Fasth -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+8C8wACgkQwYdzVZ/o1QQQuQCbB7e3qz0b8oCTORmCqKcibtPT iZIAnRbyDP6Zb/lL3/VPMJhY47rLi9JT =DAU/ -END PGP SIGNATURE- -- 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/4fbc0bcc.6050...@gmail.com
Re: switching from exim to postfix
On Tue, May 22, 2012 at 01:30:30PM +, Thorsten Glaser wrote: > The correct solution here is that the MTA that supports 8BITMIME > itself and wants to send an 8-bit message to another MTA that > doesn’t offer it in the EHLO dialogue (or doesn’t support EHLO) > *must* convert the message to QP and/or base64. And no, this > does not invalidate PGP signatures, because these apply to the > decoded content. (Though some exotic PGP/MIME constellations > may exist, however I don’t use PGP/MIME and as such am not > very knowledgeable about it.) PGP/MIME signatures are against the encoded content, not the decoded content. However, the encoding process moves the mail down to 7bit. -- 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/20120522213924.GD22383@debian
Re: amd64 as default architecture
On Tue, May 22, 2012 at 08:51:17PM +0100, Ben Hutchings wrote: > On Tue, May 22, 2012 at 09:18:21PM +0200, Sven Joachim wrote: > > On 2012-05-22 20:40 +0200, Simon McVittie wrote: > > > On 22/05/12 19:24, Sven Joachim wrote: > > > > > >> and anything that uses libx86 won't work either (#492470). ... > > The lrmi backend uses vm86 mode which is not supported under an x86_64 > > kernel. > > So the x86emu backend should be built too if there are any 64-bit > systems that need libx86 - and maybe for other reasons as well. > That's not a big deal, though, surely? Which backend to use is a compile time option, so this would be switching to always use the x86emu backend. Not a big issue if we're going to drop 32 bit kernels entirely, a performance impact on those machines if we're not. J. -- Web [ Keyboard: Used for entering errors into a system. ] site: http:// [ ] Made by www.earth.li/~noodles/ [ ] HuggieTag 0.0.24 -- 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/20120522213434.gp20...@earth.li
Re: amd64 as default architecture
On Tue, May 22, 2012 at 08:08:29PM +, Thorsten Glaser wrote: > Hm, 2035 or thereabounds sounds good. ;-) Then let’s talk again. Are you volunteering to maintain the i386 architecture until 2035, or volunteering Ben to do 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/20120522212839.GC22383@debian
Bug#674074: ITP: tinyxml2 -- C++ XML parsing library
Package: wnpp Severity: wishlist Owner: Chow Loong Jin * Package name: tinyxml2 Version : 0~git20120518.1.a2ae54e Upstream Author : Lee Thomason * URL : http://www.grinninglizard.com/tinyxml2/ * License : zlib/libpng Programming Lang: C++ Description : C++ XML parsing library TinyXML2 is a simple and small C++ XML parser that can be easily integrating into other programs. It reads XML and creates C++ objects representing the XML document. The objects can be manipulated, changed, and saved again as XML. . TinyXML2 supersedes the previous TinyXML library, with various improvements: - Fewer memory allocations (1% - 10% compared to TinyXML) - Uses less memory (about 40% of that used by TinyXML) - Faster - No STL requirement - More modern C++, including a proper namespace - Proper and useful handling of whitespace -- 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/20120522212230.31302.47922.reportbug@localhost6.localdomain6
Re: amd64 as default architecture
Ben Hutchings dixit: >> >> As in drop the i386 arch? >> > >> >No, keep i386 userland only. >> >> Oh, definitely not! Please keep this runnable on at least >> machines such as Soekris (486-compatible), Pentium-M, etc. > >For ever and ever and ever? Hm, 2035 or thereabounds sounds good. ;-) Then let’s talk again. >Right, sparc32 kernel builds were more-or-less broken for a long time. Ah, okay. >I think sparc32 is in better shape now but it seems pointless to bring >them back. Probably yes; it’s been broken on Linux for so long I believe every remaining user switched to MirBSD/NetBSD/OpenBSD in the meantime or picked up something like SunOS 4 from some archive. And those are, unlike i386, no longer built any more either. (Still usable though.) bye, //mirabilos -- 08:05⎜ mika: Does grml have an tool to read Apple ⎜System Log (asl) files? :) 08:08⎜ yeah. /bin/rm. ;) 08:09⎜ hexdump -C 08:31⎜ ft, mrud: *g* -- 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.bsm.4.64l.1205222006520.6...@herc.mirbsd.org
Re: Wheezy release: CDs are not big enough any more...
Guillem Jover dixit: >> Ah, no, don’t use ar to create .deb files. >> >> http://www.mirbsd.org/permalinks/wlog-10_e20110818-tg-g10046.htm > >Using binutils' ar should be considered supported, and works fine with >dpkg-deb and dpkg, the accepted format is documented in deb(5). I'd The problem is that binutils’ ar generates SYSV style filenames for members since the switch to ELF, while the deb format uses BSD style filenames. Nowadays, tools like apt-extracttemplates support both, but it’s not so long it didn’t (e.g. on hardy). If you use “GNUTARGET=a.out-i386-linux ar rc …” you get a suitable archive… on an i386 host; on other hosts, the $GNUTARGET to use differs. (Hence support for BSD/deb(5) style ar(5) archives in paxtar and, I think I’ve read, (free)bsdtar.) bye, //mirabilos -- “It is inappropriate to require that a time represented as seconds since the Epoch precisely represent the number of seconds between the referenced time and the Epoch.” -- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2 -- 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.bsm.4.64l.1205222008510.6...@herc.mirbsd.org
Re: amd64 as default architecture
On Tue, May 22, 2012 at 09:18:21PM +0200, Sven Joachim wrote: > On 2012-05-22 20:40 +0200, Simon McVittie wrote: > > > On 22/05/12 19:24, Sven Joachim wrote: > > > >> and anything that uses libx86 won't work either (#492470). > > > > Is this the right bug? According to the reporter's reportbug System > > Information, he's running libx86/i386 on one of the i386 kernel > > flavours, > > Oh, indeed. > > > and I don't see any indication that amd64 is involved at all. > > The lrmi backend uses vm86 mode which is not supported under an x86_64 > kernel. So the x86emu backend should be built too if there are any 64-bit systems that need libx86 - and maybe for other reasons as well. That's not a big deal, though, surely? By the way, lack of VM86 mode under Long Mode is a restriction of the AMD64 architecture definition and not a kernel limitation. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- 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/20120522195117.gs4...@decadent.org.uk
Re: amd64 as default architecture
On Sun, 2012-05-20 at 14:03:35 +0200, David Kalnischkies wrote: > On Sun, May 20, 2012 at 1:10 PM, Sven Joachim wrote: > > On 2012-05-20 11:27 +0200, Goswin von Brederlow wrote: > > > Slightly OT but I wanted to mention it for its similarity: > > > > > > One thing that should be tested and then documented prominently as yay > > > or nay in the wheezy upgrade notes is wether one can cross-grade from > > > i386 to amd64 using multiarch. Wether one can install apt/dpkg:amd64 and > > > then migrate to a 64bit userspace. > > > > Won't work in wheezy, apt does not support crossgradesน. > There is no real reason to require apt to do the heavy lifting here. > It would be nice, but it is a one-time action, so a specialized tool wouldn't > hurt muscle memory too much. Install essentials and apt and you should > be good to go to proceed as usual, just with a different architecture… I disagree that this is a one-time action, people might want to cross-grade specific packages back and forth, not just the entire installation. Also unsafe cross-grade does not only affect the Essential set, it also affects anything involved in the boot process, if for whatever reason the system crashes and apt would have removed such package the system would be rendered unbootable. > Even most essentials are easy to crossgrade, the only really difficult one > is dpkg and it's dependencies as you have to take care of not breaking it > while it crossgrades itself. I guess I don't see the additional complexity in the dpkg specific case, it just needs the shared libraries to be installed which should be co-installable anyway, and the rest being M-A:foreign. regards, guillem -- 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/20120522194514.gc22...@gaara.hadrons.org
Re: Wheezy release: CDs are not big enough any more...
On Tue, 2012-05-22 at 12:47:01 +, Thorsten Glaser wrote: > Guillem Jover dixit: > > the archive override. And if we have to keep changing the packages > > anyway to make sure they match changing priorities, we might as well > > just set the compressor (to gzip) explicitly for base packages. > > Pseudo-essential packages are going to be a problem though. > What if a (hypothetical, of course!) package maintainer of > an essential package suddenly decides they need to depend > on, oh I know, say, ucf? Of course, this situation is purely > hypothetical, and ucf would never suddenly become pseudo- > essential. It's not just pseudo-essential, anything pulled into the base set would be affected. In any case that was where my comment was coming from (probably not clearly enough though). Whenever something gets pulled into the base set by something else (another package, an update to the archive override, etc), then there's going to be a time window where the priority in the .deb and the archive override will not match, and the package will need to be modified to accommodate that change. So such possible conditional handling in dpkg-deb (with which I'm not comfortable with, because it's encoding non-generic policy into the tool) would not help anyway, at which point I'd say it makes more sense to just explicitly call dpkg-deb with -Zgzip for base packages. > (Who *is* the authority telling people off for making other > packages pseudo-essential, anyway? I’ve seen it thrice at > least already; luckily it was reverted for the instance when > someone pulled in the (full) perl package.) I'd say debian-devel, either because most of the time this implies a Pre-Depends anyway, or because it's just promoting something into the Essential set. thanks, guillem -- 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/20120522193600.gb22...@gaara.hadrons.org
Re: amd64 as default architecture
On 2012-05-22 20:40 +0200, Simon McVittie wrote: > On 22/05/12 19:24, Sven Joachim wrote: > >> and anything that uses libx86 won't work either (#492470). > > Is this the right bug? According to the reporter's reportbug System > Information, he's running libx86/i386 on one of the i386 kernel > flavours, Oh, indeed. > and I don't see any indication that amd64 is involved at all. The lrmi backend uses vm86 mode which is not supported under an x86_64 kernel. Cheers, Sven -- 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/87fwaskosi@turtle.gmx.de
Re: amd64 as default architecture
On 22/05/12 19:24, Sven Joachim wrote: >> On Tue, May 22, 2012 at 07:27:21PM +0200, Jakub Wilk wrote: >>> We have still some software that doesn't work with 64-bit kernel, >>> and (worse!) some maintainers claiming it's not a bug. > The most prominent example is probably virtualbox (#456391) That bug seems to be that the userland and kernel parts of virtualbox must have the same "width" to work correctly. In a multiarch world, that at least has a workaround: if your kernel is amd64 but your default architecture is i386, replace virtualbox/i386 with virtualbox/amd64 and it should be happy again. > and anything that uses libx86 won't work either (#492470). Is this the right bug? According to the reporter's reportbug System Information, he's running libx86/i386 on one of the i386 kernel flavours, and I don't see any indication that amd64 is involved at all. S -- 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/4fbbddb9.6030...@debian.org
Re: SV: Moving the target of localization pokes (and eventually NMUs)...
Quoting Joe Dalton (joedalt...@yahoo.dk): > pages doesn't seem to have been updated since may 2 ? This has been fixed on i18n.debian.org as of yesterday and the l10n web pages have been refreshed with this data. And, of course, here comes the bad news: - mysql-5.5 has two fuzzies because of trivial templates changes - icinga has 3 new strings from a new template (that needs review) - ledgersmb introduced some debconf templates without call for translations. They need a review. So, 100% moves again a little bit further, thanks to the tireless efforts of our fellow package maintainers..:-) signature.asc Description: Digital signature
Re: amd64 as default architecture
On 2012-05-22 20:03 +0200, Ben Hutchings wrote: > On Tue, May 22, 2012 at 07:27:21PM +0200, Jakub Wilk wrote: >> * Ben Hutchings , 2012-05-20, 03:16: >> >5. Installer for i386 prefers amd64 kernel on any capable machine >> >(that's a one-line change!) and adds amd64 as secondary >> >architecture if this is selected. >> >> We have still some software that doesn't work with 64-bit kernel, >> and (worse!) some maintainers claiming it's not a bug. > > Are you thinking of build systems using 'uname -m' to detect the > target architecture? I don't think so, although those have been quite annoying for me. The most prominent example is probably virtualbox (#456391), and anything that uses libx86 won't work either (#492470). Cheers, Sven -- 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/87mx50krax@turtle.gmx.de
Re: Wheezy release: CDs are not big enough any more...
On Tue, 2012-05-22 at 12:44:02 +, Thorsten Glaser wrote: > Adam Borowski dixit: > >using the attached script. > > Ah, no, don’t use ar to create .deb files. > > http://www.mirbsd.org/permalinks/wlog-10_e20110818-tg-g10046.htm Using binutils' ar should be considered supported, and works fine with dpkg-deb and dpkg, the accepted format is documented in deb(5). I'd consider any program not following that to be either somewhat buggy, or special purpose (for example dak only accepts a subset of a valid deb format). thanks, guillem -- 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/20120522182145.ga22...@gaara.hadrons.org
Re: amd64 as default architecture
On Tue, May 22, 2012 at 07:27:21PM +0200, Jakub Wilk wrote: > * Ben Hutchings , 2012-05-20, 03:16: > >5. Installer for i386 prefers amd64 kernel on any capable machine > >(that's a one-line change!) and adds amd64 as secondary > >architecture if this is selected. > > We have still some software that doesn't work with 64-bit kernel, > and (worse!) some maintainers claiming it's not a bug. Are you thinking of build systems using 'uname -m' to detect the target architecture? It is possible to work around those using setarch. But how do they build on sparc or s390 now? Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- 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/20120522180353.gq4...@decadent.org.uk
Re: amd64 as default architecture
* Ben Hutchings , 2012-05-20, 03:16: 5. Installer for i386 prefers amd64 kernel on any capable machine (that's a one-line change!) and adds amd64 as secondary architecture if this is selected. We have still some software that doesn't work with 64-bit kernel, and (worse!) some maintainers claiming it's not a bug. -- Jakub Wilk -- 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/20120522172721.ga8...@jwilk.net
Re: future of python-pipeline package
* Dmitry Nezhevenko , 2012-05-16, 11:57: I'm trying to package a ReviewBoard package that depends on django-pipeline module. Unfortunately there is already another package named python-pipeline in debian that uses same python module name (pipeline). This another package is orphaned for a year: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620067 I've asked it's upstream and author is going to rename it to something else: http://code.google.com/p/python-pipeline/issues/detail?id=1 (btw I've also asked upstream of django-pipeline but without any luck for now) apt-cache rdepends shows nothing for current python-pipeline. Also popcon shows only 48 installation without information about usage: http://qa.debian.org/popcon.php?package=python-pipeline So I'm asking how to deal with it? django-pipeline looks like more popular according to project github page and bugtracker. Holger suggests to ask here and thinks that it's better to remove orphaned pipeline package. How would the removal help? With my upstream and ex-maintainer hats on, I'm fine with removing python-pipeline from unstable. However, I object to another package taking over the module name. -- Jakub Wilk -- 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/20120522170553.gb7...@jwilk.net
Re: amd64 as default architecture
On Tue, May 22, 2012 at 01:25:21PM +, Thorsten Glaser wrote: > Ben Hutchings dixit: > > >> > Eventually (wheezy+2? +3?) we would stop building a kernel package for > >> > i386. > >> > >> As in drop the i386 arch? > > > >No, keep i386 userland only. > > Oh, definitely not! Please keep this runnable on at least > machines such as Soekris (486-compatible), Pentium-M, etc. For ever and ever and ever? > >> > have ppc64 and sparc64 soon!) > > For sparc64, I heard the sparc kernel has been sparc64-only > since past etch, already. (Too bad, otherwise I could have > run Debian on one of my six SPARCstations at home.) Right, sparc32 kernel builds were more-or-less broken for a long time. I think sparc32 is in better shape now but it seems pointless to bring them back. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- 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/20120522150129.gp4...@decadent.org.uk
Bug#674010: ITP: python-commodity -- Useful utilities library for Python programmers
Package: wnpp Severity: wishlist Owner: David Villa Alises Package name: python-commodity Version : 0.20120514 Upstream Author : David Villa Alises URL : http://bitbucket.org/arco_group/python-commodity License : GPL Programming Lang: Python Description : Useful utilities library for Python programmers python-commodity is a set of general purpose classes, functions and utilities (commodities) for Python programming. It is divided in different packages for multiples purposes: terminal and console formatting, network programming, file system helpers, high level threading structures, useful data structures, etc. -- 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/20120522134810.14868.38391.report...@eckert.esi.uclm.es
Re: switching from exim to postfix
Philipp Kern dixit: >I also assume that Exim does send 8bit mails to non-8bit compliant MTAs (i.e. >not advertising 8BITMIME). I don't know if that's some sort of violation. It does, and it’s a violation, yes. I’ve cursed often enough about that (deliberately running an MTA stripping bit7, for several curiosity reasons, but fully RFC compliant). The correct solution here is that the MTA that supports 8BITMIME itself and wants to send an 8-bit message to another MTA that doesn’t offer it in the EHLO dialogue (or doesn’t support EHLO) *must* convert the message to QP and/or base64. And no, this does not invalidate PGP signatures, because these apply to the decoded content. (Though some exotic PGP/MIME constellations may exist, however I don’t use PGP/MIME and as such am not very knowledgeable about it.) bye, //mirabilos -- 16:47⎜«mika:#grml» .oO(mira ist einfach gut) 23:22⎜«mikap:#grml» mirabilos: und dein bootloader ist geil :)23:29⎜«mikap:#grml» und ich finds saugeil dass ich ein bsd zum booten mit grml hab, das muss ich dann gleich mal auf usb-stick installieren -- Michael Prokop über MirOS bsd4grml -- 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.bsm.4.64l.1205221328020.23...@herc.mirbsd.org
Re: amd64 as default architecture
Ben Hutchings dixit: >> > Eventually (wheezy+2? +3?) we would stop building a kernel package for >> > i386. >> >> As in drop the i386 arch? > >No, keep i386 userland only. Oh, definitely not! Please keep this runnable on at least machines such as Soekris (486-compatible), Pentium-M, etc. >> > have ppc64 and sparc64 soon!) For sparc64, I heard the sparc kernel has been sparc64-only since past etch, already. (Too bad, otherwise I could have run Debian on one of my six SPARCstations at home.) bye, //mirabilos -- > Hi, does anyone sell openbsd stickers by themselves and not packaged > with other products? No, the only way I've seen them sold is for $40 with a free OpenBSD CD. -- Haroon Khalid and Steve Shockley in gmane.os.openbsd.misc -- 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.bsm.4.64l.1205221323260.23...@herc.mirbsd.org
Re: big .debian.tar.xz - EG Wordpress
Jon Dowland dixit: >The stuff is things such as "minified" js. The wordpress source contains the >minified copies, and you can get the originals in separate tarballs from the >wordpress site. Eh, I’d call that RC. People have been told off for not including the corresponding source in the .orig.tar.gz for ages. (Same for a LICENCE file, which one is not allowed to add in the Debian patch, even if the licence terms come from upstream.) You’ll have to repack the orig.tar.xz(I guess) thus. >It strikes me that this is *exactly* what the multiple-source-tarballs feature >of 3.0. is for. Actually, I believe not, since they may belong into the _same_ tarball as their “binaries” (minified versions). >Although, the fact these sources aren't used at all is troubling. Oh, definitely, that too. In fact, I’ve already filed such as RC bug against one of the ECMAscript packages where I noticed it, and I think this happens with many more. bye, //mirabilos -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt -- 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.bsm.4.64l.1205221315280.23...@herc.mirbsd.org
Re: Wheezy release: CDs are not big enough any more...
Guillem Jover dixit: >the archive override. And if we have to keep changing the packages >anyway to make sure they match changing priorities, we might as well >just set the compressor (to gzip) explicitly for base packages. Pseudo-essential packages are going to be a problem though. What if a (hypothetical, of course!) package maintainer of an essential package suddenly decides they need to depend on, oh I know, say, ucf? Of course, this situation is purely hypothetical, and ucf would never suddenly become pseudo- essential. (Who *is* the authority telling people off for making other packages pseudo-essential, anyway? I’ve seen it thrice at least already; luckily it was reverted for the instance when someone pulled in the (full) perl package.) bye, //mirabilos -- ch: good, you corrected yourself. ppl tend to tweet such news immediately, sth. like "grml devs seem to be buyable" dileks: we _are_. if you throw enough money in our direction, things will happen everyone is buyable, it's just a matter of priceand now comes [mira] and uses this as a signature ;0 -- they asked for 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/pine.bsm.4.64l.1205221244530.23...@herc.mirbsd.org
Re: Wheezy release: CDs are not big enough any more...
Adam Borowski dixit: >using the attached script. Ah, no, don’t use ar to create .deb files. http://www.mirbsd.org/permalinks/wlog-10_e20110818-tg-g10046.htm What you can do is: $ paxtar cAf foo.deb debian-binary control.* data.* It’s in wheezy already. bye, //mirabilos -- [...] if maybe ext3fs wasn't a better pick, or jfs, or maybe reiserfs, oh but what about xfs, and if only i had waited until reiser4 was ready... in the be- ginning, there was ffs, and in the middle, there was ffs, and at the end, there was still ffs, and the sys admins knew it was good. :) -- Ted Unangst über *fs -- 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.bsm.4.64l.1205221243040.23...@herc.mirbsd.org
Re: zlib and biarch/triarch
Andrey Rahmatullin (22/05/2012): > > Seeing the trouble broonie has with zlib, why are those > > packages still built anyway? Can’t they please go away? > What are you talking about? Probably that: http://packages.qa.debian.org/z/zlib.html http://packages.debian.org/changelogs/pool/main/z/zlib/current/changelog Mraw, KiBi. signature.asc Description: Digital signature
Re: Wheezy release: CDs are not big enough any more...
Adam Borowski dixit: >if udebs switched to xz (unpacking takes ~10MB memory). -2 takes only 3 MiB, which is about 2 MiB more than gzip, since that number is rounded. bye, //mirabilos -- you introduced a merge commit│ % g rebase -i HEAD^^ sorry, no idea and rebasing just fscked │ Segmentation should have cloned into a clean repo │ fault (core dumped) if I rebase that now, it's really ugh │ wuahh -- 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.bsm.4.64l.1205221231410.23...@herc.mirbsd.org
Re: /usr/share/doc/ files and gzip/xz/no compression
Carsten Hey dixit: >IIRC bzip2 had a better compression. Compressing dpkg's changelog on >stable seems confirm this: xz’s default compression level -6 is not good for files smaller than 8 MiB. Try -2 instead, maybe -2e (slower). Besides, it decompresses a lot faster than bzip2, so even in case of a (slight) size increase from bzip2 to xz, I’d choose xz every day anyway. bye, //mirabilos, wondering how many *.gz don’t use gzip -n9 either -- FWIW, I'm quite impressed with mksh interactively. I thought it was much *much* more bare bones. But it turns out it beats the living hell out of ksh93 in that respect. I'd even consider it for my daily use if I hadn't wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh -- 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.bsm.4.64l.1205221227450.23...@herc.mirbsd.org
Re: zlib and biarch/triarch
On Tue, May 22, 2012 at 12:14:49PM +, Thorsten Glaser wrote: > Just curious… > > I thought one is supposed to use Multi-Arch now, and that > biarch/triarch can finally go away. > > Seeing the trouble broonie has with zlib, why are those > packages still built anyway? Can’t they please go away? What are you talking about? -- WBR, wRAR signature.asc Description: Digital signature
Re: The archive now supports xz compression
Roger Leigh dixit: >Possibly a stupid question here but: Given that we are now autosigning >builds, why can't the slower arches use gzip, and then after upload >they could be recompressed with xz (and resigned) on a faster arch? xz -2 is fast enough on m68k (IIRC, compresses not worse than bzip2 and is not slower than gzip). I think you could justify even something like xz --lzma=preset=3,dict=8M for speed freaks. However, see my mail in for a justification for using xz -2 for most packages and xz -2e for packages with really large data (that is not already precompressed, such as gzip’d manpages) on not-fast architectures (with an allowance for -6[e] for debug, but those wouldn’t be on the CDs anyway). bye, //mirabilos -- Solange man keine schmutzigen Tricks macht, und ich meine *wirklich* schmutzige Tricks, wie bei einer doppelt verketteten Liste beide Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz hervorragend. -- Andreas Bogk über boehm-gc in d.a.s.r -- 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.bsm.4.64l.1205221205140.23...@herc.mirbsd.org
zlib and biarch/triarch
Just curious… I thought one is supposed to use Multi-Arch now, and that biarch/triarch can finally go away. Seeing the trouble broonie has with zlib, why are those packages still built anyway? Can’t they please go away? bye, //mirabilos -- “It is inappropriate to require that a time represented as seconds since the Epoch precisely represent the number of seconds between the referenced time and the Epoch.” -- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2 -- 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.bsm.4.64l.1205221213290.23...@herc.mirbsd.org
Re: removal of Qt3
On 05/21/2012 09:09 AM, Paul Wise wrote: > On Mon, May 21, 2012 at 2:36 PM, Neil Williams wrote: > >> Does LSB matter? > > LSB is irrelevant to me personally since I'm mostly not interested in > running proprietary software on Linux systems. > > I guess LSB must be relevant to Debian since we have it in Debian and > even have a mailing list dedicated to it: > > http://lists.debian.org/debian-lsb/ > > Apparently LSB 5.0 will drop the Qt3 requirement: > > http://lists.debian.org/debian-lsb/2012/02/msg9.html Then we should either drop lsp partly or get 5.0 into Wheezy. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- 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/4fbb65a9.3080...@bzed.de
[MIA?] Tomas Fasth, Maintainer of Termit et al
Hi, I'm not sure, whether I should ask here. I already wrote a mail to Tomas Fasth some weeks ago (I believe, can't find it anymore). I'd like to fix some of the issues in the termit package. But there's no sign of life of him. 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/201205220918.09753.tho...@koch.ro
