Re: Fwd: Re: Why no Opera?
> you can at least use linda and lintian (-iI) to check your packages, > that should help a lot. Indeed - I've been using lintian, and linda's on my set of things to try during my next binge of package work. Eddy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: Re: Why no Opera?
On Thu, Sep 06, 2007 at 10:21:14AM +0200, Edward Welbourne wrote: > > you can at least use linda and lintian (-iI) to check your packages, > > that should help a lot. > > Indeed - I've been using lintian, and linda's on my set of things to > try during my next binge of package work. How about amd64 packages? thanks, Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why no Opera?
On Sep 5, 2007, at 4:43 PM, Edward Welbourne wrote: Steffen: For a closed source release it would be lovely if you had a Debian developer amongst your Opera developers who can upload packages to the distribution. That's one of the (too many) things I've got on my todo list - get myself trained as a proper Debian developer. For the moment, I just have some scripts (mostly inherited, I've only had time to clean them up so far) that do the packaging mostly right; the scripts know more about Debian packaging than I do, though. Tollef Fog Heen directed me to http://www.debian.org/doc/manuals/maint-guide/ when he was my Ubuntu contact, so I guess I should familiarize myself with that before asking for a sponsor ! Eddy. IANDD, but I work with the debian-perl packaging team, mostly creating havoc in their subversion repository. :) I am willing to help packaging Opera because I think it might help persuade the powers that be that the Free Software ecosystem is good for software in general and that using a Free Software license for software can add to its quality and increase profits for the company that writes it. I do have reservations though, it would be nice to know that there is consideration of Free Software licensing for Opera's desktop browser. Frankly I do not see how the GPL or similar license could negatively impact the market prospects for Opera as nearly every browser is already under a Free Software license. (I'm thinking of Web-Kit and Firefox, of course IE is an exception but you do not want to be associated with them. ;^) ) I agree with others on this list who state that there is little point helping closed source software and I could not contribute to a closed source project if it were going to remain closed. I live in Gothenburg Sweden, quite near the headquarters of Opera in Oslo, and you have a development team here in Gothenburg if I am not mistaken - perhaps we could meet and talk about packaging issues? Also there is going to be a Free Software conference in Gothenburg, perhaps Opera is interested in attending / participating (if you or someone from Opera is not already)? We have an exciting roster of speakers lined up with some interesting people from the Free Software world and the entire conference is partly sponsored by the Free Software Foundation Europe. I'll relate more to your email address when the press release is out if you wish, don't want people mad at me for advertising on this list. :) Apologies in advance if this mail is off-topic, which it largely appears to be. I will continue any thread that is not germane off list. Kind regards, Jeremiah Foster [EMAIL PROTECTED] --- Key fingerprint = 9616 2AD3 3AE0 502C BD75 65ED BDC3 0D44 2F5A E672 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: US mirror troubles
Hi, On Wed Sep 05, 2007 at 20:41:51 -0500, John Goerzen wrote: > Hi, > > 35.9.37.225, in http.us.debian.org, and ftp.us.debian.org, has been > unreachable on port 80 from all the networks I have access to for days. > > This is ftp.egr.msu.edu. created as RT#171 -- [EMAIL PROTECTED] /root]# man real-life No manual entry for real-life -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ITP: pgplot-perl -- PGPLOT Perl module
Package: wnpp Severity: wishlist * Package name: pgplot-perl Version : 2.20 Upstream Authors : Karl Glazebrook <[EMAIL PROTECTED]> * URL : http://search.cpan.org/search%3fmodule=PGPLOT * License : see below (yes non-free) Description : PGPLOT Perl module This module allows the use of the the PGPLOT graphics library from the popular Perl scripting language. PGPLOT makes it very easy to process and plot data using the powerful file and text manipulation facilites built in to Perl. Perl provides a superset of the features of the useful UNIX utilities awk and sed and is the `Swiss-Army Chainsaw' of UNIX programming. Find a working, unpolished version at http://gnu.ethz.ch/debian/pgplot-perl/ LICENSE INFORMATION --- The PGPLOT module for Perl is distributed under the same licensing terms as Perl itself. Please see the file "README" in the Perl distribution for more details. The PGPLOT library is copyrighted by the California Institute of Technology but is available free for education, academic research and non-commercial purposes. Please see the file copyright.notice in the PGPLOT distribtuion for more details. Karl Glazebrook 7/Dec/1996 -- System Information: Debian Release: testing/unstable Architecture: powerpc Kernel: Linux ibook 2.4.23-ben1 #7 Sat Dec 27 11:20:38 CET 2003 ppc Locale: LANG=POSIX, LC_CTYPE=POSIX -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#441047: ITP: libyanfs-java -- Yet Another NFS - a Java NFS library
Package: wnpp Severity: wishlist Owner: Varun Hiremath <[EMAIL PROTECTED]> * Package name: libyanfs-java Version : CVS Upstream Author : Agnes Jacob et al * URL : https://yanfs.dev.java.net/source/browse/yanfs/ * License : BSD Programming Lang: Java Description : Yet Another NFS - a Java NFS library This project represents a Java implementation of the XDR, RPC, NFSv2, and NFSv3 protocols in client side form. . WebNFS was the original name for this implementation but the name has changed to reflect the expanded scope of the project to include a server side implementation. . Homepage: https://yanfs.dev.java.net/ -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.15-ck7 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) (ignored: LC_ALL set to en_US) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: Re: Why no Opera?
(Explicitly CCing Edward in the assumption he's not subscribed to this list. The message I'm answering to is at http://lists.debian.org/debian-devel/2007/09/msg00145.html . I'd like to be CCed an followups, although subscribed.) On Wed, Sep 05, 2007 at 09:38:14AM -0400, Roberto C. Sánchez wrote: > On Wed, Sep 05, 2007 at 03:16:07PM +0200, Steffen Moeller wrote: >> On Wednesday 05 September 2007 13:23:46 Edward Welbourne wrote: >>> I'm confused. Pierre appears to be saying "static is bad", Bruce >>> "closed must be static". >> There are multiple views on this. > The problem runs a little deeper than that. > Static linking is considered bad because it is a security > nightmare. You now have extra copies of library code floating > around. Dynamic linking is what the security team likes since it > means that you only update the code once for the whole system. > However, in the event that there is an update which makes the > library non-binary compatible, then there is another problem. That > is, apps linking against it must be recompiled. With a non-free > product like opera, there would be ability for some well-meaning Roberto meant "would *not* be ability", I presume. > Debian Developer to NMU the package (since there is no source) or > for a binNMU to take place if that could fix the problem. (That is in the context of a security problem in a library, naturally.) > Additionally, static linking destroys any memory utilization benefit of > library code. (...) > One possible solution would be for Opera to produce a "source" > package of unlinked binary object files. This would allow relinking > against new versions of the libraries (at least in most cases) > without the need for access to the source. This is already legally required anyway, assuming you link with LGPL code: section 6 of LGPL 2.1. Putting it in a Debian "source package" would only put it in a most convenient form for your users. > However, I tend to be in agreement with others on this list that the > best solution would be a Free software release of Opera. AOL, obviously ;-) -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: Re: Why no Opera?
On Thu, Sep 06, 2007 at 02:27:25PM +0200, Lionel Elie Mamane wrote: > (Explicitly CCing Edward in the assumption he's not subscribed to this > list. The message I'm answering to is at > http://lists.debian.org/debian-devel/2007/09/msg00145.html . I'd like > to be CCed an followups, although subscribed.) > > On Wed, Sep 05, 2007 at 09:38:14AM -0400, Roberto C. Sánchez wrote: > > On Wed, Sep 05, 2007 at 03:16:07PM +0200, Steffen Moeller wrote: > >> On Wednesday 05 September 2007 13:23:46 Edward Welbourne wrote: > > >>> I'm confused. Pierre appears to be saying "static is bad", Bruce > >>> "closed must be static". > > >> There are multiple views on this. > > > The problem runs a little deeper than that. > > > Static linking is considered bad because it is a security > > nightmare. You now have extra copies of library code floating > > around. Dynamic linking is what the security team likes since it > > means that you only update the code once for the whole system. > > However, in the event that there is an update which makes the > > library non-binary compatible, then there is another problem. That > > is, apps linking against it must be recompiled. With a non-free > > product like opera, there would be ability for some well-meaning > > Roberto meant "would *not* be ability", I presume. > Quite right. My brain works faster than I can type. > > Debian Developer to NMU the package (since there is no source) or > > for a binNMU to take place if that could fix the problem. > > (That is in the context of a security problem in a library, > naturally.) > > > Additionally, static linking destroys any memory utilization benefit of > > library code. (...) > > > One possible solution would be for Opera to produce a "source" > > package of unlinked binary object files. This would allow relinking > > against new versions of the libraries (at least in most cases) > > without the need for access to the source. > > This is already legally required anyway, assuming you link with LGPL > code: section 6 of LGPL 2.1. Putting it in a Debian "source package" > would only put it in a most convenient form for your users. > Right. My point was that distributing it in such a fashion might address some of the concerns (though not all, of course) about having something like Opera even in non-free. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: US mirror troubles
John Goerzen <[EMAIL PROTECTED]> writes: > Hi, > > 35.9.37.225, in http.us.debian.org, and ftp.us.debian.org, has been > unreachable on port 80 from all the networks I have access to for days. > > This is ftp.egr.msu.edu. > > It is also still listed at http://www.debian.org/mirror/list > > It is listed "bad" at http://mirror.debian.org/status.html > > Can someone remove it from http.us.debian.org and the list until it's back? > > Also, would it be possible to notify mirror admins of bad mirrors > autoamtically in the future, so this problem can be avoided? > > Meanwhile, I can't seem to find a list of rsyncable US mirrors anymore. Does > anyone know where that list is kept? > > I'm not sure what list is best for this. Apologies if I found the > wrong one. I also notice that we have 4 servers listed under the name "http.us.debian.org" Using "host" from bind9-host, $ host http.us.debian.org http.us.debian.org has address 128.101.240.212 http.us.debian.org has address 204.152.191.7 http.us.debian.org has address 35.9.37.225 http.us.debian.org has address 64.50.238.52 And if you repeat the command, you will see the DNS doing round-robin returning the addresses in various orders. This seems great. However, libc6 resolv+ (I think - can someone confirm who is to blame?) goes out of its way to *sort* the list by IP number and thus thwarts the round-robin. Aptitude (and wget, &c) *always* choose 35.9.37.225. This server must be getting beat like a red-headed stepchild since *all* the debian update/upgrade trying http.us.debian.org go there. Where do I send a bug report about IP number sorting in (I presume) gethostbyname()? > (Should it be -project? Some ticket with the admins RT?) > > Thanks, > > -- John > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- Johan KULLSTAM -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Find complete set of debs
Hi! [please cc: me. Thank you.] How can I (more or less efficiently - I do have a script but it's very crude and probably buggy) download all .debs (and for bonus points the source pkgs, too) that belong to some .deb that I have (same src package, same version)? cheers -- vbi -- > So does the bible contain invariant sections? It sure does: $ bible rev22:18-19 -- Drew Parsons, in a GFDL debate signature.asc Description: This is a digitally signed message part.
Re: US mirror troubles
On Thu, Sep 06, 2007 at 09:24:24AM -0400, Johan Kullstam wrote: > I also notice that we have 4 servers listed under the name > "http.us.debian.org" > > Using "host" from bind9-host, > $ host http.us.debian.org > http.us.debian.org has address 128.101.240.212 > http.us.debian.org has address 204.152.191.7 > http.us.debian.org has address 35.9.37.225 > http.us.debian.org has address 64.50.238.52 > > And if you repeat the command, you will see the DNS doing round-robin > returning the addresses in various orders. This seems great. > > However, libc6 resolv+ (I think - can someone confirm who is to > blame?) goes out of its way to *sort* the list by IP number and thus > thwarts the round-robin. Aptitude (and wget, &c) *always* choose > 35.9.37.225. This server must be getting beat like a red-headed > stepchild since *all* the debian update/upgrade trying > http.us.debian.org go there. > > Where do I send a bug report about IP number sorting in (I presume) > gethostbyname()? I guess its an nscd issue ? Flo -- Florian Lohoff [EMAIL PROTECTED] +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature
Re: virtualbox-ose: package hijack?
Hi, I'm happy to hear that the team maintainance aspect of this seems to have been resolved on IRC. Thanks to those involved! On Wednesday 05 September 2007 14:26, Josselin Mouette wrote: > If there are restrictions on the package name, this definitely looks > like something all Debian developers, especially FTP masters, should be > aware of. http://virtualbox.org/wiki/Licensing_FAQ - #8 regards, Holger .oO( icebox ) pgpvJv3wCssmG.pgp Description: PGP signature
Re: US mirror troubles
On Thu, Sep 6, 2007 at 09:24:24 -0400, Johan Kullstam wrote: > However, libc6 resolv+ (I think - can someone confirm who is to > blame?) goes out of its way to *sort* the list by IP number and thus > thwarts the round-robin. Aptitude (and wget, &c) *always* choose > 35.9.37.225. This server must be getting beat like a red-headed > stepchild since *all* the debian update/upgrade trying > http.us.debian.org go there. > > Where do I send a bug report about IP number sorting in (I presume) > gethostbyname()? > Send it to apt if anything, this change in libc is not a bug. If an application wants to loop over the different addresses returned for a name, it needs to handle that itself. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: virtualbox-ose: package hijack?
Quoting Holger Levsen ([EMAIL PROTECTED]): > Hi, > > I'm happy to hear that the team maintainance aspect of this seems to have > been > resolved on IRC. Thanks to those involved! Indeed. I don't know who had the initiative of setting up that IRC discussion to solve that "dispute" but (s)he deserves a few beers for achieving what I've nearly never seen in many Debian years: stop a -devel flame war. Peace, love, brothers and sisters. (/me goes seeking his old Gong LPs to celebrate) signature.asc Description: Digital signature
Re: Find complete set of debs
On Thu, 6 Sep 2007 15:45:28 +0200 Adrian von Bidder <[EMAIL PROTECTED]> wrote: > How can I (more or less efficiently - I do have a script but it's > very crude and probably buggy) download all .debs (and for bonus > points the source pkgs, too) that belong to some .deb that I have > (same src package, same version)? You mean each architecture? apt-cross is one start - it will be easier with the new rewrite (0.2.9) but that isn't ready for an upload yet. It isn't something it was designed to do - it would mean a lot of cache downloads for the first run but much quicker for subsequent runs. The alternative is that the filename in each mirror is predictable for each arch - a simple reg exp should be sufficient. If you like working in Perl, you could look at the SVN code for apt-cross (www.emdebian.org) and adapt that. (The new version works with libapt-pkg-perl and apt-get.) The cache handling in that code could also detect the .dsc and that would provide the rest of the data. Just some ideas. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpjGNoHTdwJA.pgp Description: PGP signature
directory for icons
Hi my package fai-server will include a command faimond-gui which needs some icons. Were should I put those icons? /usr/share/packagename/icons or /usr/share/commandname/icons or /usr/share/icons/packagename or a different location? I could not find anything in the policy, developers-reference or FHS concerning this. -- regards Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: directory for icons
* Thomas Lange [Fri, 31 Aug 2007 13:57:49 +0200]: > Hi > my package fai-server will include a command faimond-gui which needs > some icons. Were should I put those icons? > /usr/share/packagename/icons or > /usr/share/commandname/icons or > /usr/share/icons/packagename > or a different location? I could not find anything in the policy, > developers-reference or FHS concerning this. I think that if it's a 32x32 .xpm file, the standard location is /usr/share/pixmaps. You probably want that. PNG icons get normally shipped somewhere under /usr/share/icons, but it seems each desktop has its own policies about exactly where. HTH, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Alaska y Dinarama - Cebras -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: US mirror troubles
On Thu, Sep 06, 2007 at 09:24:24AM -0400, Johan Kullstam wrote: > > Using "host" from bind9-host, > $ host http.us.debian.org > http.us.debian.org has address 128.101.240.212 > http.us.debian.org has address 204.152.191.7 > http.us.debian.org has address 35.9.37.225 > http.us.debian.org has address 64.50.238.52 > > And if you repeat the command, you will see the DNS doing round-robin > returning the addresses in various orders. This seems great. > > However, libc6 resolv+ (I think - can someone confirm who is to > blame?) goes out of its way to *sort* the list by IP number and thus > thwarts the round-robin. Aptitude (and wget, &c) *always* choose > 35.9.37.225. This server must be getting beat like a red-headed > stepchild since *all* the debian update/upgrade trying > http.us.debian.org go there. See http://bugs.debian.org/438179 Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: US mirror troubles
Kurt Roeckx wrote: > See http://bugs.debian.org/438179 This bug was closed by adding a config option. Why wasn't it cloned to all the network clients (apt, ntp, etc) that exhibit undesirable behavior due to this change in glibc? Perhaps because the list is too long for anyone to enumerate it. -- see shy jo signature.asc Description: Digital signature
Re: US mirror troubles
On Thu, Sep 06, 2007 at 04:19:51PM -0400, Joey Hess wrote: > Kurt Roeckx wrote: > > See http://bugs.debian.org/438179 > > This bug was closed by adding a config option. Why wasn't it cloned to > all the network clients (apt, ntp, etc) that exhibit undesirable > behavior due to this change in glibc? Perhaps because the list is too > long for anyone to enumerate it. I opened an upstream bug report with ntp. But I would rather see the default get changed. I think there are just too many people/applications that assume a certain behaviour that's different then what we have now. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: US mirror troubles
Kurt Roeckx <[EMAIL PROTECTED]> writes: > On Thu, Sep 06, 2007 at 09:24:24AM -0400, Johan Kullstam wrote: >> >> Using "host" from bind9-host, >> $ host http.us.debian.org >> http.us.debian.org has address 128.101.240.212 >> http.us.debian.org has address 204.152.191.7 >> http.us.debian.org has address 35.9.37.225 >> http.us.debian.org has address 64.50.238.52 >> >> And if you repeat the command, you will see the DNS doing round-robin >> returning the addresses in various orders. This seems great. >> >> However, libc6 resolv+ (I think - can someone confirm who is to >> blame?) goes out of its way to *sort* the list by IP number and thus >> thwarts the round-robin. Aptitude (and wget, &c) *always* choose >> 35.9.37.225. This server must be getting beat like a red-headed >> stepchild since *all* the debian update/upgrade trying >> http.us.debian.org go there. > > > See http://bugs.debian.org/438179 Hmm this makes me sad. Thanks for fighting the good fight. For the benefit of those who might not know, the solution is to edit /etc/gai.conf and put a line of "sortv4 no". IMNSHO it ought to be the default. For IPv4 RFC-3484 makes no sense. Round-robin DNS depends on clients prefering first address returned. This totally breaks a de-facto standard. In IPv4, Subnet is perhaps easy to detect and prefer, but how do you configure prefering a local-net? And since IPv4 blocks are more or less randomly strewn about the world, it doesn't help. It makes some sense of IPv6. But then, IPv6 is the internet of the future and - like fusion power - will always be. So why are we breaking today's internet for some vaporware? Screw 3484. > Kurt -- Johan KULLSTAM A foolish consistency is the hobgoblin of little minds - R.W. Emerson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Heads up on initramfs-tools dev
MODULES=dep The size of the generated initramfs of initramfs-tools in the case of MODULES=dep improved since 0.90a version. i'd like to get more tester feedback on that setting. -> /etc/initramfs-tools/initramfs.conf WARNING: The ide subsys has a funky /sys usage where the sysfs modules string does not match the modules name. There the sysfs walk is presumed to fail (PIIX_IDE != piix). This will go away soon after the migration to pata. For initramfs debugging see http://wiki.debian.org/InitramfsDebug BUSYBOX=n - This setting boots fine since 0.90a and klibc 1.5.6 on /dev/sdaX root (UUID, LABEL usage included). 0.91 moves busybox from Depends to Recommends. allowing package enforced BUSYBOX=n keep in mind that in the case of a boot failure your recovery tools in that situation will be very limited to echo, cat, dmesg, uname, fstype (see ls /usr/lib/klibc/bin/ ). I'd ask the d-i folks to queue busybox before i-t in the base install as it is needed for any but unusual installations. also i'll send patches out to different initramfs boot script to enforce BUSYBOX=y as they might rely on busybox tools (sed, awk, grep, tr, ..). klibc Next steps on a real small initramfs for embedded usage is udev-klibc (compiles and boots fine) and a m-i-t against klibc. klibc got a stdio branch so if others want to play^W compile against klibc that might be the better start to hack on (lvm2, mdadm or even busybox comes to the mind) just install libklic-dev and use make CC=klcc hpa is active, patches are quickly reviewed and merged upstream. git clone git://git.kernel.org/pub/scm/libs/klibc/klibc.git Mailing list: http://www.zytor.com/mailman/listinfo/klibc The klibc linux-libc-dev build-dep change went well (quickly fixed mips+ia64), but gcc-4.2 seems to hit on sparc. that will need attention by sparc porters once the kernel sparc issues are solved. #440721 initramfs races --- Push usage of scsi_wait_scan upstream (thanks a lot willy for the work). already implemented in qlogic, aic94xx, lpfc and fusion. The udev boot script just needs to modprobe it. Patches for ata aka sata and pata are in preparation. The suse bootscripts wait up to some seconds for /dev/mapper/control to appear. that seems sensible and easy to do in the debian lvm2 boot script too. dkt --- Once dkt [1] is in place linux-images will ship parts of the modules prebuild as initramfs in order to reduce build time of the default initramfs. Also grub2 allows multiple initramfs files usage. The dkt will also allow to remove the corresponding initramfs sha1sum's in /var/lib/initramfs-tools on linux-image removal. git repo initramfs repository moved some time ago to git [2]: git clone git://git.debian.org/git/kernel/initramfs-tools.git A special thanks goes to mika for test coverage [3] on grml. happy hacking -- maks [1] http://multibuild.org/documentation/dkt [2] http://www.itp.tuwien.ac.at/~mattems/blog/2007/04/10#bzr_to_git [3] http://www.mail-archive.com/[EMAIL PROTECTED]/msg01388.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: US mirror troubles
On Wed, Sep 05, 2007 at 08:41:51PM -0500, John Goerzen wrote: > 35.9.37.225, in http.us.debian.org, and ftp.us.debian.org, has been > unreachable on port 80 from all the networks I have access to for days. > > This is ftp.egr.msu.edu. Its admin are in BCC of this mail. > It is also still listed at http://www.debian.org/mirror/list > > It is listed "bad" at http://mirror.debian.org/status.html > > Can someone remove it from http.us.debian.org and the list until it's back? This specific issue is being handled by DSA since the ticket has been opened. > Also, would it be possible to notify mirror admins of bad mirrors > autoamtically in the future, so this problem can be avoided? It is possible and already planned, but not yet made real. I could just cron the script I localy run from time to time, but it doesn't handle the case "don't harass daily admins whose mirror is KO" > Meanwhile, I can't seem to find a list of rsyncable US mirrors anymore. Does > anyone know where that list is kept? http://www.debian.org/mirror/mirrors_full or the source file in the webwml CVS. > I'm not sure what list is best for this. Apologies if I found the wrong one. > > (Should it be -project? Some ticket with the admins RT?) (debian-)[EMAIL PROTECTED] or a bug against the 'mirrors' pseudopackage. Regards, -- Simon Paillard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: Re: Why no Opera?
Lionel: >> (Explicitly CCing Edward in the assumption he's not subscribed to this >> list. Thank you - I am, indeed, not subscribed. It would actually be best if you could address me as [EMAIL PROTECTED], so that various of my colleagues see the discussion, too. >> ... The message I'm answering to is at >> http://lists.debian.org/debian-devel/2007/09/msg00145.html . I'd like >> to be CCed an followups, although subscribed.) Thanks for the link - and I largely agree with much that's said in that - see below. Roberto: >> > Static linking is considered bad because it is a security >> > nightmare. You now have extra copies of library code floating >> > around. Dynamic linking is what the security team likes since it >> > means that you only update the code once for the whole system. ... >> > Additionally, static linking destroys any memory utilization benefit of >> > library code. (...) Agreed. These are roughly the arguments I've used in the past to avoid pressure to "simplify" our packaging by changing to static linking (which would save us having to address issues of compatibility with diverse versions of GNU/Linux). The cost is that we have to keep ourselves up-to-date with existing systems, which increases the number of distinct builds we have to make (and package and ship). We have the opera-static version (which static-links Qt, but dynamic-links everything else) so that we can support those on very old versions of GNU/Linux; and I don't like the security (or footprint) angle on that, but it's the best we can think of to do for folk who don't upgrade their core systems. >> > However, in the event that there is an update which makes the >> > library non-binary compatible, then there is another problem. That >> > is, apps linking against it must be recompiled. With a non-free >> > product like opera, there would be [no] ability for some well-meaning >> > Debian Developer to NMU the package (since there is no source) or >> > for a binNMU to take place if that could fix the problem. I'm not sure what a binNMU is. As for the NMU problem, for the foreseeable future, I have to live with opera being non-free, which means we have to carry the burden of responding in a timely manner to such ABI-incompatible changes. Naturally, [EMAIL PROTECTED] would be grateful for any notification of such problems, when they arise. >> > One possible solution would be for Opera to produce a "source" >> > package of unlinked binary object files. This would allow relinking >> > against new versions of the libraries (at least in most cases) >> > without the need for access to the source. >> This is already legally required anyway, assuming you link with LGPL >> code: section 6 of LGPL 2.1. LGPL 2.1 Section 6.b allows for us to b) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable, and (2) will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with. and we use shared linkage for the most part. Even the opera-static package only statically links Qt (for which we have a separate license from TrollTech, independent of its availability under GPL or QPL); everything else is shared-linked. So my understanding of the legal angle is that providing unlinked binaries isn't required - please explain why, if you disagree. >> ... Putting it in a Debian "source package" >> would only put it in a most convenient form for your users. Using shared linkage gets the end-user as much ability to replace libraries (including the X libraries, under BSDoid licenses) as supplying the linkable binaries - if the ABI changes, they'd need a new linkable component from us in any case, and otherwise their replacement shared library will still work. If I've missed something crucial, please enlighten me ! Roberto again: > Right. My point was that distributing it in such a fashion might > address some of the concerns (though not all, of course) about having > something like Opera even in non-free. It would help me if you could enumerate those concerns. Eddy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: Re: Why no Opera?
On Fri, Sep 07, 2007 at 12:11:24AM +0200, Edward Welbourne wrote: > > These are roughly the arguments I've used in the past to avoid > pressure to "simplify" our packaging by changing to static linking > (which would save us having to address issues of compatibility with > diverse versions of GNU/Linux). The cost is that we have to keep > ourselves up-to-date with existing systems, which increases the number > of distinct builds we have to make (and package and ship). We have > the opera-static version (which static-links Qt, but dynamic-links > everything else) so that we can support those on very old versions of > GNU/Linux; and I don't like the security (or footprint) angle on that, > but it's the best we can think of to do for folk who don't upgrade > their core systems. > It seems like you have made a sensible choice in offering both. After all, in a free market one must offer what the customer wants or risk losing the customer altogether. > >> > However, in the event that there is an update which makes the > >> > library non-binary compatible, then there is another problem. That > >> > is, apps linking against it must be recompiled. With a non-free > >> > product like opera, there would be [no] ability for some well-meaning > >> > Debian Developer to NMU the package (since there is no source) or > >> > for a binNMU to take place if that could fix the problem. > > I'm not sure what a binNMU is. As for the NMU problem, for the A binNMU is simply a rebuild that is triggered by archive admins. That is, no source changes are required just a recompile. This is often the case with library transitions so that all the packages that depend on an old library can be recompiled to depend on the new library. In the past this required an actual upload, but nowadays they can just trigger it without an upload. Any package you see with a +b1, +b2 or something like that at the end of the Debian version has been binNMU'd. > foreseeable future, I have to live with opera being non-free, which > means we have to carry the burden of responding in a timely manner to > such ABI-incompatible changes. Naturally, [EMAIL PROTECTED] would be > grateful for any notification of such problems, when they arise. > One thing which would help is if you made use of the Bugs: filed in debian/control. That is you do something like this: Bugs: mailto:[EMAIL PROTECTED] This allows people to send bug reports to you directly using the reportbug tool, which is the preferred tool for submitting bug reports against Debian packages. That field above will indicate to reportbug that the report needs to go to that address instead of the Debian BTS address. > >> > One possible solution would be for Opera to produce a "source" > >> > package of unlinked binary object files. This would allow relinking > >> > against new versions of the libraries (at least in most cases) > >> > without the need for access to the source. > > >> This is already legally required anyway, assuming you link with LGPL > >> code: section 6 of LGPL 2.1. > > LGPL 2.1 Section 6.b allows for us to > > b) Use a suitable shared library mechanism for linking with the > Library. A suitable mechanism is one that (1) uses at run time a > copy of the library already present on the user's computer system, > rather than copying library functions into the executable, and (2) > will operate properly with a modified version of the library, if > the user installs one, as long as the modified version is > interface-compatible with the version that the work was made with. > > and we use shared linkage for the most part. Even the opera-static > package only statically links Qt (for which we have a separate license > from TrollTech, independent of its availability under GPL or QPL); > everything else is shared-linked. > > So my understanding of the legal angle is that providing unlinked > binaries isn't required - please explain why, if you disagree. > I believe he was referring to this paragraph from the Preamble: For example, if you distribute copies of the library, whether gratis or for a fee, you must give the recipients all the rights that we gave you. You must make sure that they, too, receive or can get the source code. If you link other code with the library, you must provide complete object files to the recipients, so that they can relink them with the library after making changes to the library and recompiling it. And you must show them these terms so they know their rights. I think that the intent is that user should be able to make non-binary compatible changes to the library and still relink the non-free work against the new library. > >> ... Putting it in a Debian "source package" > >> would only put it in a most convenient form for your users. > > Using shared linkage gets the end-user as much ability to replace > libraries (including the X libraries, under BSDoid licenses) as >
Re: ITP: pgplot-perl -- PGPLOT Perl module
(added [EMAIL PROTECTED] to the Cc:s) Gürkan Sengün dijo [Thu, Sep 06, 2007 at 11:36:41AM +0200]: > Package: wnpp > Severity: wishlist > > * Package name: pgplot-perl Please use libpgplot-perl, following the current policy for Perl packages. Consider working this together with the pkg-perl group (then again, we might have to discuss this in the group - Group, are you interested in maintaining non-free packages? ;-) ) > Version : 2.20 > Upstream Authors : Karl Glazebrook <[EMAIL PROTECTED]> > * URL : http://search.cpan.org/search%3fmodule=PGPLOT > * License : see below (yes non-free) > Description : PGPLOT Perl module > This module allows the use of the the PGPLOT graphics library from the > popular Perl scripting language. PGPLOT makes it very easy to process > and plot data using the powerful file and text manipulation facilites > built in to Perl. Perl provides a superset of the features of the > useful UNIX utilities awk and sed and is the `Swiss-Army Chainsaw' of > UNIX programming. > > Find a working, unpolished version at > http://gnu.ethz.ch/debian/pgplot-perl/ > > LICENSE INFORMATION > --- > > The PGPLOT module for Perl is distributed under the same licensing terms > as Perl itself. Please see the file "README" in the Perl distribution > for more details. > > The PGPLOT library is copyrighted by the California Institute of > Technology but is available free for education, academic research and > non-commercial purposes. Please see the file copyright.notice in the > PGPLOT distribtuion for more details. > > Karl Glazebrook 7/Dec/1996 (Reproduced only so the pkg-perl group can refer to it without jumping through hoops) Note that the eleven-year-old timestamp seems to concern the _license_, not the module itself :) -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP: pgplot-perl -- PGPLOT Perl module
Hi: On Thu, 6 Sep 2007, Gunnar Wolf wrote: (added [EMAIL PROTECTED] to the Cc:s) Gürkan Sengün dijo [Thu, Sep 06, 2007 at 11:36:41AM +0200]: Package: wnpp Severity: wishlist * Package name: pgplot-perl Please use libpgplot-perl, following the current policy for Perl packages. Consider working this together with the pkg-perl group (then again, we might have to discuss this in the group - Group, are you interested in maintaining non-free packages? ;-) ) I have no objection to working on this, being the maintainer of pgplot5. The problem is that there is a bug filed against pgplot5 because it doesn't properly support libpgplot-perl (pgplot-perl or formerly pgperl) [0]. I have not had any time to figure this out for the past 8 months unfortunately. Part of the problem is that pgplot5 has a very complex build system and I inherited it from an MIA maintainer (silly me...). Carlo [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=407462 -- Carlo U. Segre -- Professor of Physics Associate Dean for Special Projects, Graduate College Illinois Institute of Technology Voice: 312.567.3498Fax: 312.567.3494 [EMAIL PROTECTED]http://www.iit.edu/~segre[EMAIL PROTECTED]
Work-needing packages report for Sep 7, 2007
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 379 (new: 7) Total number of packages offered up for adoption: 79 (new: 2) Total number of packages requested help for: 37 (new: 0) Please refer to http://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: aspell-sv (#440940), orphaned yesterday Description: The Swedish dictionary for GNU aspell Installations reported by Popcon: 401 carpaltunnel (#440615), orphaned 3 days ago Description: Configuration helper for OpenVPN Installations reported by Popcon: 167 dnscvsutil (#440616), orphaned 3 days ago Description: Maintain DNS zone files under CVS control Installations reported by Popcon: 26 ldaptor (#440617), orphaned 3 days ago Description: Documentation for Ldaptor Reverse Depends: ldaptor-utils ldaptor-webui scalemail Installations reported by Popcon: 180 mailping (#440618), orphaned 3 days ago Description: monitor email service availability and functioning Installations reported by Popcon: 54 python-osd (#440782), orphaned 2 days ago Description: Python bindings for X On-Screen Display library Installations reported by Popcon: 209 python-oss (#440783), orphaned 2 days ago Description: Open Sound System (OSS) interface for Python Installations reported by Popcon: 75 372 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/orphaned for a complete list. The following packages have been given up for adoption: gnaural (#440418), offered 5 days ago Description: A programmable binaural-beat audio generator Installations reported by Popcon: 87 klavaro (#440417), offered 5 days ago Description: A very flexible touch typing tutor Installations reported by Popcon: 85 77 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: aboot (#315592), requested 805 days ago Description: Alpha bootloader: Looking for co-maintainers Reverse Depends: aboot aboot-cross dfsbuild ltsp-client-core Installations reported by Popcon: 110 apt-build (#365427), requested 495 days ago Description: Need new developer(s) Installations reported by Popcon: 869 apt-cacher (#403584), requested 262 days ago Description: caching proxy system for Debian package and source files Installations reported by Popcon: 372 apt-show-versions (#382026), requested 394 days ago Description: lists available package versions with distribution Installations reported by Popcon: 2886 athcool (#278442), requested 1045 days ago Description: Enable powersaving mode for Athlon/Duron processors Installations reported by Popcon: 294 cvs (#354176), requested 560 days ago Description: Concurrent Versions System Reverse Depends: bonsai crossvc cvs-autoreleasedeb cvs-buildpackage cvs2cl cvs2html cvschangelogbuilder cvsconnect cvsd cvsdelta (16 more omitted) Installations reported by Popcon: 20037 dpkg (#282283), requested 1020 days ago Description: dselect: a user tool to manage Debian packages Reverse Depends: alien alsa-source apt-build apt-cross apt-src backuppc build-essential bzr-builddeb clamsmtp crosshurd (87 more omitted) Installations reported by Popcon: 61773 elvis (#432298), requested 59 days ago Description: powerful clone of the vi/ex text editor (with X11 support) Reverse Depends: elvis elvis-console elvis-tools Installations reported by Popcon: 289 gentoo (#422498), requested 123 days ago Description: a fully GUI-configurable, two-pane X file manager Installations reported by Popcon: 261 grub (#248397), requested 1214 days ago Description: GRand Unified Bootloader Reverse Depends: dfsbuild replicator Installations reported by Popcon: 56447 ispell-et (#391105), requested 337 days ago Description: Estonian dictionary for Aspell/Ispell/MySpell Installations reported by Popcon: 37 kradio (#429873), requested 78 days ago Description: Comfortable Radio Application for KDE Installations reported by Popcon: 265 lirc (#364606), requested 500 days ago Description: Linux Infra-red Remote Control support Reverse Depends: audacious-plugins-dev audacious-plugins-extra digitaldj fbtv gkrellm-radio gnomeradio gxine irmp3 kradio liblircclient-dev (21 more omitted) Installations reporte
Re: Find complete set of debs
On Thursday 06 September 2007 19.33:50 Neil Williams wrote: > On Thu, 6 Sep 2007 15:45:28 +0200 > > Adrian von Bidder <[EMAIL PROTECTED]> wrote: > > How can I (more or less efficiently - I do have a script but it's > > very crude and probably buggy) download all .debs (and for bonus > > points the source pkgs, too) that belong to some .deb that I have > > (same src package, same version)? > > You mean each architecture? No, all the other .deb packages that come from the same source pkg as the one I have. (But usually I only want i386 and all architectures.) Time to properly learn grep-dctrl, I guess, that's one tool I've completely neglected so far. I guess it should provide the info if invoked the right way. cheers -- vbi -- If you look at debian it has included a qmail-src packet that does patch and changes your local copy of qmail to work as expected (i.e. not the qmail way). -- Anders Arnholm, 2001-08-28, OpenBSD ports mailing list signature.asc Description: This is a digitally signed message part.
Re: Fwd: Re: Why no Opera?
On Fri, Sep 07, 2007 at 12:11:24AM +0200, Edward Welbourne wrote: > Lionel Mamane: >>> Roberto Sánchez: One possible solution would be for Opera to produce a "source" package of unlinked binary object files. This would allow relinking against new versions of the libraries (at least in most cases) without the need for access to the source. >>> This is already legally required anyway, assuming you link with LGPL >>> code: section 6 of LGPL 2.1. > LGPL 2.1 Section 6.b allows for us to > b) Use a suitable shared library mechanism for linking with the > Library. (...) > and we use shared linkage for the most part. Even the opera-static > package only statically links Qt (...); everything else is > shared-linked. > So my understanding of the legal angle is that providing unlinked > binaries isn't required - please explain why, if you disagree. This was written under the assumption that you statically-linked to LGPL libraries, not only Qt. As you now inform me this is not the case, my statement has no base anymore. -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#441136: ITP: jfftw -- Java library to perform Fast Fourier Transformations (FFT)
Package: wnpp Severity: wishlist Owner: Manuel Prinz <[EMAIL PROTECTED]> X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: jfftw Version : 20070725 Upstream Author : Will Hossack <[EMAIL PROTECTED]> * URL : http://www.ph.ed.ac.uk/~wjh/teaching/Java/fft/ * License : GPL Programming Lang: C, Java Description : Java library to perform Fast Fourier Transformations (FFT) jfftw is a simple, and partial, Java interface to the highly optimised FFTW C-package from Matteo Frigo and Steven Johnson from the Department of Applied Mathematics, MIT. . jfftw is developed by Will Hossack from the School of Physics, University of Edinburgh, Scotland. . Homepage: http://www.ph.ed.ac.uk/~wjh/teaching/Java/fft/ -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (200, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.21-2-686 (SMP w/1 CPU core) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Wanted: really weird status files from production machines
On Mon, Aug 27, 2007 at 04:35:30PM +0100, Ian Jackson wrote: > As I report on debian-dpkg in > <[EMAIL PROTECTED]> > I'm proposing to deploy a new dpkg status file parser. > > It would be bad if someone installed the new dpkg but then the new > dpkg rejected their status file. I think I've captured the complete > historical syntax as accepted generated by existing dpkg versions, but > the existing parser is rather too extensively- written to be able to > do a formal analysis. It is possible (even likely) that there > constructions accepted by the old parser but rejected by the new. I > want to be sure that no such constructions exist in the wild. > > So if you have a machine which you have reason to believe has unusual > entries in its status file, please send me copies of the unusual > stanzas. > > Alternatively, download the executable `perftest' > > http://www.chiark.greenend.org.uk/~ian/git/dpkg/dpkg.speedup/build-tree/src/perftest > and run > .../perftest a1 y > which should print `done y' and not complain about any syntax errors. When asking on people a public mailing list to download and run binaries, I sugges you at least sign your email; providing sources would be even better. Running unknown binaries isn't exactly recommended practise =) Regards: David -- /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
