Re: Building packages with exact binary matches
On Mon, Sep 24, 2007 at 06:16:57PM -0700, Russ Allbery wrote: Right now, it's also badly out of date in several respects and not in a position to lead any charge. Manoj and I have both been eaten by our respective day jobs, there are a ton of obvious fixes that should go into the next release, and the work is, er, not being spread at all beyond the two of us. There are 5 Policy delegates listed at http://www.debian.org/intro/organization . There are 5 users who appear to have commit access. These sets are not even close to identical. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: modified email address in debian/copyright file
Ben Finney wrote: That is, so that the information can be extracted automatically and presented by a program in various contexts, rather than having the *only* way to get at the information be to read the debian/copyright file in its entirety. If machine-parsing the copyright file is desired, I suggest someone draft up some kind of control-field format or similar to aid parsing. Attempting to machine-extract useful info consistently from copyright files across the archive at the moment is surely going to be a very error prone task. Until this is done, it would seem a bit unfair to impose restrictions on the way people format the file, such as requiring un-munged email addresses (or even worse, formally specifying the munging method, although thankfully nobody has suggested that yet ;)) -- Jon Dowland -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#443977: ITP: tcl8.5 -- Tcl (the Tool Command Language) v8.5
Package: wnpp Severity: wishlist Owner: Sergei Golovan [EMAIL PROTECTED] * Package name: tcl8.5 Version : 8.5b1 Upstream Author : Tcl Core Team (http://www.tcl.tk/community/coreteam/) * URL : http://www.tcl.tk/ * License : BSD Programming Lang: C, Tcl Description : Tcl (the Tool Command Language) v8.5 Tcl is a powerful, easy to use, embeddable, cross-platform interpreted scripting language. Version 8.5 has the following new features: - dict command - new lassign and lrepeat commands - arbitrary-precision integer support - expr ** exponentiation operator - namespace ensembles support - source -encoding switch - unload command - and much, much more This version is still under development, but the final release of 8.5.0 is expected soon. The current version is quite usable. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-5-amd64 Locale: LANG=ru_RU.CP1251, LC_CTYPE=ru_RU.CP1251 (charmap=CP1251) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#443769: rt2500-source: Missing dependency on bzip2
Steve Greenland wrote: It seems to me that module-assistant should recommend/depend on bzip2, since it is presumably m-a that is calling it. Since it seems as if not every module package is distributed as a bzip2 tarball I think Recommends would be suffice. Because it is a strong, but not absolute, dependency as described by the policy. Regards, Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: modified email address in debian/copyright file
Ben Finney wrote: I'm of the opinion that a copyright statement for the work in a Debian package should include valid contact details ... If they want to avoid giving valid contact information ... The goal is not withold valid contact information, it is to impede automatic email-harvesting software. So far we haven't discussed munging addresses beyond human recognition, just sufficiently to impede work on machine-parsing the copyright file (which I have otherwise heard nothing about) as a by-product. -- Jon Dowland -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: modified email address in debian/copyright file
On Tue, 25 Sep 2007, Jon Dowland wrote: Ben Finney wrote: That is, so that the information can be extracted automatically and presented by a program in various contexts, rather than having the *only* way to get at the information be to read the debian/copyright file in its entirety. If machine-parsing the copyright file is desired, I suggest someone draft up some kind of control-field format or similar to aid parsing. Attempting to machine-extract useful info consistently from copyright files across the archive at the moment is surely going to be a very error prone task. Like say, http://wiki.debian.org/Proposals/CopyrightFormat ? Don Armstrong -- There is no such thing as social gambling. Either you are there to cut the other bloke's heart out and eat it--or you're a sucker. If you don't like this choice--don't gamble. -- Robert Heinlein _Time Enough For Love_ p250 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to detect if inside a buildd chroot
On Sep 25, Sebastian Dröge [EMAIL PROTECTED] wrote: does somebody know about a solution to check whether one runs in a buildd chroot or not? I need this to prevent hal from starting in buildd chroots (via invoke-rc.d from postinst) as it breaks there because of several reasons, including no /sys mounted. Look at the maintainer scripts of the udev package. -- ciao, Marco signature.asc Description: Digital signature
Re: How to detect if inside a buildd chroot
On 25/09/2007 Sebastian Dröge wrote: does somebody know about a solution to check whether one runs in a buildd chroot or not? I need this to prevent hal from starting in buildd chroots (via invoke-rc.d from postinst) as it breaks there because of several reasons, including no /sys mounted. I tought that this should be handled by invoke-rc.d itself. The manpage states that: invoke-rc.d introduces the concept of a policy layer which is used to verify if an init script should be run or not, or if something else should be done instead. This layer has various uses, the most immediate ones being avoiding that package upgrades start daemons out-of-runlevel, and that a package starts or stops daemons while inside a chroot jail. So my assumption was that invoke-rc.d detects if it's invoked inside a chroot, and doesn't start the service in that case. greetings, jonas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to detect if inside a buildd chroot
Hi, Sebastian Dröge schrieb: does somebody know about a solution to check whether one runs in a buildd chroot or not? I need this to prevent hal from starting in buildd chroots (via invoke-rc.d from postinst) as it breaks there because of several reasons, including no /sys mounted. My chroots have /proc and /sys mounted, but I'd still be grateful if hal didn't start. Would it make sense to demote the dependency on the hal daemon to a Recommends (after all, the hal client library should deal with the daemon not running anyway)? Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: modified email address in debian/copyright file
On 2007-09-24 13:17 -0500, Steve Greenland wrote: On 24-Sep-07, 04:30 (CDT), Andre Majorel [EMAIL PROTECTED] wrote: On 2007-09-24 18:21 +1000, Ben Finney wrote: Andre Majorel [EMAIL PROTECTED] writes: On 2007-09-23 17:22 -0700, Don Armstrong wrote: The package should include in the copyright file the correct email address for whatever contact information the upstream author(s) use to receive queries from users and other people. This email address will be used by humans. Why does it have to be machine readable ? So that the information can be presented *to* humans *by* machines. How do you determine that being able to do that is more important than concerns over disseminating other people's email addresses without their permission ? These would be the same people who are distributing the code, right? And who put their preferred public e-mail address in the associated documentation? If you don't want a particular e-mail address distributed, then don't distribute it. The people who mind having their address published are not likely to hand it out without obfuscating it. -- André Majorel http://www.teaser.fr/~amajorel/ bugs.debian.org, a spammer's favourite. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to detect if inside a buildd chroot
Am Dienstag, den 25.09.2007, 11:55 +0200 schrieb Simon Richter: Hi, Sebastian Dröge schrieb: does somebody know about a solution to check whether one runs in a buildd chroot or not? I need this to prevent hal from starting in buildd chroots (via invoke-rc.d from postinst) as it breaks there because of several reasons, including no /sys mounted. My chroots have /proc and /sys mounted, but I'd still be grateful if hal didn't start. Would it make sense to demote the dependency on the hal daemon to a Recommends (after all, the hal client library should deal with the daemon not running anyway)? In one of the cases I found this won't be correct: gnome-mount depends on hal as it doesn't work at all without hal. libnautilus-burn should depend on gnome-mount as it can't do some stuff if gnome-mount is not available. If this is a recommends only, people that don't install recommends have a unusable library lying around. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to detect if inside a buildd chroot
Am Dienstag, den 25.09.2007, 11:49 +0200 schrieb Jonas Meurer: On 25/09/2007 Sebastian Dröge wrote: does somebody know about a solution to check whether one runs in a buildd chroot or not? I need this to prevent hal from starting in buildd chroots (via invoke-rc.d from postinst) as it breaks there because of several reasons, including no /sys mounted. I tought that this should be handled by invoke-rc.d itself. The manpage states that: invoke-rc.d introduces the concept of a policy layer which is used to verify if an init script should be run or not, or if something else should be done instead. This layer has various uses, the most immediate ones being avoiding that package upgrades start daemons out-of-runlevel, and that a package starts or stops daemons while inside a chroot jail. So my assumption was that invoke-rc.d detects if it's invoked inside a chroot, and doesn't start the service in that case. AFAIK this only happens if specified in some config file that daemons shouldn't be started. Whatever, although hal is invoked by invoke-rc.d it is started in the buildd chroots. :/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to detect if inside a buildd chroot
Am Dienstag, den 25.09.2007, 11:35 +0200 schrieb Marco d'Itri: On Sep 25, Sebastian Dröge [EMAIL PROTECTED] wrote: does somebody know about a solution to check whether one runs in a buildd chroot or not? I need this to prevent hal from starting in buildd chroots (via invoke-rc.d from postinst) as it breaks there because of several reasons, including no /sys mounted. Look at the maintainer scripts of the udev package. Thanks, I'll take a look at it... also trying to check all prequisites that hal needs in the init script before launching it might be a solution. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: modified email address in debian/copyright file
On Tue, Sep 25, 2007 at 02:33:58AM -0700, Don Armstrong wrote: Like say, http://wiki.debian.org/Proposals/CopyrightFormat ? Yup, exactly like that :-) Would specifying the copyright line as being structured (rather than free-form) not be a prerequisite before specifying the email address to be un-munged? -- Jon Dowland -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to detect if inside a buildd chroot
Hi, Sebastian Dröge wrote: Would it make sense to demote the dependency on the hal daemon to a Recommends (after all, the hal client library should deal with the daemon not running anyway)? gnome-mount depends on hal as it doesn't work at all without hal. Well, gnome-mount should never be installed on an autobuilder IMO. libnautilus-burn should depend on gnome-mount as it can't do some stuff if gnome-mount is not available. If this is a recommends only, people that don't install recommends have a unusable library lying around. That sounds like recommends, TBH. The fact that apt used to not install Recommends by default has led to way too stringent relationships; I don't see a problem with packages that are largely unusable without a recommended package as long as they handle the situation gracefully. Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFC: autobuilder pseudo-package
Hi, inspired by the how to detect if inside a buildd chroot thread: would it make sense to have an (empty) package autobuilder that all packages that are not supposed to be installed on autobuilders (daemons, packages requiring interactive configuration, ...) can conflict against? Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to detect if inside a buildd chroot
Am Dienstag, den 25.09.2007, 12:23 +0200 schrieb Simon Richter: Hi, Sebastian Dröge wrote: Would it make sense to demote the dependency on the hal daemon to a Recommends (after all, the hal client library should deal with the daemon not running anyway)? gnome-mount depends on hal as it doesn't work at all without hal. Well, gnome-mount should never be installed on an autobuilder IMO. libnautilus-burn should depend on gnome-mount as it can't do some stuff if gnome-mount is not available. If this is a recommends only, people that don't install recommends have a unusable library lying around. That sounds like recommends, TBH. The fact that apt used to not install Recommends by default has led to way too stringent relationships; I don't see a problem with packages that are largely unusable without a recommended package as long as they handle the situation gracefully. Ok, but even if it is recommends, as apt install recommends by default won't it be installed in the buildd chroots too? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to detect if inside a buildd chroot
ti, 2007-09-25 kello 11:55 +0200, Simon Richter kirjoitti: Hi, Sebastian Dröge schrieb: does somebody know about a solution to check whether one runs in a buildd chroot or not? I need this to prevent hal from starting in buildd chroots (via invoke-rc.d from postinst) as it breaks there because of several reasons, including no /sys mounted. My chroots have /proc and /sys mounted, but I'd still be grateful if hal didn't start. Would policy-rc.d be helpful for this situation? -- Don't use me as a bat in your fight; I might start hitting you instead -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#443769: rt2500-source: Missing dependency on bzip2
On Tue, Sep 25, 2007 at 11:30:37AM +0200, Patrick Schoenfeld wrote: Steve Greenland wrote: It seems to me that module-assistant should recommend/depend on bzip2, since it is presumably m-a that is calling it. Since it seems as if not every module package is distributed as a bzip2 tarball I think Recommends would be suffice. Because it is a strong, but not absolute, dependency as described by the policy. True, but what would be the harm in depending on bzip2? Given that module-assistant installs build-essential it doesn't seem like space is an important consideration. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to detect if inside a buildd chroot
tag 439389 help stop Sebastian Dröge [EMAIL PROTECTED] writes: Would it make sense to demote the dependency on the hal daemon to a Recommends (after all, the hal client library should deal with the daemon not running anyway)? In one of the cases I found this won't be correct: gnome-mount depends on hal as it doesn't work at all without hal. libnautilus-burn should depend on gnome-mount as it can't do some stuff if gnome-mount is not available. If this is a recommends only, people that don't install recommends have a unusable library lying around. I think this problem is similar to #439389 in xine-lib (RC, help really appreciated): - libxine1 only depends on libraries, that it really needs. This leaves users that don't install the recommended packages in the situation, that they cannot play their mp3/ogg/etc files. - Promoting them to depends causes them to be installed in any case, which is unwanted in special-use situations (think embedded or special purpose multimedia center installations). - leaving them as recommends causes xine frontends not only to build faster (fewer dependencies to be installed), but also to build more reliably (as you aren't affected by some potential library transition, happened several times in the past. In conclusion: I think we are facing a very similar problem, but we are solving it differently: You prefer to not annoy users which don't respect recommends, and I urge/force people to install recommends if they want to have a usable frontend. Can we perhaps reach a broader consensus on this type of decisions? Ideally, we can clarify this in the Developers Reference. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building packages three times in a row
[EMAIL PROTECTED] writes: On Mon, Sep 24, 2007 at 08:35:50PM +0200, Goswin von Brederlow wrote: Some tools use randomization to get out of worst case situations or general optimization. For example when you look for an optimal allocation of register usage you can do a search by picking a random register allocation and repeat that a few thousand times to find a suitable minimum. Or a randomized heap that gives you O(1) time for all operations instead of O(lg n). By requiring bit-to-bit identical results you eliminate all such randomness and could seriously hinder the algorithm available for tools. While I have a hard time understanding why true randomness is required to solve such problems, I have no problem accepting that practically this is a big obstacle. You could probably fix the seed for the random number generator and thereby make the build fixed. But then some joker would construct a source code that would run into the worst case with specifically that seed. It will not be trivial to establish the equivalence of two such pieces of object code. Thank you for sharing this insight. I think you have helped me to finally see the problem that others have pointed to. Taking etch as the example, could you give any idea what percentage of package we might expect this to turn up in ? I think was doing some randomness with register allocation in some cases. But I'm not sure if that is still the case with all the changes gcc had over the years. But if then you could get for example r0 and r1 interchanged in a function causing a change in all opcaodes involving them. In any case it sounds very much like this idea would be much harder to do than I had originally hoped :-( It will be impossible if you don't excude a lot of known timestamps. Regards, Paddy MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: autobuilder pseudo-package
Simon Richter [EMAIL PROTECTED] writes: Hi, inspired by the how to detect if inside a buildd chroot thread: would it make sense to have an (empty) package autobuilder that all packages that are not supposed to be installed on autobuilders (daemons, packages requiring interactive configuration, ...) can conflict against? Simon Just in case some depends pulls it in unintentionally? In that case I think sbuild would just happily remove it and that would be that. Or do you want to make it essential? :) At a minimum you need sbuild to know about it. But I haven't yet seen why rc policy settings should not do the trick. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: autobuilder pseudo-package
Hi, On Tuesday 25 September 2007 12:25, Simon Richter wrote: inspired by the how to detect if inside a buildd chroot thread: would it make sense to have an (empty) package autobuilder that all packages that are not supposed to be installed on autobuilders (daemons, packages requiring interactive configuration, ...) can conflict against? Interactive configuration must be done via debconf by now. And not wanting to start daemon can have other reasons than autobuilders, eg. eg. chroots, fai's nfsroot, piuparts... so autobuilder is not a good name. regards, Holger pgp0P43WRXgeY.pgp Description: PGP signature
Re: modified email address in debian/copyright file
On Tue, 25 Sep 2007, Jon Dowland wrote: On Tue, Sep 25, 2007 at 02:33:58AM -0700, Don Armstrong wrote: Like say, http://wiki.debian.org/Proposals/CopyrightFormat ? Yup, exactly like that :-) Would specifying the copyright line as being structured (rather than free-form) not be a prerequisite before specifying the email address to be un-munged? I'm personally not terribly concerned at this point about specifying the email address either way. I'm just against specifying that it be munged. [That's for the author/upstream contact string, though. If the copyright statement contains an unmunged (or munged) address, it should not be modified in either direction.] Don Armstrong -- This can't be happening to me. I've got tenure. -- James Hynes _Publish and Perish_ http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: User-Agent strings, privacy and Debian browsers
On Sep 22, 2007, at 8:18 PM, Peter Eckersley wrote: On Sep 22, Marco D'Itri [EMAIL PROTECTED] wrote: On Sep 22, Peter Eckersley [EMAIL PROTECTED] wrote: This means, in practice, that many sites will be able to track Debian users by their User-Agent, even if (say) the user is blocking cookies or limiting them to a single session and is changing IP address regularly. This is highly debateable. There may be tens or thousands of users of the same package visiting a web site. I've seen reports from very large sites indicating that User-Agent strings are almost as useful as cookies for tracking their users. There is no question that many, if not all, web sites that track visitors use the UA string in some way or other. Often it is used for tracking and more commonly it is used to create work-arounds for non- standard compliance. For example IE 6 has some quirky CSS behavior that people often have to consider. Or people use the UA string with the IP and create a hash that is the 'signature' of the visitor. This of course breaks easily but it is still done. Jeremiah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
volatile.debian.org: Does Debian still support it?
The Debian volatile archive is the place for packages that expires before new Debian release. The description perfectly fits for my package libdatetime-timezone-perl. I prepared a few weeks ago new releases for sarge and etch. The release is based on old packages which have refreshed just timezone data, based on Olson Database. The API is not change so it fits to Debian's philosophy of backporting changes to prevent breaking compability. I uploaded them a week ago and... nothing. After 30th of September the timezone data for New Zealand will be not correct (Bug#440258). The users who rely on Debian package will notice that something goes wrong. Please, tell me what should I do so I could see my package in volatile archive? I'm a little disappointed that I was just ignored. My packages are also available at http://people.debian.org/~dexter/volatile/ -- .''`.Piotr Roszatycki : :' :mailto:[EMAIL PROTECTED] `. `' mailto:[EMAIL PROTECTED] `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to detect if inside a buildd chroot
On Tue, 2007-09-25 at 13:14 +0300, Lars Wirzenius wrote: ti, 2007-09-25 kello 11:55 +0200, Simon Richter kirjoitti: Sebastian Dröge schrieb: does somebody know about a solution to check whether one runs in a buildd chroot or not? I need this to prevent hal from starting in buildd chroots (via invoke-rc.d from postinst) as it breaks there because of several reasons, including no /sys mounted. My chroots have /proc and /sys mounted, but I'd still be grateful if hal didn't start. Would policy-rc.d be helpful for this situation? According to /usr/share/doc/sysv-rc/README.policy-rc.d all you need is a /usr/sbin/policy-rc.d (inside the chroot) containing: exit 101 Is there a reason the abovementioned isn't part of standard Debian chroots such as those on buildds? -- Edward Allcutt [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: User-Agent strings, privacy and Debian browsers
On Sep 23, 2007, at 1:39 AM, Joerg Jaspert wrote: On 11150 March 1977, Peter Eckersley wrote: This is highly debateable. There may be tens or thousands of users of the same package visiting a web site. I've seen reports from very large sites indicating that User-Agent strings are almost as useful as cookies for tracking their users. I cant believe this. Looking at the stats from packages.debian.org - U-A is the worst possible way to track users. Would be totally dumb to try something with U-A: Whether it is dumb or not, it is widely used. Same for anything matching Firefox/, has 467789 total hits, with more detail, first 15 rows we get 89003 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) Gecko/ 20061201 Firefox/2.0.0.6 (Ubuntu-feisty) 51159 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7 21879 Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7 11289 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3) Gecko/ 20061201 Firefox/2.0.0.3 (Ubuntu-feisty) 10975 Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7 10217 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6 8542 Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.6) Gecko/ 20061201 Firefox/2.0.0.6 (Ubuntu-feisty) 7572 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7 6029 Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7 5379 Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7 4885 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.7) Gecko/ 20070914 Firefox/2.0.0.7 4859 Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7 4606 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) Gecko/ 20070725 Firefox/2.0.0.6 4549 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) Gecko/ 20070919 Ubuntu/7.10 (gutsy) Firefox/2.0.0.6 4472 Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv: 1.8.1.7) Gecko/20070914 Firefox/2.0.0.7 And thats a quick and very inaccurate way to do it. But it nicely shows that modifying your UA (or forcing others to do so) does not gain you or anyone else anything. The only effect you have is to make statistics more unusable than they already are. I think that is the stated goal. I am still not sure what the issue is from a privacy standpoint. Is it that the EFF fears that information in web server logs might point to a particular user because that user could be identified by the package number of the web browser they are using as stated in the UA string? This seems a pretty flimsy legal premise to identify someone before a court. Not least because that string is completely malleable. Furthermore, the second that package gets updated, the string will change. Packages can change frequently, at least in comparison to new versions of debian itself. Any change from upstream should bump that version string you speak of, as well as a new package inside debian (the last bit of the version string is often the version of the debian package, if the package is not debian native. i.e. the -1 ending in Debian-1.1.4-1). So the package version is a volatile string and not something that a web site analytics software tool (like yaalr for instance :) ) would use to effectively track the user. Furthermore, it seems highly unlikely that a web site would drill down so low into the UA string to get this data and use that as a unique identification. What purpose would that serve? Certainly no web site relies on the package version number of Iceweasel or Firefox to be rendered correctly, and if so they would more likely look for the version string of the software itself, ignoring any debian packaging. I could see one scenario where this might have relevance. That would be if the UA string was logged on several servers. For example, our hypothetical user goes to stealmp3.com and leaves her user string. Then she goes to hacktheNSA.org leaving her version string. She carefully refused any cookies and used different IP addresses, but the version string shows which version of the Iceweasel package she used and the authorities know that that package was only available in a two week period - coincidentally the same time as our user was surfing. The authorities (or RIAA) use this information to narrow down the network and potentially the location of the user (through geolocation perhaps, but that is also unreliable). But this scenario seems highly implausible. Jeremiah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: volatile.debian.org: Does Debian still support it?
Hi Piotr, On Tue Sep 25, 2007 at 14:10:58 +0200, Piotr Roszatycki wrote: The Debian volatile archive is the place for packages that expires before new Debian release. The description perfectly fits for my package libdatetime-timezone-perl. I prepared a few weeks ago new releases for sarge and etch. The release is based on old packages which have refreshed just timezone data, based on Olson Database. The API is not change so it fits to Debian's philosophy of backporting changes to prevent breaking compability. I uploaded them a week ago and... nothing. how about answering to my mail[1]? Greetings Martin [1] http://lists.debian.org/debian-volatile/2007/09/msg5.html [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]
Re: volatile.debian.org: Does Debian still support it?
Ah... Do you mean this mail? am I missing something completely here? [EMAIL PROTECTED]:~/debian/packages$ diff -rNu libdatetime-timezone-perl-0.42-before-dv/ libdatetime-timezone-perl-0.42 | diffstat changelog|9 control |4 packages |2 patches/001-AKST9AKDT_timezone.patch | 11 patches/010-tzdata2007g.patch|38814 +++ patches/012-tzdata2007g-tests.patch | 21 patches/020-AKST9AKDT_timezone.patch | 11 rules|4 update-tzdata.sh | 30 9 files changed, 38890 insertions(+), 16 deletions(-) What is your question exactly? Do you mean, the patch is too large or what? Can you clarify, what do you really want to ask? The package is perfectly correct and the only difference is updated timezone database plus the shell script debian/update-tzdata.sh which I used for updating plus updated test units for new database. 2007/9/25, Martin Zobel-Helas [EMAIL PROTECTED]: Hi Piotr, On Tue Sep 25, 2007 at 14:10:58 +0200, Piotr Roszatycki wrote: The Debian volatile archive is the place for packages that expires before new Debian release. The description perfectly fits for my package libdatetime-timezone-perl. I prepared a few weeks ago new releases for sarge and etch. The release is based on old packages which have refreshed just timezone data, based on Olson Database. The API is not change so it fits to Debian's philosophy of backporting changes to prevent breaking compability. I uploaded them a week ago and... nothing. how about answering to my mail[1]? Greetings Martin [1] http://lists.debian.org/debian-volatile/2007/09/msg5.html [EMAIL PROTECTED] /root]# man real-life No manual entry for real-life -- .''`.Piotr Roszatycki : :' :mailto:[EMAIL PROTECTED] `. `' mailto:[EMAIL PROTECTED] `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: modified email address in debian/copyright file
Andre Majorel [EMAIL PROTECTED] writes: The people who mind having their address published are not likely to hand it out without obfuscating it. These aren't email addresses of close personal friends, given to a select few people. These are email addresses given by the copyright holder as the contact address to use in relation to a particular software work. (If that's not the case, it's not the case under discussion here.) The *only* useful purpose for giving an email address to someone is for them to put it into a computer program; for that purpose, it needs to be in a valid form at *some* point. There's negative value to each person holding that address to keep it in obfuscated form: every time they want to make use of it, it needs to either be un-obfuscated from that form, or (much more likely) retrieved from some location where it is stored in valid form. So it's completely unreasonable to expect that, once given out as the contact email address for the copyright holder of a widely-published work of software, it won't appear in valid-computer-parseable form associated with that software. -- \ There's no excuse to be bored. Sad, yes. Angry, yes. | `\Depressed, yes. Crazy, yes. But there's no excuse for boredom, | _o__) ever. -- Viggo Mortensen | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to detect if inside a buildd chroot
Sebastian Dröge [EMAIL PROTECTED] writes: That sounds like recommends, TBH. The fact that apt used to not install Recommends by default has led to way too stringent relationships; I don't see a problem with packages that are largely unusable without a recommended package as long as they handle the situation gracefully. Ok, but even if it is recommends, as apt install recommends by default won't it be installed in the buildd chroots too? I'd assume that the buildd maintainers will configure apt in a way that it doesn't install recommends, but only depends. I don't know if this has been discussed among the buildd maintainers, does anybody know a contact adress for them as collective? -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to detect if inside a buildd chroot
On Tue September 25 2007 5:03:32 am Sebastian Dröge wrote: AFAIK this only happens if specified in some config file that daemons shouldn't be started. Whatever, although hal is invoked by invoke-rc.d it is started in the buildd chroots. :/ It is this whole problem that has caused me to never want to try to build things in chroots -- the problem of installing things that mess with daemons. I've had MTAs restarted, cron restarted, etc. I don't really think that chroot is the appropriate tool for this. Why not something more strongly isolated, such as vserver, OpenVZ, or even Xen or UML for this? -- John
Re: volatile.debian.org: Does Debian still support it?
Piotr Roszatycki wrote: After 30th of September the timezone data for New Zealand will be not correct (Bug#440258). The users who rely on Debian package will notice that something goes wrong. Based on the description (and not the patch) it seems to me that this kind of change should be in the next etch point release. SRMs? Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to detect if inside a buildd chroot
John Goerzen [EMAIL PROTECTED] writes: It is this whole problem that has caused me to never want to try to build things in chroots -- the problem of installing things that mess with daemons. I've had MTAs restarted, cron restarted, etc. Sounds like a bug (severity important) to me. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#444021: ITP/RFP: sugar
package: wnpp Severity: wishlist Owner: Holger Levsen [EMAIL PROTECTED] x-debbugs-cc: debian-devel@lists.debian.org, [EMAIL PROTECTED], [EMAIL PROTECTED] * Package name: sugar Version : snapshots Upstream Authors : 14 people, see AUTHORS * URL : http://wiki.laptop.org/go/Sugar * License : GPL Programming Lang: Python Description : OLPC Human Interface Sugar is the core of the OLPC Human Interface. Its goal is to turn the Laptop into a fun, easy to use, social experience that promotes sharing and learning. These are other good pointers: http://dev.laptop.org/git?p=sugar;a=tree http://wiki.laptop.org/go/Sugar_on_Debian - instruction how to build it from source http://wiki.laptop.org/go/Sugar_on_Ubuntu_Linux - links to ubuntu packages I'm very happy about co-maintainers or even other maintainers, as a.) I'm quite too busy already and b.) I don't really know much python. I thought I file this as an ITP anyway (and not RFP), so that it shows up on my QA-page, so I get reminded of this once in a while. regards, Holger pgpMGq1WZ8z7d.pgp Description: PGP signature
Re: Bug#444021: ITP/RFP: sugar
On Tue, Sep 25, 2007 at 04:08:32PM +0200, Holger Levsen wrote: package: wnpp Severity: wishlist Owner: Holger Levsen [EMAIL PROTECTED] x-debbugs-cc: debian-devel@lists.debian.org, [EMAIL PROTECTED], [EMAIL PROTECTED] * Package name: sugar Version : snapshots Upstream Authors : 14 people, see AUTHORS * URL : http://wiki.laptop.org/go/Sugar * License : GPL Programming Lang: Python Description : OLPC Human Interface Sugar is the core of the OLPC Human Interface. Its goal is to turn the Laptop into a fun, easy to use, social experience that promotes sharing and learning. But, er, what does it /do/? I read the webpage but that has the same marketing style waffle. Is it a replacement for a window manager? A replacement for gnome/kde/xfce? -- Simon [ [EMAIL PROTECTED] ] *\ The machine is dead - Deep Throat \** ** ]-+-+-+-+-+-+-+-+-[ **\\* ** [ Htag.pl 0.0.22 ] ***\\ signature.asc Description: Digital signature
Re: volatile.debian.org: Does Debian still support it?
Hi, On Tue Sep 25, 2007 at 14:55:47 +0200, Piotr Roszatycki wrote: Ah... Do you mean this mail? am I missing something completely here? [EMAIL PROTECTED]:~/debian/packages$ diff -rNu libdatetime-timezone-perl-0.42-before-dv/ libdatetime-timezone-perl-0.42 | diffstat changelog|9 control |4 packages |2 patches/001-AKST9AKDT_timezone.patch | 11 patches/010-tzdata2007g.patch|38814 +++ patches/012-tzdata2007g-tests.patch | 21 patches/020-AKST9AKDT_timezone.patch | 11 rules|4 update-tzdata.sh | 30 9 files changed, 38890 insertions(+), 16 deletions(-) What is your question exactly? Do you mean, the patch is too large or what? Can you clarify, what do you really want to ask? The package is perfectly correct and the only difference is updated timezone database plus the shell script debian/update-tzdata.sh which I used for updating plus updated test units for new database. I don't understand why there is a patch of 38k lines needed to fix ONE SINGE timezone. Greetings Martin -- [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]
Re: How to detect if inside a buildd chroot
ti, 2007-09-25 kello 08:18 -0500, John Goerzen kirjoitti: I don't really think that chroot is the appropriate tool for this. Why not something more strongly isolated, such as vserver, OpenVZ, or even Xen or UML for this? If the chroot has a policy-rc.d that says not to start daemons, any package that does so is buggy (possibly even RC buggy), and needs to be fixed. Luckily, there's few such packages anymore. -- Yet another quit message no-one will ever comment on. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
dh_install vs. dh_movefiles
dh_movefiles(1) says that dh_install is a much better program, and you are
recommended to use it instead. Accordingly, I've changed the packages I've
adopted from using dh_movefiles to dh_install --sourcedir=debian/tmp. But
it's not entirely clear to me just _how_ dh_install is so much better. And is
dh_movefiles deprecated? I think it can be practical if you need to put some
files in one package and the rest in a main package. Since you can't
specify all files in /usr/share/foo except these: ..., you have to
basically list them one by one otherwise (or use hacks
like usr/share/foo/{[!b]*,?[!a]*,??[!z]*}, or delete the duplicates
afterwards).
Accidentally overlapping .files lists can cause files to end up in the wrong
packages, whereas lintian can detect if the same file is in more than one
package. (And one must of course make sure that dh_movefiles operates on the
packages in the correct order if using deliberately overlapping lists.)
I also note that dh_movefiles might do globbing in a different way and that it
doesn't actually move files (it copies and then removes the original)
--
Magnus Holmgren[EMAIL PROTECTED]
(No Cc of list mail needed, thanks)
signature.asc
Description: This is a digitally signed message part.
Bug#444022: ITP: papi -- OpenPrinting PAPI suite
Package: wnpp Severity: wishlist Owner: Jeff Licquia [EMAIL PROTECTED] * Package name: papi Version : 1.0 beta Upstream Author : Norm Jacobs [EMAIL PROTECTED] * URL : http://sourceforge.net/projects/openprinting * License : Mostly CDDL (some LGPL, some MIT-style) Programming Lang: C Description : OpenPrinting PAPI suite This is an implementation of OpenPrinting PAPI, a programming specification for cross-platform and cross-print-system printing. The package includes PAPI libraries, an implementation of the System V and BSD print utilities which use PAPI, and an Apache module for receiving IPP requests and passing them on via PAPI. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.21-2-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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: Bug#444021: ITP/RFP: sugar
Hi, On Tuesday 25 September 2007 16:20, Simon Huggins wrote: Sugar is the core of the OLPC Human Interface. Its goal is to turn the Laptop into a fun, easy to use, social experience that promotes sharing and learning. But, er, what does it /do/? Point taken. I read the webpage but that has the same marketing style waffle. But it has nice screenshots!! ;) Is it a replacement for a window manager? A replacement for gnome/kde/xfce? The latter. It provides the GUI for XO laptops. regards, Holger pgptpDFl5v3dC.pgp Description: PGP signature
Re: Bug#443769: rt2500-source: Missing dependency on bzip2
Hamish Moffatt schrieb: True, but what would be the harm in depending on bzip2? Given that Well, i don't see a harm caused by that. But IMHO it is just a question of how to read the policy, as it states the (spongelike) sentence: The Depends field should be used if the depended-on package is required for the depending package to provide a significant amount of functionality. What does significant amount mean? Absolutely sure is, that Depends should only be used if the depended thing is *required*, but what for? If you consider unpacking module source tarballs as significant amount of functionality, then one *needs* to depend on bzip2. But thats not sure, because not every source tarball is distributed as a bzip2 tarball. module-assistant installs build-essential it doesn't seem like space is an important consideration. When i read this sentence I had an idea of what would eventually be better. module-assistant is installing build-essential, you said. Why shouldn't it install bzip2 on demand? It would make sense, wouldn't it? Regards, Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#443904: ITP: jugglemaster -- graphical siteswap simulator
El Tuesday 25 September 2007 05:37:51 Steve Greenland va escriure: JuggleMaster is a siteswap animator. If you know what that is, great. If you don't, you can just install the program and look at some of the builtin patterns, without understanding the notation. Look, I one of those who doesn't think descriptions of specialty packages need to explain their function to non-specialized users. If you don't understand this, you don't need it is an acceptable background attitude for a lot of package descriptions. However, spelling it out explicitly may be a bit much. As for the next sentence, I'm not sure it's OK to say: if you want to know what the program does, you have to install it. Regards. David -- David Ammouial http://da.weeno.net/ signature.asc Description: This is a digitally signed message part.
Re: How to detect if inside a buildd chroot
On Tue, 25 Sep 2007 08:18:39 -0500, John Goerzen [EMAIL PROTECTED] said: I don't really think that chroot is the appropriate tool for this. Why not something more strongly isolated, such as vserver, OpenVZ, or even Xen or UML for this? I've always used an UML for this. I need to automate my workflow a bit more -- there are two parts of building packages; one set of operations run as root (build depends loading, and running piuparts), and another set which is run as a user running perhaps under fake root (the real build etc). I can use an @boot cron job to run stuff; but I have not done so since specifying SELinux policy for this is not gonna be fun (run as root in some security domain, and then start a dpkg-buildpackage as root in the usr_t domain), and I have been being lazy. I already have a shell version of satisfy_builddeps, so all I really need is to have the policy snippet, and I'll publish my building in a SELinux uml/kvm virtual machine thing. In my copious spare time, of course. manoj -- It's a naive, domestic operating system without any breeding, but I think you'll be amused by its presumption. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Changing name of source package
hi, I just want to double check that changing the name of a source package can be done as I anticipate it. I would like to change the name of the source package php4-ps into php-ps. php4-ps creates two binary packages php4-ps and php5-ps. The new source package php-ps will only create php5-ps because php4 will be dropped anyway in the near future. From what I have read so far, it should be sufficient to upload the new source package which takes over the binary package php5-ps. Is it required to wait for a new upstream version or can I simply push up the debian version from 1.3.5-1 to 1.3.5-2? Uwe -- MMK GmbH, Fleyer Str. 196, 58097 Hagen [EMAIL PROTECTED] Tel: 02331 840446Fax: 02331 843920 signature.asc Description: Digital signature
Re: Bug#443769: rt2500-source: Missing dependency on bzip2
Le Tuesday 25 September 2007 16:51:10 Patrick Schoenfeld, vous avez écrit : module-assistant installs build-essential it doesn't seem like space is an important consideration. When i read this sentence I had an idea of what would eventually be better. module-assistant is installing build-essential, you said. Why shouldn't it install bzip2 on demand? It would make sense, wouldn't it? Well the real solution to solve this is to count the ratio of packages that provides sources as a bzip2 tarball with regard to gzip tarballs. If this is a vast majority, which is what I think, then its a depends. If this is like fifty-fifty, then a recommends, if this is a small minority, then a suggests... Romain
Bug#444031: ITP: gimmix -- a gtk+2 based client for the music player daemon (MPD)
Package: wnpp Severity: wishlist Owner: Patrick Schoenfeld [EMAIL PROTECTED] * Package name: gimmix Version : 0.4.1 Upstream Author : Priyank Gosalia [EMAIL PROTECTED] * URL : http://gimmix.berlios.de/index.php * License : GPL Programming Lang: C Description : a gtk+2 based client for the music player daemon (MPD) Gimmix is a graphical client for the music player daemon (MPD) written in C using GTK+2. It's very simple and easy to use and has a small memory footprint. .. Features: - Simple and clean interface - Compact and full view modes - Library browser with search functionality - Playlist management for mpd - ID3v2 tag editing support - Support for controlling gimmix through keyboard - System tray icon support - Notification support This package is already in Ubuntu. I will take their package as a base and start working on it. Thats the reason why I CC the Ubnutu team. To them the question: Is it okay to add you as a co-maintainer of a package? I prefer to be maintainer for myself, but I trust in the Ubnutu team to contribute if/as neccessary and also like the idea to see all those packages that are a result of the Ubnutu initiative on qa.debian.org. Best Regards, Patrick -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (1001, 'testing'), (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.18-4-k7 (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: volatile.debian.org: Does Debian still support it?
It's not about one timezone. The new release refresh all available timezones. The whole package was synced with the latest Olson database. It is simple analogy for tzdata package. You should also ask, why the tzdata package has so many changes and why don't simply update only one timezone? 2007/9/25, Martin Zobel-Helas [EMAIL PROTECTED]: Hi, On Tue Sep 25, 2007 at 14:55:47 +0200, Piotr Roszatycki wrote: Ah... Do you mean this mail? am I missing something completely here? [EMAIL PROTECTED]:~/debian/packages$ diff -rNu libdatetime-timezone-perl-0.42-before-dv/ libdatetime-timezone-perl-0.42 | diffstat changelog|9 control |4 packages |2 patches/001-AKST9AKDT_timezone.patch | 11 patches/010-tzdata2007g.patch|38814 +++ patches/012-tzdata2007g-tests.patch | 21 patches/020-AKST9AKDT_timezone.patch | 11 rules|4 update-tzdata.sh | 30 9 files changed, 38890 insertions(+), 16 deletions(-) What is your question exactly? Do you mean, the patch is too large or what? Can you clarify, what do you really want to ask? The package is perfectly correct and the only difference is updated timezone database plus the shell script debian/update-tzdata.sh which I used for updating plus updated test units for new database. I don't understand why there is a patch of 38k lines needed to fix ONE SINGE timezone. Greetings Martin -- [EMAIL PROTECTED] /root]# man real-life No manual entry for real-life -- .''`.Piotr Roszatycki : :' :mailto:[EMAIL PROTECTED] `. `' mailto:[EMAIL PROTECTED] `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: semi-virtual packages?
On Tue, 25 Sep 2007 02:36:24 -0600, Bruce Sass [EMAIL PROTECTED] said: On Sun September 23 2007 03:08:59 pm Manoj Srivastava wrote: On Sun, 23 Sep 2007 14:26:29 -0600, Bruce Sass [EMAIL PROTECTED] said: On Sun September 23 2007 11:00:58 am Manoj Srivastava wrote: We can create any number of dummy packages on the fly, but what is the use case we are trying to solve here? Why are we adding a virtual package, having package provide the virtual package, given that this virtual package does not provide any functionality, and so no other package is going to depend on it? Why are you asking that. You provided the use case---a file shared by many packages but really owned by none. Yup, I provided that use case. I see no reason to create a virtual package to implement the use case I provided. I ask again, do you have a use case which led you down the path of proposing a virtual package? I say again, I have not proposed creating any virtual packages... Sorry, that was not clear to me. I have written nothing about adding a virtual package, and the functionality of the existing virtual packages which I would manifest is obvious---provide a home for the files shared by many packages but really owned by none. ...what I did mention was: Perhaps virtual packages need to have a real presence on the system when such a situation exists. Could you please elaborate what you mean, since I obviously have not understood you? I ask again, with slightly different words: Is there any case of a file shared by many packages but really owned by none which does not already have a virtual package associated with it? Sure. /etc/kernel-img.conf, if it exists, does not belong to anyone. Unfortunately, I see no reason to create a virtual package to implement the use case I provided., sounds like a yes but it doesn't really answer the question. I can't find a case so I can not demonstrate something which doesn't exist, you think you've found a case so you should be able to describe it more fully than I see no reason. No, that is not what I meant. What I meant was that my use case was that there are circumstances where it is useful to have a number of packages read a configuration file -- but none of them really wants to own it. Everything I described after that point was under: assuming a, no. If you would have answered yes to that question then you should have ignored (at least from the perspective of solving the case you mentioned) everything after that point because it was clearly not applicable to your use case. It would have then been a good idea to describe why your use case results in a yes because I was, equally clearly, not able to think of a situation including your use case which should not already involve a virtual package. If it was otherwise I would not have assumed no, ya. Think, for instance, of kernel image packages. Kernel image packages come and go -- each new upstream kernel creates a whole slew of packages. Now, if any package owned the file, and the image package was purged -- the file would go with it. So, kernel-img.conf exists outside of any package -- and is created by some image package postinst in certain rare conditions, and abandoned. If you are willing to go for that, I might be willing to go for that if there was a clear statement of benefit gained, what use case we are satisfying, and if there were convincing arguments that other solutions are not a better fit than trying to shoe horn dpkg -L to be the solution to whatever use case we are attempting to solve (this is no longer the original use case presented -- I-do-not-know-where-the-documentation-is). Huh. You provided the case, and the benefit should be obvious---and if it is not then why did you bring up addressing, the case of a file shared by many packages but really owned by none? No, my use case merely says that we should be able to have a situation where we have a configuration file that does not belong to a package. And yes, I see the benefits of this use case immediately. aside it is stuff like this which tends to act like `pee in my cornflakes' Well, the misunderstanding is with what I was presenting as my use case (need for files to not belong to any package, in the absence of any virtual package to tack the file on to). You were talking of something else entirely -- I think you are talking about upgrading a free floating conf file to a different format, or something like that (I am still not sure) What does the No you wrote connect with: - the fact that you provided the use case, in spite of your, Yup, I provided that use case., statement nope. - the implication that benefits should be obvious to you, since you provided the case nope. - is it an answer to the question itself, even though the answer should be in the form of
Re: Bug#443769: rt2500-source: Missing dependency on bzip2
Romain Beauxis schrieb: Well the real solution to solve this is to count the ratio of packages that provides sources as a bzip2 tarball with regard to gzip tarballs. Why do you call it the *real* solution? What makes the solution better over the one I suggested? If this is a vast majority, which is what I think, then its a depends. If this is like fifty-fifty, then a recommends, if this is a small minority, then a suggests... Besides that it makes a lot of work and I don't know if you are true, that is not constant. This value is likely to change and so would the relation ship eventually need to change. Also it leaves the chance that the user might install module-assistant w/o the need for bzip2, which is a waste of everything (space, bandwith). I actually do see that this are minor issues, but they *are* issues, while the solution I came up with has no issues I am aware of or that anybody pointed out. It is also the same solution that is already used in module-assistant for build-essential, while this is a virtual package depending on several others which makes it a bit different, though. Regards, Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Maintainer of package joystick may be missing
Dear Debian MIA Team, I made a small patch for the jscal.c in the joystick package. I then tried to contact the maintainer, Edward Betts ([EMAIL PROTECTED]) on 09/17/2007, with no success. As recommended on the page 'Debian Developer's Reference Chapter 7 / Dealing with inactive and/or unreachable maintainers', I tried to gather information on Edward Betts: - his debian home page http://people.debian.org/~edward/ does not seem to have content newer than 08-Dec-2005 - according to http://asdfasdf.debian.net/~tar/bugstats/?edward%40debian.org, he has not uploaded anything for two years - there are 2 patches against hist joystick package that are not included, the latest dates from 01 Nov 2005 - searching for Edward Betts on google, I have not noticed anything after 2005 Unfortunately going to the developers' LDAP database (https://db.debian.org/) did not yield the date when he last posted to a Debian mailing list (this was suggested in the Developers' Reference). Please show me the way I can have my patch included in jscal.c of the joystick package. I believe it is useful and I immediately wanted to share it with others. This however turns out to be a lot more difficult than I expected. Edward Betts seems to be unavailable for almost two years now, and so there is nobody to apply my - or the other 2 in the queue - patch to the source. I thank you for your kind help in advance. Best regards, Laszlo Kajan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to detect if inside a buildd chroot
* Reinhard Tartler: - libxine1 only depends on libraries, that it really needs. This leaves users that don't install the recommended packages in the situation, that they cannot play their mp3/ogg/etc files. I guess this will be a non-issue as soon as apt-get installs recommends by default. Users who overide this will know what to do in this situation. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#443769: rt2500-source: Missing dependency on bzip2
Le Tuesday 25 September 2007 17:37:03 Patrick Schoenfeld, vous avez écrit : Romain Beauxis schrieb: Well the real solution to solve this is to count the ratio of packages that provides sources as a bzip2 tarball with regard to gzip tarballs. Why do you call it the *real* solution? What makes the solution better over the one I suggested? Well real is perhaps too strong. Let's say that it's the quantitative approach. Other approaches are just chatty chatty. There's no point in discussing infinitely things if we don't consider real facts. This is no big deal, a quick an dirty search gives: apt-file search /usr/src/ | grep gz | grep 'source:' | wc -l 18 apt-file search /usr/src/ | grep bz2 | grep 'source:' | wc -l 48 (This search is not adequate, it matches non-module packages like ocaml-search) So that makes roughtly 75% of bzip2 tarballs and 25 % of gz tarballs. That number would mean to me that it is more likely to have a recommends than a depends. Now perhaps, the real (...) solution is to settle a minimal policy about this. For instance, should module-source package also depends on module-assistant ? This is the case for many packages but I don't think module-assistant is required to build a package, isn't it an *assistant* ? A simple policy like source packages must recommend module-assistant and should provide gzip tarballs would give a common answer, given that it's not a technical issue as far as I see it... Romain
Re: Bug#444022: ITP: papi -- OpenPrinting PAPI suite
Jeff Licquia wrote: * Package name: papi [...] This is an implementation of OpenPrinting PAPI, a programming specification for cross-platform and cross-print-system printing. For me, papi is a library with its tools to access hardware performance counters. It used a lot on some plateform (NUMA, ...) to analyze the performance of HPC programs. Google with papi give this link in first : http://icl.cs.utk.edu/papi/ This software is not packaged in Debian (yet ? but it needs a patched kernel). However, I think I would be better if you do not use 'papi' as the package name. Perhaps openprinting-papi or openprinting or ... What do you think ? Best regards, Vincent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: volatile.debian.org: Does Debian still support it?
On Tue, Sep 25, 2007 at 05:36:03PM +0200, Piotr Roszatycki wrote: It's not about one timezone. The new release refresh all available timezones. The whole package was synced with the latest Olson database. It would be good if you fixed #416206, and used tzdata yourself. So that we only need to update 1 package in volatile. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
unbelievable
Debian-devel best x x x for free 7forfree dot cn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Changing name of source package
On Tue, Sep 25, 2007 at 05:04:47PM +0200, Uwe Steinmann wrote: From what I have read so far, it should be sufficient to upload the new source package which takes over the binary package php5-ps. Is it required to wait for a new upstream version or can I simply push up the debian version from 1.3.5-1 to 1.3.5-2? As long as the versions of the binary packages are higher than the ones already in the archive you should be safe I guess. Since you change the name of the source package the upstream version doesn't really matter since the orig.tar.gz's will named differently either way... Gruesse, -- Frank Lichtenheld [EMAIL PROTECTED] www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#444022: ITP: papi -- OpenPrinting PAPI suite
Vincent Danjean wrote: For me, papi is a library with its tools to access hardware performance counters. It used a lot on some plateform (NUMA, ...) to analyze the performance of HPC programs. Google with papi give this link in first : http://icl.cs.utk.edu/papi/ This software is not packaged in Debian (yet ? but it needs a patched kernel). However, I think I would be better if you do not use 'papi' as the package name. Perhaps openprinting-papi or openprinting or ... What do you think ? I'm not particularly attached to the package name, but there will likely be issues with the library name. What's worse is that the OpenPrinting libpapi already appears in a few other distributions, and is already referenced in a published standard by the OpenPrinting group. So, perhaps, the hardware-counter PAPI group should consider a name change instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: volatile.debian.org: Does Debian still support it?
It is almost impossible. The DateTime::TimeZone is pure Perl library and can't use binary data from tzdata package. In fact, this library can be used on systems without libc6 and tzdata at all! You wrongly assume that tzdata package is more important than libdatetime-timezone-perl package. It can be true only for glibc based systems. Even tzdata package is compiled from the source data - the same data which is used for refreshing libdatetime-timezone-perl! 2007/9/25, Kurt Roeckx [EMAIL PROTECTED]: On Tue, Sep 25, 2007 at 05:36:03PM +0200, Piotr Roszatycki wrote: It's not about one timezone. The new release refresh all available timezones. The whole package was synced with the latest Olson database. It would be good if you fixed #416206, and used tzdata yourself. So that we only need to update 1 package in volatile. Kurt -- .''`.Piotr Roszatycki : :' :mailto:[EMAIL PROTECTED] `. `' mailto:[EMAIL PROTECTED] `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: volatile.debian.org: Does Debian still support it?
On Tue, Sep 25, 2007 at 09:48:19PM +0200, Piotr Roszatycki wrote: It is almost impossible. The DateTime::TimeZone is pure Perl library and can't use binary data from tzdata package. In fact, this library can be used on systems without libc6 and tzdata at all! You wrongly assume that tzdata package is more important than libdatetime-timezone-perl package. It can be true only for glibc based systems. Even tzdata package is compiled from the source data - the same data which is used for refreshing libdatetime-timezone-perl! That it can be used on other systems that don't have tzdata doesn't mean it shouldn't try and use tzdata if it's available on Debian. The binary data in the tzdata should be easy to parse. See man tzfile(5). 2007/9/25, Kurt Roeckx [EMAIL PROTECTED]: On Tue, Sep 25, 2007 at 05:36:03PM +0200, Piotr Roszatycki wrote: It's not about one timezone. The new release refresh all available timezones. The whole package was synced with the latest Olson database. It would be good if you fixed #416206, and used tzdata yourself. So that we only need to update 1 package in volatile. Kurt -- .''`.Piotr Roszatycki : :' :mailto:[EMAIL PROTECTED] `. `' mailto:[EMAIL PROTECTED] `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: modified email address in debian/copyright file
On 25-Sep-07, 04:13 (CDT), Jon Dowland [EMAIL PROTECTED] wrote: The goal is not withold valid contact information, it is to impede automatic email-harvesting software. So far we haven't discussed munging addresses beyond human recognition, just sufficiently to impede work on machine-parsing the copyright file (which I have otherwise heard nothing about) as a by-product. I'd bet at least a small sum of money that not beyond human recognition and impede machine parsing are, at this point, non-intersecting sets. It's not even like they have to get it right on the first try -- just generate a bunch of differnt unmunges, and try them. Or, more accurately, sell them to losers. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#443406 closed by Torsten Werner [EMAIL PROTECTED] (Bug#443406: fixed in liquidlnf 2.9.1-3)
This is an automatic notification regarding your Bug report
which was filed against the liquidlnf package:
#443406: Use of our external site embedded into a Debian file
It has been closed by Torsten Werner [EMAIL PROTECTED].
Their explanation is attached below. If this explanation is
unsatisfactory and you have not received a better one in a separate
message then please contact Torsten Werner [EMAIL PROTECTED] by replying
to this email.
Debian bug tracking system administrator
(administrator, Debian Bugs database)
---BeginMessage---
Source: liquidlnf
Source-Version: 2.9.1-3
We believe that the bug you reported is fixed in the latest version of
liquidlnf, which is due to be installed in the Debian FTP archive:
liquidlnf_2.9.1-3.diff.gz
to pool/contrib/l/liquidlnf/liquidlnf_2.9.1-3.diff.gz
liquidlnf_2.9.1-3.dsc
to pool/contrib/l/liquidlnf/liquidlnf_2.9.1-3.dsc
liquidlnf_2.9.1-3_all.deb
to pool/contrib/l/liquidlnf/liquidlnf_2.9.1-3_all.deb
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to [EMAIL PROTECTED],
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Torsten Werner [EMAIL PROTECTED] (supplier of updated liquidlnf package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing [EMAIL PROTECTED])
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Tue, 28 Aug 2007 16:39:39 +0530
Source: liquidlnf
Binary: liquidlnf
Architecture: source all
Version: 2.9.1-3
Distribution: unstable
Urgency: low
Maintainer: Varun Hiremath [EMAIL PROTECTED]
Changed-By: Torsten Werner [EMAIL PROTECTED]
Description:
liquidlnf - Java Swing Look and Feel of Mosfet Liquid KDE 3.x
Closes: 443406
Changes:
liquidlnf (2.9.1-3) unstable; urgency=low
.
* debian/control: Add XS-Vcs-{Svn,Browser} headers.
* Add debian/README.Debian-source file.
* Stop using sitetruth.com in debian/watch (Closes: #443406)
Files:
d0d14d8a730a3e051267aa16fe295480 783 contrib/utils extra liquidlnf_2.9.1-3.dsc
4e14d58067929254794eb1efd7b38e93 2917 contrib/utils extra
liquidlnf_2.9.1-3.diff.gz
74f29a2024c0ae644ef11029e9ade511 328154 contrib/utils extra
liquidlnf_2.9.1-3_all.deb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFG+WtsfY3dicTPjsMRAoUpAJ9OyrYvcOKnFxJQLTGMAaVR56QYiACeJrwO
hFNmP3D4BwtFc4AIRWLH1sk=
=11Hb
-END PGP SIGNATURE-
---End Message---
Re: volatile.debian.org: Does Debian still support it?
It is already such library called DateTime::TimeZone::Tzfile. It is not packaged yet, but... It is different story. We still talk about DateTime::TimeZone. Even if it should be replaced with newer, better and faster libraray, it is ALREADY in etch and sarge. The Debian supports the packages which do not really work for the full time of a stable release. The Volatile archive keeps them functional. The libdatetime-timezone-perl is one of such packages. I explained what changed in this package, why the changes are necessary and how I made this update. It perfectly fits to stable policy. It is backward compatible and only data are changed. Of course, the Perl code can also be a data, and this module is an adequate example. Users of my package would like to see the updated package which is supported by Debian. One of them even tested it before I uploaded it to Volatile incoming queue. I don't understand what is the point? Why do you think this package shouldn't go to Volatile? What do you propose as alternative? 2007/9/25, Kurt Roeckx [EMAIL PROTECTED]: On Tue, Sep 25, 2007 at 09:48:19PM +0200, Piotr Roszatycki wrote: It is almost impossible. The DateTime::TimeZone is pure Perl library and can't use binary data from tzdata package. In fact, this library can be used on systems without libc6 and tzdata at all! You wrongly assume that tzdata package is more important than libdatetime-timezone-perl package. It can be true only for glibc based systems. Even tzdata package is compiled from the source data - the same data which is used for refreshing libdatetime-timezone-perl! That it can be used on other systems that don't have tzdata doesn't mean it shouldn't try and use tzdata if it's available on Debian. The binary data in the tzdata should be easy to parse. See man tzfile(5). -- .''`.Piotr Roszatycki : :' :mailto:[EMAIL PROTECTED] `. `' mailto:[EMAIL PROTECTED] `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: AM status for Krystian Wlosek?
Hi. Thank you a lot. I suppose that everyone are busy today, so do I. I'm a little tired with sponsoring his packages and I know he could to upload his packages by his own. I really don't undestand why new developers are checked so precisely. I think it is much harder to join Debian than i.e. Google or Microsoft. It is ridiculous. I understand, the developers should have a good knowledge of unix systems and our ogranization but... that's going too far! I'm sure that many people resigns because this process is too long. I really wonder why Krystian still want to be Debian developer. I think I weren't be a Debian developer today, if I would take so long NM process 8 years ago. 2007/9/25, Aníbal Monsalve Salazar [EMAIL PROTECTED]: I'm sorry about the delay, I have been very busy with my new job. I'll work on Krystian's application this weekend. -- .''`.Piotr Roszatycki : :' :mailto:[EMAIL PROTECTED] `. `' mailto:[EMAIL PROTECTED] `-
Re: Building packages with exact binary matches
On Mon, Sep 24, 2007 at 06:20:40PM -0500, Manoj Srivastava wrote: On Tue, 25 Sep 2007 00:04:15 +0200, Martin Uecker [EMAIL PROTECTED] said: It would be enough when just a few people are actually recompiling the binaries and compare it to the official debian packages. Then *everbody* could trust that the packages are not modified, because any modification would be detected immediatley. This is only possible with bit-identical binaries. Err, what? Why would everyone do that? I mean, you do not trust the Debian distribution system, the archive gpg signatures, the md5sums on the package, etc, and ye5t you are willing to accept mails from other people that things are oK? No. I would trust the binaries if there are *no mails* from other people that things are *not ok*. Because everybody can check that the binaries are not compromised, you can actually be quite sure that things are ok, as long as nobody complains. And if doubts come up, I can check myself. This actually the same principle on wich science is build: falsifiability. Compare this to the current system: The trustworthiness of *all* DDs wich maintain packages which are installed on my systems, the security of *all* computers those DDs store their keys on, the security of the build host, the gpg signatures and the md5sums are actually a chain of trust where the weakest link determines the total security. Martin
Re: Building packages with exact binary matches
On Tue, Sep 25, 2007 at 01:03:27AM +0100, Benjamin A'Lee wrote: On Tue, Sep 25, 2007 at 12:04:15AM +0200, Martin Uecker wrote: Manoj Srivastava [EMAIL PROTECTED] wrote: Actually, if you do not trust the path down which a binary package flows, you can not use any information down that flow path to test your implementation. You need to do a full source audit, and build from source -- at which point, you might just install your trused binary, instead of trying to verify that the upstream package is the same as yours. It would be enough when just a few people are actually recompiling the binaries and compare it to the official debian packages. Then *everbody* could trust that the packages are not modified, because any modification would be detected immediatley. This is only possible with bit-identical binaries. Erm, if I can't trust the Debian Project to create trustworthy packages and verify their integrity, why should I trust anyone else to verify them? No, I trust that somebody would *falsify* them if there are compromised. See my reply to Manoj for an explanation. [...] You're also assuming that the source code is trustworthy. If the binary packages can be compromised, so can the source packages. Its exactly the same: Because the source code is open, I would hope that somebody would find the backdoor. Martin
Re: volatile.debian.org: Does Debian still support it?
Hi, On Tue Sep 25, 2007 at 17:36:03 +0200, Piotr Roszatycki wrote: It is simple analogy for tzdata package. You should also ask, why the tzdata package has so many changes and why don't simply update only one timezone? [EMAIL PROTECTED]:~% diff -rNu tzdata-2007b tzdata-2007f | diffstat africa | 16 asia | 56 +--- australasia| 24 +-- debian/changelog |9 ++ europe | 62 ++ leapseconds| 16 ++-- northamerica | 177 ++--- southamerica | 17 +++-- zone.tab | 10 +- 9 files changed, 289 insertions(+), 98 deletions(-) So where are 38k lines here, which changed? In general i have no problem to accept a package into volatile, if one can give me GOOD reasons, why all these changes are necessary. What i do not understand is, why tzdata has about 300 lines changed, while your package needs 38k lines changed to achive the same effect. Greetings Martin -- [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]
Re: volatile.debian.org: Does Debian still support it?
You made a subtle mistake. You checked the source package for tzdata
and the changes are really small. Then you checked the differences for
libdatetime-timezone-perl package, but this source package is already
compiled. You should check the difference between binary packages for
tzdata.
The real source data for DateTime::TimeZone is the same as for tzdata
source package. Then, the data is precompiled into Perl source. It
makes a Debian source package.
Did you really read this patch?
It contains the series of such differences:
diff -Nru DateTime-TimeZone-0.42/lib/DateTime/TimeZone/Africa/Addis_Ababa.pm
DateTime-TimeZone-0.42
--- DateTime-TimeZone-0.42/lib/DateTime/TimeZone/Africa/Addis_Ababa.pm
2006-02-20 16:45:58.000
+++ DateTime-TimeZone-0.42.2007g/lib/DateTime/TimeZone/Africa/Addis_Ababa.pm
2007-09-05 14:29:11
@@ -3,7 +3,7 @@
# DateTime::TimeZone module distribution in the tools/ directory
#
-# Generated from /tmp/3PactztUqR/africa. Olson data version 1
+# Generated from tzdata/africa. Olson data version 2007g
#
# Do not edit this file directly.
#
@@ -50,7 +50,7 @@
sub has_dst_changes { 0 }
-sub _max_year { 2016 }
+sub _max_year { 2017 }
sub _new_instance
{
If you multiply this chunk by 400 timezones, you can get 40K of patch.
Another patch changes test units so make test can be passed with new
data. Also I provided a shell script which precompiles tzdata source
into Perl source so updating is quite simplier.
As I sad previously, the timezones data are precompiled into Perl
source because this library runs on non-Linux platforms, too, and in
this case it has a meaning.
You just compared an apples with oranges.
I understand, it's not comfortable situation with updates, but this
library already exists, and is used by many Perl projects. I see you
proposed to replace this library with other, which doesn't provide own
timezone data, but it is too late and not possible just now.
2007/9/25, Martin Zobel-Helas [EMAIL PROTECTED]:
So where are 38k lines here, which changed?
In general i have no problem to accept a package into volatile, if one can
give
me GOOD reasons, why all these changes are necessary. What i do not understand
is, why tzdata has about 300 lines changed, while your package needs 38k lines
changed to achive the same effect.
--
.''`.Piotr Roszatycki
: :' :mailto:[EMAIL PROTECTED]
`. `' mailto:[EMAIL PROTECTED]
`-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#443769: rt2500-source: Missing dependency on bzip2
On Tue, Sep 25, 2007 at 04:51:10PM +0200, Patrick Schoenfeld wrote: Hamish Moffatt schrieb: module-assistant installs build-essential it doesn't seem like space is an important consideration. When i read this sentence I had an idea of what would eventually be better. module-assistant is installing build-essential, you said. Why shouldn't it install bzip2 on demand? It would make sense, wouldn't it? It would be consistent with m-a's handling of build-essential. However, I think m-a should depend on build-essential since it always requires it. Therefore we are still undecided about bzip2. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#443769: rt2500-source: Missing dependency on bzip2
On Wed, Sep 26, 2007 at 08:44:50AM +1000, Hamish Moffatt wrote: It would be consistent with m-a's handling of build-essential. However, I think m-a should depend on build-essential since it always requires it. Therefore we are still undecided about bzip2. m-a don't need build-essential. It needs the compiler (nothing else like libc headers) for the kernel. The debian linux headers already depends against the correct compiler. Bastian -- One does not thank logic. -- Sarek, Journey to Babel, stardate 3842.4
Bug#444082: ITP: cothreads -- concurrent programming library for OCaml
Package: wnpp Severity: wishlist Owner: Sylvain Le Gall [EMAIL PROTECTED] * Package name: cothreads Version : 0.10 Upstream Author : Zheng Li [EMAIL PROTECTED] * URL : http://cothreads.sourceforge.net/ * License : GPL Programming Lang: OCaml Description : concurrent programming library for OCaml This library enhances the Threads library of the standard OCaml distribution in two dimensions: . - It implements the same API of the standard Threads library on different execution engines (process, networker(todo)), so that a single copy of source code can be compiled and deployed to different environments without modification. - It is also a super set of the standard Threads library, with extra components (STM etc.), functions (spawn etc.) and features (object-level compatibility etc.). -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22.6-vs2.2.0.3-core2 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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: Building packages with exact binary matches
Clint Adams [EMAIL PROTECTED] writes: On Mon, Sep 24, 2007 at 06:16:57PM -0700, Russ Allbery wrote: Right now, it's also badly out of date in several respects and not in a position to lead any charge. Manoj and I have both been eaten by our respective day jobs, there are a ton of obvious fixes that should go into the next release, and the work is, er, not being spread at all beyond the two of us. There are 5 Policy delegates listed at http://www.debian.org/intro/organization . There are 5 users who appear to have commit access. These sets are not even close to identical. Yeah. I, or Manoj, or somebody needs to ping the union of those two sets and try to figure out who's interested. If people want to work on Policy and are just blocked because they don't know how to technically go about it, I would be quite happy to answer questions, and I'm sure Manoj would as well. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#443769: rt2500-source: Missing dependency on bzip2
On Wed, 26 Sep 2007 01:03:38 +0200, Bastian Blank [EMAIL PROTECTED] said: On Wed, Sep 26, 2007 at 08:44:50AM +1000, Hamish Moffatt wrote: It would be consistent with m-a's handling of build-essential. However, I think m-a should depend on build-essential since it always requires it. Therefore we are still undecided about bzip2. m-a don't need build-essential. It needs the compiler (nothing else like libc headers) for the kernel. The debian linux headers already depends against the correct compiler. Not good enough. What if I am using m-a with kernel.org kernel sources? I won't have a kernel-headers package installed (I don't). If you need something, depend upon it. Don't depend on some package you do not even depend upon to transitively provide you with stuff; the package you are blithely dependent upon might change its dependencies, and your package will be up the creek without a paddle. m-a works just fine to help me compile third party modules with locally compiled kernels. So, if it needs bzip2, it should depend on bzip2. manoj -- To use violence is to already be defeated. Chinese proverb Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building packages with exact binary matches
On Tue, 25 Sep 2007 23:49:17 +0200, Martin Uecker [EMAIL PROTECTED] said: On Mon, Sep 24, 2007 at 06:20:40PM -0500, Manoj Srivastava wrote: On Tue, 25 Sep 2007 00:04:15 +0200, Martin Uecker [EMAIL PROTECTED] said: It would be enough when just a few people are actually recompiling the binaries and compare it to the official debian packages. Then *everbody* could trust that the packages are not modified, because any modification would be detected immediatley. This is only possible with bit-identical binaries. Err, what? Why would everyone do that? I mean, you do not trust the Debian distribution system, the archive gpg signatures, the md5sums on the package, etc, and ye5t you are willing to accept mails from other people that things are oK? No. I would trust the binaries if there are *no mails* from other Ah, security through blissful ignorance :) You do not actually trust the archive, or the developers, you trust the silence. people that things are *not ok*. Because everybody can check that the binaries are not compromised, you can actually be quite sure that things are ok, as long as nobody complains. And if doubts come up, I can check myself. This actually the same principle on wich science is build: falsifiability. Everyone does that now based on debian archive signatures. You do not need bit-by-bit verification for that. So, one someone lets the cat out of the bag, and we are not so blissful ,how can we check? Simple, you say, compile the source!! But, dear folks, the person who can compromise the archive, fake out the buildd's, add the archive signature -- can also hack the source. Its exactly the same: Because the source code is open, I would hope that somebody would find the backdoor. Ah. again, assume security until someone pulls us out of our ignorance. So easy to do a denial of service attack by random slander of binaries and source (thanks, helpful botnet). Compare this to the current system: The trustworthiness of *all* DDs wich maintain packages which are installed on my systems, the security of *all* computers those DDs store their keys on, the security of the build host, the gpg signatures and the md5sums are actually a chain of trust where the weakest link determines the total security. I kinda find your alternate shceme, based on bit-for-bit sameness, not to be all that secure, really. It is a feel good thing with little added secueity. However, this is all moot; unless someone does all the work to make things absolutely bit-for-bit the same, compile after compile, and manages to convince all the package ownsers to accept the changes, this is going nowhere. I am not even sure it can be done, technically. manoj -- Work without a vision is slavery, Vision without work is a pipe dream, But vision with work is the hope of the world. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building packages with exact binary matches
On Tue, Sep 25, 2007 at 06:33:40PM -0500, Manoj Srivastava wrote: On Tue, 25 Sep 2007 23:49:17 +0200, Martin Uecker [EMAIL PROTECTED] said: On Mon, Sep 24, 2007 at 06:20:40PM -0500, Manoj Srivastava wrote: On Tue, 25 Sep 2007 00:04:15 +0200, Martin Uecker [EMAIL PROTECTED] said: It would be enough when just a few people are actually recompiling the binaries and compare it to the official debian packages. Then *everbody* could trust that the packages are not modified, because any modification would be detected immediatley. This is only possible with bit-identical binaries. Err, what? Why would everyone do that? I mean, you do not trust the Debian distribution system, the archive gpg signatures, the md5sums on the package, etc, and ye5t you are willing to accept mails from other people that things are oK? No. I would trust the binaries if there are *no mails* from other Ah, security through blissful ignorance :) You do not actually trust the archive, or the developers, you trust the silence. I trust special relativity, because nobody has disproven it yet. Do you think this is blissfull ignorance, too? people that things are *not ok*. Because everybody can check that the binaries are not compromised, you can actually be quite sure that things are ok, as long as nobody complains. And if doubts come up, I can check myself. This actually the same principle on wich science is build: falsifiability. Everyone does that now based on debian archive signatures. You do not need bit-by-bit verification for that. Again: How does this protect against a compromised build host? So, one someone lets the cat out of the bag, and we are not so blissful ,how can we check? Simple, you say, compile the source!! But, dear folks, the person who can compromise the archive, fake out the buildd's, add the archive signature -- can also hack the source. Is actually quite likely that somebody would notice if Debian distributes trojaned source packages. Its exactly the same: Because the source code is open, I would hope that somebody would find the backdoor. Ah. again, assume security until someone pulls us out of our ignorance. See above. So easy to do a denial of service attack by random slander of binaries and source (thanks, helpful botnet). All security work in the free software community works like this: Somebody finds a flaw, he reports it, it gets fixed. So you say this can be DOSed by reporting a lot of false bug reports with a botnet? Compare this to the current system: The trustworthiness of *all* DDs wich maintain packages which are installed on my systems, the security of *all* computers those DDs store their keys on, the security of the build host, the gpg signatures and the md5sums are actually a chain of trust where the weakest link determines the total security. I kinda find your alternate shceme, based on bit-for-bit sameness, not to be all that secure, really. It is a feel good thing with little added secueity. Ironically, I think the current scheme where the binaries are signed by some public key provides a false illusion of security. Have you actually thought about the meaning of this signature? It just means that the signee (and I do not even know who this actually is) believes that this binary was not tampered with. Nothing more. And nobody else has the possibilty to verify this. However, this is all moot; unless someone does all the work to make things absolutely bit-for-bit the same, compile after compile, and manages to convince all the package ownsers to accept the changes, this is going nowhere. I am not even sure it can be done, technically. You are right: Currently, this is all moot. But I find this discussion very interesting. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#443769: rt2500-source: Missing dependency on bzip2
On Wed, Sep 26, 2007 at 01:03:38AM +0200, Bastian Blank wrote: On Wed, Sep 26, 2007 at 08:44:50AM +1000, Hamish Moffatt wrote: It would be consistent with m-a's handling of build-essential. However, I think m-a should depend on build-essential since it always requires it. Therefore we are still undecided about bzip2. m-a don't need build-essential. It needs the compiler (nothing else like libc headers) for the kernel. The debian linux headers already depends against the correct compiler. Maybe so, but m-a prepare installs it. I don't know why it doesn't just depend on it instead. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building packages with exact binary matches
Martin Uecker [EMAIL PROTECTED] writes: On Tue, Sep 25, 2007 at 06:33:40PM -0500, Manoj Srivastava wrote: Ah, security through blissful ignorance :) You do not actually trust the archive, or the developers, you trust the silence. I trust special relativity, because nobody has disproven it yet. Really? I trust the theory of special relativity because there is enormous evidence supporting it, and little evidence against it. In the case of there are no messages, therefore I trust the security of the system, that's faith — belief in spite of an utter lack of evidence. Do you think this is blissfull ignorance, too? Worse, it's foolish. In the lack of *any* evidence either way on a question, it's foolish to hold any position but unknown; and, if the question is important for a matter of trust, it's imperative to *get* some evidence before extending any trust. -- \ A society that will trade a little liberty for a little order | `\ will lose both, and deserve neither. —Thomas Jefferson, in a | _o__)letter to Madison | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Maintainer of package joystick may be missing
On 9/26/07, laszlo kajan [EMAIL PROTECTED] wrote: I then tried to contact the maintainer, Edward Betts ([EMAIL PROTECTED]) on 09/17/2007, with no success. That wasn't very long ago. Please show me the way I can have my patch included in jscal.c of the joystick package. I believe it is useful and I immediately wanted to share it with others. You could try submitting it upstream, but that looks just as inactive: http://sourceforge.net/tracker/?group_id=3063 Eduard Bloch, one of the people listed in joystick debian/copyright is active within Debian. http://packages.debian.org/changelogs/pool/main/j/joystick/current/copyright Perhaps if you contact him, he would be willing to commit the patch upstream and know how to contact Edward. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#443769: rt2500-source: Missing dependency on bzip2
On Wed, 2007-09-26 at 11:26 +1000, Hamish Moffatt wrote: On Wed, Sep 26, 2007 at 01:03:38AM +0200, Bastian Blank wrote: m-a don't need build-essential. It needs the compiler (nothing else like libc headers) for the kernel. The debian linux headers already depends against the correct compiler. Maybe so, but m-a prepare installs it. I don't know why it doesn't just depend on it instead. Perhaps because the specific compiler needed depends on what the current kernel was compiled with? I thought that was the reason linux-headers depended on a specific compiler version. -- Edward Allcutt [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Bug#443769: rt2500-source: Missing dependency on bzip2
On Tue, Sep 25, 2007 at 10:10:52PM -0400, Edward Allcutt wrote: On Wed, 2007-09-26 at 11:26 +1000, Hamish Moffatt wrote: On Wed, Sep 26, 2007 at 01:03:38AM +0200, Bastian Blank wrote: m-a don't need build-essential. It needs the compiler (nothing else like libc headers) for the kernel. The debian linux headers already depends against the correct compiler. Maybe so, but m-a prepare installs it. I don't know why it doesn't just depend on it instead. Perhaps because the specific compiler needed depends on what the current kernel was compiled with? I thought that was the reason linux-headers depended on a specific compiler version. As I said, m-a prepare installs build-essential always. Therefore it may as well just depend on it. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#443769: rt2500-source: Missing dependency on bzip2
On Tue, 25 Sep 2007 22:10:52 -0400, Edward Allcutt [EMAIL PROTECTED] said: Perhaps because the specific compiler needed depends on what the current kernel was compiled with? I thought that was the reason linux-headers depended on a specific compiler version. Has that ever been the case? I've had modules compiled with a different gcc that I had when I compiled the kernel, and never had an issue so far. manoj -- The Marines: The few, the proud, the not very bright. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building packages with exact binary matches
On Wed, 26 Sep 2007 02:45:09 +0200, Martin Uecker [EMAIL PROTECTED] said: On Tue, Sep 25, 2007 at 06:33:40PM -0500, Manoj Srivastava wrote: On Tue, 25 Sep 2007 23:49:17 +0200, Martin Uecker [EMAIL PROTECTED] said: On Mon, Sep 24, 2007 at 06:20:40PM -0500, Manoj Srivastava wrote: On Tue, 25 Sep 2007 00:04:15 +0200, Martin Uecker [EMAIL PROTECTED] said: It would be enough when just a few people are actually recompiling the binaries and compare it to the official debian packages. Then *everbody* could trust that the packages are not modified, because any modification would be detected immediatley. This is only possible with bit-identical binaries. Err, what? Why would everyone do that? I mean, you do not trust the Debian distribution system, the archive gpg signatures, the md5sums on the package, etc, and ye5t you are willing to accept mails from other people that things are oK? No. I would trust the binaries if there are *no mails* from other Ah, security through blissful ignorance :) You do not actually trust the archive, or the developers, you trust the silence. I trust special relativity, because nobody has disproven it yet. Do you think this is blissfull ignorance, too? Actually, partly. I am a quantum mechanic by training (I just went sideways into computer because there was so little money in devoce modeling). I like the special relativity because the math is sound; it has predicted things we were not aware of before; and all kinds of experimental data matches the theory -- except when you get to very very small dimensions, but people are still working on that. Just because you have _heard_ anyone diss special relativity being the sole reason to believe in it is in the same ball park as blissful, you know, ignorance. people that things are *not ok*. Because everybody can check that the binaries are not compromised, you can actually be quite sure that things are ok, as long as nobody complains. And if doubts come up, I can check myself. This actually the same principle on wich science is build: falsifiability. Everyone does that now based on debian archive signatures. You do not need bit-by-bit verification for that. Again: How does this protect against a compromised build host? Doesn't. So, if the archive signature has not been compromised, this is a probably a buggy source. Rebuilding from the tainted source gets you nowhere. But the common case is not this is. Compromised buildd's are a rare occurrence; and when it is detected, auditing the sources and rebuilding on a clean machine is a far better solution than bit for bit same binaries (which is not really much better than the signed Packages file unless you have a trusted path to the sources, which you do not. This lack of a trusted path does the whole let's all rebuild from source and compare our binaries bit. So, one someone lets the cat out of the bag, and we are not so blissful ,how can we check? Simple, you say, compile the source!! But, dear folks, the person who can compromise the archive, fake out the buildd's, add the archive signature -- can also hack the source. Is actually quite likely that somebody would notice if Debian distributes trojaned source packages. Really? What was the last time anyone looked through libsepol library code, eh? Or libselinux code? You do know dpkg and coreutils are linked to that? All security work in the free software community works like this: Somebody finds a flaw, he reports it, it gets fixed. So you say this can be DOSed by reporting a lot of false bug reports with a botnet? No, the bug reporter goes and presents _evidence_ that can be checked, and a patch, or a source of the problem. No one jumps up and down and issue CVE's just become someone says things are not ok. And no one makes a security ssue go away if bunches of people rise up and say the code is juuust fiiine. The difference is evidence. If there is some merit to the notion that a buildd is compromised, the solution is not bunches of people building from potentially tainted sources and comparing checksums. Ironically, I think the current scheme where the binaries are signed by some public key provides a false illusion of security. Have you actually thought about the meaning of this signature? It just means that the signee (and I do not even know who this actually is) believes that this binary was not tampered with. Nothing more. And nobody else has the possibilty to verify this. If you do not know who the signatories of the archive key are, I suggest you leanr, and see how the web of trust thing works for you, and whether or not you can trust the guy doing the builds. Nothing is bullet proof. And no one can make anyone trust anyone, including themselves. Like all security ractices, it is a tradeoff. I have decided to trust my
Accepted libnet-sip-perl 0.37-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 24 Sep 2007 21:22:09 -0600 Source: libnet-sip-perl Binary: libnet-sip-perl Architecture: source all Version: 0.37-1 Distribution: unstable Urgency: low Maintainer: Debian Perl Group [EMAIL PROTECTED] Changed-By: Rene Mayorga [EMAIL PROTECTED] Description: libnet-sip-perl - SIP handler Perl module Changes: libnet-sip-perl (0.37-1) unstable; urgency=low . * New upstream release * Promote Homepage as a valid control field in debian/control Files: 8df09f867c363d8de8e1311674b1eb4c 953 perl optional libnet-sip-perl_0.37-1.dsc b7f695a4d9969541810eea4d88fb4276 128726 perl optional libnet-sip-perl_0.37.orig.tar.gz d04fb7297229025f24380929c224ce98 2260 perl optional libnet-sip-perl_0.37-1.diff.gz 4102ad8ac942eca54d8ddd265505c6cf 208122 perl optional libnet-sip-perl_0.37-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG+KEdHqjlqpcl9jsRAimVAJ9goeq8gaXrfZTTYpyBnnLOFBF0bACdFxps KBcz2NzdoupToaVY2o1ErMM= =FT3O -END PGP SIGNATURE- Accepted: libnet-sip-perl_0.37-1.diff.gz to pool/main/libn/libnet-sip-perl/libnet-sip-perl_0.37-1.diff.gz libnet-sip-perl_0.37-1.dsc to pool/main/libn/libnet-sip-perl/libnet-sip-perl_0.37-1.dsc libnet-sip-perl_0.37-1_all.deb to pool/main/libn/libnet-sip-perl/libnet-sip-perl_0.37-1_all.deb libnet-sip-perl_0.37.orig.tar.gz to pool/main/libn/libnet-sip-perl/libnet-sip-perl_0.37.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted puppet 0.23.2-7 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 25 Sep 2007 16:41:32 +1000 Source: puppet Binary: puppet puppetmaster Architecture: source all Version: 0.23.2-7 Distribution: unstable Urgency: low Maintainer: Matthew Palmer [EMAIL PROTECTED] Changed-By: Matthew Palmer [EMAIL PROTECTED] Description: puppet - centralised configuration management for networks puppetmaster - centralised configuration manangement control daemon Closes: 443932 Changes: puppet (0.23.2-7) unstable; urgency=low . * Ignore ENOENT errors in the module plugin syncing code, since they're innocuous and expected. * Allow facts that are downloaded through pluginsync to be used like any other fact. * Allow users to still have an old-style plugins mount if they want, by specifying a path for the mount. Also track down a fault in old-style fileserving which did strange slash-stripping. Closes: #443932. Files: 50740c80164bb77b2c5f93b131e7e177 683 admin optional puppet_0.23.2-7.dsc cfdae0c38e3e40d6eb6d2f36f108 14121 admin optional puppet_0.23.2-7.diff.gz 87f8da5d5be27ca6ad3bd25bdf4c5539 393816 admin optional puppet_0.23.2-7_all.deb 5f3c7bfd67ab7a64bb2a06f40b03347c 24508 admin optional puppetmaster_0.23.2-7_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFG+LH7BEnrTWk1E4cRAkl7AJ9irdhWUaxaBTiRRNHkkoHtqAqp6ACcDCLl UtC91QOJKZgm7nQfwD04OEA= =4i86 -END PGP SIGNATURE- Accepted: puppet_0.23.2-7.diff.gz to pool/main/p/puppet/puppet_0.23.2-7.diff.gz puppet_0.23.2-7.dsc to pool/main/p/puppet/puppet_0.23.2-7.dsc puppet_0.23.2-7_all.deb to pool/main/p/puppet/puppet_0.23.2-7_all.deb puppetmaster_0.23.2-7_all.deb to pool/main/p/puppet/puppetmaster_0.23.2-7_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted dpkg 1.14.7~newshlib (source i386 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 25 Sep 2007 08:43:45 +0200 Source: dpkg Binary: dpkg dselect dpkg-dev Architecture: source i386 all Version: 1.14.7~newshlib Distribution: experimental Urgency: low Maintainer: Dpkg Developers [EMAIL PROTECTED] Changed-By: Raphael Hertzog [EMAIL PROTECTED] Description: dpkg - package maintenance system for Debian dpkg-dev - package building tools for Debian dselect- user tool to manage Debian packages Closes: 10807 41907 48208 80340 109954 323911 395942 430367 431597 432893 437825 440502 440537 440636 440859 440956 440962 440972 440973 441051 441106 441113 443190 443191 443276 Changes: dpkg (1.14.7~newshlib) experimental; urgency=low . [ Raphael Hertzog ] * dpkg-shlibdeps has been heavily reworked: * it supports symbols files to generate finer-grained dependencies. Closes: #430367 Those files can be created by the new dpkg-gensymbols command. * it uses now all paths in RPATH (instead of only the first). Closes: #395942 * it's now able to parse include directives in /etc/ld.so.conf. Closes: #431597 * libraries are also searched in the public directories of packages being built and thus debian/shlibs.local can effectively define dependencies for libraries that are being built. Closes: #80340 * symbols files use the full SONAME as key instead of splitting it in (name, version) like the shlibs format requires it. This allows binaries to be linked with unversioned libraries and not fail. Closes: #48208 Note that unversioned libraries are still a very bad idea. * dpkg-shlibdeps now supports -xpackage options that can be used to exclude packages from generated dependencies. This is particalularly useful to avoid dependencies on ourselves when a package contains a binary and a library (without requiring an shlibs.local file to override the usual shlibs file). It might also be used to avoid other unwanted dependencies (use with care though). Closes: #41907, #109954 * If dpkg-shlibdeps doesn't find any dependency information for a shared library that is actively used, then it will fail. This can be disabled with the option --ignore-missing-info. Closes: #10807 . [ Guillem Jover ] * Add back $dpkglib into @INC, needed by the controllib.pl require in 822-date. Closes: #440962 * Document in dpkg-scanpackages that apt now requires Packages.bz2 in preference to Packages.gz. Closes: #440973 * Stop recognizing the obsolete Optional field when building packages. * Use fakeroot, if present, by default to gain root privileges in dpkg-buildpackage. * Fix typos in dpkg-deb.1 and start-stop-daemon.8. Closes: #441051 Thanks to A. Costa. * After 'prerm remove' fails and while doing the error unwinding, if the 'postinst abort-remove' call succeeds, preserve the old status instead of unconditionally setting it to 'Installed'. Closes: #432893 Thanks to Brian M. Carlson. * Add Vcs-Browser and Vcs-Git fields to debian/control. . [ Frank Lichtenheld ] * Add _MTN to dpkg-source -i default regex. Suggested by Jari Aalto. * Convert dpkg-buildpackage to a Perl script. * dpkg-buildpackage accepts a -jn option now which will set MAKEFLAGS(-jn) and DEB_BUILD_OPTIONS(parallel=n) accordingly. parallel=n in DEB_BUILD_OPTIONS will be passed to MAKEFLAGS as well. Based on an idea by Robert Millan. Closes: #440636 * Allow dpkg-source -I without a pattern which will load a default list of pattern similar to -i without regexp. Patch by Jari Aalto. Closes: #440972 * Rework documentation of dpkg-source's -i and -I options. Closes: #323911, #440956 . [ Updated dpkg translations ] * Basque (Piarres Beobide). Closes: #440859 * Danish (Claus Hindsgaul). Closes: #441106 * French (Frédéric Bothamy). * German (Sven Joachim). Closes: #440537 * Nepali (Shiva Prasad Pokharel). Closes: #437825 * Portuguese (Miguel Figueiredo). Closes: #441113 * Romanian (Eddy Petri?or). * Vietnamese (Clytie Siddall). Closes: #440502 * Korean (Sunjae Park). Closes: #443190 . [ Updated man pages translations ] * German (Helge Kreutzmann). * Swedish (Peter Karlsson). * Korean (Sunjae Park). Closes: #443191 . [ Updated scripts translations ] * Correct a typo in the French translation. Closes: #443276 Files: 0e724edaf152da5368df1936f424dc2e 969 admin required dpkg_1.14.7~newshlib.dsc 1e4de4e5968f91365cc0d39034411b79 5939940 admin required dpkg_1.14.7~newshlib.tar.gz 559bd1d755610c0eb14387bedad23a44 2089802 admin required dpkg_1.14.7~newshlib_i386.deb 9a77429db7fcad1eacaf86f412174c78 508702 admin required dselect_1.14.7~newshlib_i386.deb 434b8a6b1500244b69fc7d26548d70e6 240362 utils optional dpkg-dev_1.14.7~newshlib_all.deb -BEGIN PGP SIGNATURE-
Accepted gozerbot 0.7.1.1-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 25 Sep 2007 14:45:03 +0800 Source: gozerbot Binary: gozerbot Architecture: source all Version: 0.7.1.1-1 Distribution: unstable Urgency: low Maintainer: Jeremy Malcolm [EMAIL PROTECTED] Changed-By: Jeremy Malcolm [EMAIL PROTECTED] Description: gozerbot - An IRC and Jabber bot written in Python Changes: gozerbot (0.7.1.1-1) unstable; urgency=low . * New upstream release. Files: bcfe838c8aefbc1b34d60ca91af48d1a 586 net optional gozerbot_0.7.1.1-1.dsc 8d1bd4f7b24f2bbd81006d9c166a1837 2032170 net optional gozerbot_0.7.1.1-1.tar.gz f8fbe1f37d0c99ef64f814acb6f6bc10 312468 net optional gozerbot_0.7.1.1-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG+K8A9nWq4tKrIiARAoMhAKD4rRF6bU/PbAlDTAnXC86oJMHS0wCfQyP0 9NYewDK66q0u9GKTGdVYFN4= =YJlI -END PGP SIGNATURE- Accepted: gozerbot_0.7.1.1-1.dsc to pool/main/g/gozerbot/gozerbot_0.7.1.1-1.dsc gozerbot_0.7.1.1-1.tar.gz to pool/main/g/gozerbot/gozerbot_0.7.1.1-1.tar.gz gozerbot_0.7.1.1-1_all.deb to pool/main/g/gozerbot/gozerbot_0.7.1.1-1_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted dropbear 0.50-2 (source powerpc)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 24 Sep 2007 16:49:17 + Source: dropbear Binary: dropbear Architecture: source powerpc Version: 0.50-2 Distribution: unstable Urgency: low Maintainer: Gerrit Pape [EMAIL PROTECTED] Changed-By: Gerrit Pape [EMAIL PROTECTED] Description: dropbear - lightweight SSH2 server and client Closes: 441515 Changes: dropbear (0.50-2) unstable; urgency=low . * debian/dropbear.README.Debian: no longer talk about entropy from /dev/random, /dev/urandom is now used by default (thx Joey Hess, closes: #441515). Files: 171379c6876b213c55941d8c26a50777 550 net optional dropbear_0.50-2.dsc 928fde7c9001b78a5b89e6fdf44345d9 2481 net optional dropbear_0.50-2.diff.gz 45e87817958a67ac60584452144234df 236646 net optional dropbear_0.50-2_powerpc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG+Lo7GJoyQbxwpv8RAm77AJ9q8E4DZfM8/yZbamQwFcMeW5OjjACfb7pJ JzIkDjH42BiEYY38PD9ZIGY= =BWC6 -END PGP SIGNATURE- Accepted: dropbear_0.50-2.diff.gz to pool/main/d/dropbear/dropbear_0.50-2.diff.gz dropbear_0.50-2.dsc to pool/main/d/dropbear/dropbear_0.50-2.dsc dropbear_0.50-2_powerpc.deb to pool/main/d/dropbear/dropbear_0.50-2_powerpc.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted dash 0.5.4-2 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 25 Sep 2007 07:39:37 + Source: dash Binary: dash-udeb ash dash Architecture: all source Version: 0.5.4-2 Distribution: unstable Urgency: low Maintainer: Gerrit Pape [EMAIL PROTECTED] Changed-By: Gerrit Pape [EMAIL PROTECTED] Description: ash- Compatibility package for the Debian Almquist Shell dash - The Debian Almquist Shell dash-udeb - The Debian Almquist Shell for boot floppies (udeb) Closes: 373611 387441 431320 Changes: dash (0.5.4-2) unstable; urgency=low . * debian/diff/0001-SHELL-Restore-foreground-process-group-on-exit.diff: new; from upstream git, replaces debian/diff/0001-Restore-pgrp-on-exit-fix-backgrounded-MC-bug.diff. * debian/diff/0002-SHELL-Move-flushall-to-the-point-just-before-_exit.diff, debian/diff/0003-BUILTIN-test-White-space-fixes.diff, debian/diff/0004-BUILTIN-test-little-size-and-speed-optimizations.diff: new; from upstream git (closes: #431320). * debian/diff/0005-dash.1-clarify-description-of-nt-ot-options-to-te.diff: new; dash.1: clarify description of -nt, -ot options to test builtin (closes: #373611). * debian/diff/0006-dash.1-clarify-syntax-of-the-for-command.diff: new; dash.1: clarify syntax of the for command (closes: #387441). Files: 14e60127147becf26f5b02f52a27f8ce 639 shells optional dash_0.5.4-2.dsc 659679b20be39c81e443b1e90af3b7f5 27205 shells optional dash_0.5.4-2.diff.gz 867ca4a775a8cf98a2e9dc8eafb6f303 18544 shells optional ash_0.5.4-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG+MT/GJoyQbxwpv8RAo2AAKCBGDC+7LsjqHEAuwHZSxaEE7AAyQCfR3Bt L6qQ8UuaYrznGfGXXeKfFPM= =kqSM -END PGP SIGNATURE- Accepted: ash_0.5.4-2_all.deb to pool/main/d/dash/ash_0.5.4-2_all.deb dash_0.5.4-2.diff.gz to pool/main/d/dash/dash_0.5.4-2.diff.gz dash_0.5.4-2.dsc to pool/main/d/dash/dash_0.5.4-2.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted xserver-xorg-video-sunleo 1:1.1.0-3 (source sparc)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 25 Sep 2007 10:37:29 +0200 Source: xserver-xorg-video-sunleo Binary: xserver-xorg-video-sunleo Architecture: source sparc Version: 1:1.1.0-3 Distribution: unstable Urgency: low Maintainer: Debian X Strike Force [EMAIL PROTECTED] Changed-By: Julien Cristau [EMAIL PROTECTED] Description: xserver-xorg-video-sunleo - X.Org X server -- Sun Leo display driver Changes: xserver-xorg-video-sunleo (1:1.1.0-3) unstable; urgency=low . [ David Nusinow ] * Generate server dependencies automatically from the ABI . [ Julien Cristau ] * Add link to xserver-xorg-core bug script, so that bugreports contain the user's config and log files. * Add myself to Uploaders, and remove Branden with his permission. * Rebuild against xserver 1.4. . [ Brice Goglin ] * Pull upstream manpage fix fe5af18d4bc8fc095e3b12d1030b6e5765c7e3a4 * Install the upstream changelog. * Bump Build-Depends: xserver-xorg-dev to = 2:1.2.99.902 (needed to let xsfbs get access to serverminver). * Add XS-Vcs-*. * Add a link to www.X.org and a reference to the xf86-video-sunleo module in the long description. * Remove Fabio from uploaders with his permission. He's always welcome back. * Add upstream URL to debian/copyright. . [ Timo Aaltonen ] * Replaces/Conflicts: xserver-xorg-driver-sunleo. Files: 7921a4fb8d6b1a67e546f715c7ebd789 1059 x11 optional xserver-xorg-video-sunleo_1.1.0-3.dsc 2e60568067b3785afca8de57550388b6 111692 x11 optional xserver-xorg-video-sunleo_1.1.0-3.diff.gz 6fe13897a65844c6a4c352b4645fac89 19102 x11 optional xserver-xorg-video-sunleo_1.1.0-3_sparc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG+M1XmEvTgKxfcAwRAj/4AJ9EOjIe40fZNTCuH9uxyqo799FmdwCeI3Xx KAwvsm1fk1x3JyoQvWeMWp8= =Rh34 -END PGP SIGNATURE- Accepted: xserver-xorg-video-sunleo_1.1.0-3.diff.gz to pool/main/x/xserver-xorg-video-sunleo/xserver-xorg-video-sunleo_1.1.0-3.diff.gz xserver-xorg-video-sunleo_1.1.0-3.dsc to pool/main/x/xserver-xorg-video-sunleo/xserver-xorg-video-sunleo_1.1.0-3.dsc xserver-xorg-video-sunleo_1.1.0-3_sparc.deb to pool/main/x/xserver-xorg-video-sunleo/xserver-xorg-video-sunleo_1.1.0-3_sparc.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted xserver-xorg-video-sunbw2 1:1.1.0-5 (source sparc)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 25 Sep 2007 10:00:36 +0200 Source: xserver-xorg-video-sunbw2 Binary: xserver-xorg-video-sunbw2 Architecture: source sparc Version: 1:1.1.0-5 Distribution: unstable Urgency: low Maintainer: Debian X Strike Force [EMAIL PROTECTED] Changed-By: Julien Cristau [EMAIL PROTECTED] Description: xserver-xorg-video-sunbw2 - X.Org X server -- Sun BW2 display driver Changes: xserver-xorg-video-sunbw2 (1:1.1.0-5) unstable; urgency=low . [ Julien Cristau ] * Add link to xserver-xorg-core bug script, so that bugreports contain the user's config and log files. * Rebuild against xserver 1.4. * Add myself to Uploaders, and remove Branden with his permission. . [ Brice Goglin ] * Pull upstream manpage fix 4b97b50a48eb0b3a978d7d4fb082e07f51363953 * Install the upstream changelog. * Add XS-Vcs-*. * Add a link to www.X.org and a reference to the xf86-video-sunbw2 module in the long description. * Remove Fabio from uploaders with his permission. He's always welcome back. * Add upstream URL to debian/copyright. . [ Timo Aaltonen ] * Replaces/Conflicts: xserver-xorg-driver-sunbw2. Files: 5c3275a148ded4b322070ddf34f2892a 1011 x11 optional xserver-xorg-video-sunbw2_1.1.0-5.dsc c8f36773a9a8b39b46c137d45baa2eae 111834 x11 optional xserver-xorg-video-sunbw2_1.1.0-5.diff.gz 8ff51a60799db250d64bff80f775977e 11174 x11 optional xserver-xorg-video-sunbw2_1.1.0-5_sparc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG+MMUmEvTgKxfcAwRApA+AKCKmN4AoMEvv/Rm4g/owmUUvj+/pgCaAjKI tny/wngM/MDuVr0h+ZqKXw8= =C8Nn -END PGP SIGNATURE- Accepted: xserver-xorg-video-sunbw2_1.1.0-5.diff.gz to pool/main/x/xserver-xorg-video-sunbw2/xserver-xorg-video-sunbw2_1.1.0-5.diff.gz xserver-xorg-video-sunbw2_1.1.0-5.dsc to pool/main/x/xserver-xorg-video-sunbw2/xserver-xorg-video-sunbw2_1.1.0-5.dsc xserver-xorg-video-sunbw2_1.1.0-5_sparc.deb to pool/main/x/xserver-xorg-video-sunbw2/xserver-xorg-video-sunbw2_1.1.0-5_sparc.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted xserver-xorg-video-suncg3 1:1.1.0-3 (source sparc)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 25 Sep 2007 10:20:51 +0200 Source: xserver-xorg-video-suncg3 Binary: xserver-xorg-video-suncg3 Architecture: source sparc Version: 1:1.1.0-3 Distribution: unstable Urgency: low Maintainer: Debian X Strike Force [EMAIL PROTECTED] Changed-By: Julien Cristau [EMAIL PROTECTED] Description: xserver-xorg-video-suncg3 - X.Org X server -- Sun CG3 display driver Changes: xserver-xorg-video-suncg3 (1:1.1.0-3) unstable; urgency=low . [ David Nusinow ] * Generate server dependencies automatically from the ABI . [ Julien Cristau ] * Add link to xserver-xorg-core bug script, so that bugreports contain the user's config and log files. * Add myself to Uploaders, and remove Branden with his permission. * Rebuild against xserver 1.4. . [ Brice Goglin ] * Pull upstream manpage fix ba46a263cca120175d5a669f8bec56508560dd03 * Install the upstream changelog. * Bump Build-Depends: xserver-xorg-dev to = 2:1.2.99.902 (needed to let xsfbs get access to serverminver). * Add XS-Vcs-*. * Add a link to www.X.org and a reference to the xf86-video-suncg3 module in the long description. * Remove Fabio from uploaders with his permission. He's always welcome back. * Add upstream URL to debian/copyright. . [ Timo Aaltonen ] * Replaces/Conflicts: xserver-xorg-driver-suncg3. Files: 15e4bf41da9bbee2bbacddab166c996d 1059 x11 optional xserver-xorg-video-suncg3_1.1.0-3.dsc b57c8e9f16c4eb3dd56d3bd8e489a178 111356 x11 optional xserver-xorg-video-suncg3_1.1.0-3.diff.gz 904169aafd6c6ba448cc38ebf24b8a70 10824 x11 optional xserver-xorg-video-suncg3_1.1.0-3_sparc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG+MfEmEvTgKxfcAwRAk8JAKCJMIO7FxPK5UjaTMc8dh2F9H++xACfdhig kMsftJt+biphDKwr27w11SE= =WNaL -END PGP SIGNATURE- Accepted: xserver-xorg-video-suncg3_1.1.0-3.diff.gz to pool/main/x/xserver-xorg-video-suncg3/xserver-xorg-video-suncg3_1.1.0-3.diff.gz xserver-xorg-video-suncg3_1.1.0-3.dsc to pool/main/x/xserver-xorg-video-suncg3/xserver-xorg-video-suncg3_1.1.0-3.dsc xserver-xorg-video-suncg3_1.1.0-3_sparc.deb to pool/main/x/xserver-xorg-video-suncg3/xserver-xorg-video-suncg3_1.1.0-3_sparc.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted xserver-xorg-video-sunffb 1:1.1.0-3 (source sparc)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 25 Sep 2007 10:31:33 +0200 Source: xserver-xorg-video-sunffb Binary: xserver-xorg-video-sunffb Architecture: source sparc Version: 1:1.1.0-3 Distribution: unstable Urgency: low Maintainer: Debian X Strike Force [EMAIL PROTECTED] Changed-By: Julien Cristau [EMAIL PROTECTED] Description: xserver-xorg-video-sunffb - X.Org X server -- Sun FFB display driver Changes: xserver-xorg-video-sunffb (1:1.1.0-3) unstable; urgency=low . [ David Nusinow ] * Generate server dependencies automatically from the ABI . [ Julien Cristau ] * Add link to xserver-xorg-core bug script, so that bugreports contain the user's config and log files. * Add myself to uploaders, and remove Branden with his permission. * Rebuild against xserver 1.4. . [ Brice Goglin ] * Pull upstream manpage fix b86a3f4662d384e3a3540340bfd5171ab2523c34 * Install the upstream changelog. * Generate Provides: line automatically. * Bump Build-Depends: xserver-xorg-dev to = 2:1.2.99.902 (needed to let xsfbs get access to serverminver). * Add XS-Vcs-*. * Add a link to www.X.org and a reference to the xf86-video-sunffb module in the long description. * Remove Fabio from uploaders with his permission. He's always welcome back. * Add upstream URL to debian/copyright. . [ Timo Aaltonen ] * Replaces/Conflicts: xserver-xorg-driver-sunffb. Files: 0588c8092f45e2e3e5b5a279c841bb9a 1175 x11 optional xserver-xorg-video-sunffb_1.1.0-3.dsc 575cc983170d0af4e416c34c0413537e 116499 x11 optional xserver-xorg-video-sunffb_1.1.0-3.diff.gz fb2f2908e6b609f7ef7844f7cbab1186 36876 x11 optional xserver-xorg-video-sunffb_1.1.0-3_sparc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG+MknmEvTgKxfcAwRAlbgAJ4lctBJJkPs8ZwbU750GflRc/mpvACg09Cc zc2QgL/imGRn3aQzWIbdfzI= =LX66 -END PGP SIGNATURE- Accepted: xserver-xorg-video-sunffb_1.1.0-3.diff.gz to pool/main/x/xserver-xorg-video-sunffb/xserver-xorg-video-sunffb_1.1.0-3.diff.gz xserver-xorg-video-sunffb_1.1.0-3.dsc to pool/main/x/xserver-xorg-video-sunffb/xserver-xorg-video-sunffb_1.1.0-3.dsc xserver-xorg-video-sunffb_1.1.0-3_sparc.deb to pool/main/x/xserver-xorg-video-sunffb/xserver-xorg-video-sunffb_1.1.0-3_sparc.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted xserver-xorg-video-suntcx 1:1.1.0-3 (source sparc)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 25 Sep 2007 10:44:09 +0200 Source: xserver-xorg-video-suntcx Binary: xserver-xorg-video-suntcx Architecture: source sparc Version: 1:1.1.0-3 Distribution: unstable Urgency: low Maintainer: Debian X Strike Force [EMAIL PROTECTED] Changed-By: Julien Cristau [EMAIL PROTECTED] Description: xserver-xorg-video-suntcx - X.Org X server -- Sun TCX display driver Changes: xserver-xorg-video-suntcx (1:1.1.0-3) unstable; urgency=low . [ Julien Cristau ] * Add link to xserver-xorg-core bug script, so that bugreports contain the user's config and log files. * Add myself to Uploaders and remove Branden with his permission. * Rebuild against xserver 1.4. . [ Brice Goglin ] * Install the upstream changelog. * Generate server dependencies automatically from the ABI. * Generate Provides: line automatically. * Bump Build-Depends: xserver-xorg-dev to = 2:1.2.99.902 (needed to let xsfbs get access to serverminver). * Add XS-Vcs-*. * Add a link to www.X.org and a reference to the xf86-video-suntcx module in the long description. * Remove Fabio from uploaders with his permission. He's always welcome back. * Add upstream URL to debian/copyright. . [ Timo Aaltonen ] * Replaces/Conflicts: xserver-xorg-driver-suntcx. Files: 592ef1ff2e8d98702e2397cf89e73940 1059 x11 optional xserver-xorg-video-suntcx_1.1.0-3.dsc 77d2f339b75b778cdf83909474cb0e9a 111465 x11 optional xserver-xorg-video-suntcx_1.1.0-3.diff.gz ff82bff4192f6a415c690f7c75819e6e 13288 x11 optional xserver-xorg-video-suntcx_1.1.0-3_sparc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG+MwtmEvTgKxfcAwRAr/2AJ4ieVlAR0B+qmSlB18IuNpLrL5zAwCfcoGn Kn9stZRS6ubefLSaSl+o5kY= =p9wf -END PGP SIGNATURE- Accepted: xserver-xorg-video-suntcx_1.1.0-3.diff.gz to pool/main/x/xserver-xorg-video-suntcx/xserver-xorg-video-suntcx_1.1.0-3.diff.gz xserver-xorg-video-suntcx_1.1.0-3.dsc to pool/main/x/xserver-xorg-video-suntcx/xserver-xorg-video-suntcx_1.1.0-3.dsc xserver-xorg-video-suntcx_1.1.0-3_sparc.deb to pool/main/x/xserver-xorg-video-suntcx/xserver-xorg-video-suntcx_1.1.0-3_sparc.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted xserver-xorg-video-suncg14 1:1.1.0-4 (source sparc)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 25 Sep 2007 10:13:58 +0200 Source: xserver-xorg-video-suncg14 Binary: xserver-xorg-video-suncg14 Architecture: source sparc Version: 1:1.1.0-4 Distribution: unstable Urgency: low Maintainer: Debian X Strike Force [EMAIL PROTECTED] Changed-By: Julien Cristau [EMAIL PROTECTED] Description: xserver-xorg-video-suncg14 - X.Org X server -- Sun CG14 display driver Changes: xserver-xorg-video-suncg14 (1:1.1.0-4) unstable; urgency=low . [ David Nusinow ] * Generate server dependencies automatically from the ABI . [ Julien Cristau ] * Add link to xserver-xorg-core bug script, so that bugreports contain the user's config and log files. * Add myself to Uploaders, and remove Branden with his permission. * Rebuild against xserver 1.4. . [ Brice Goglin ] * Install the upstream changelog. * Bump Build-Depends: xserver-xorg-dev to = 2:1.2.99.902 (needed to let xsfbs get access to serverminver). * Add XS-Vcs-*. * Add a link to www.X.org and a reference to the xf86-video-suncg14 module in the long description. * Remove Fabio from uploaders with his permission. He's always welcome back. * Pull upstream manpage fix e37c03efea954f675961f2b1babbfb0787f4d3c9 * Add upstream URL to debian/copyright. . [ Timo Aaltonen ] * Replaces/Conflicts: xserver-xorg-driver-suncg14. Files: 4addbea93e75147069d7b14463ffc361 1065 x11 optional xserver-xorg-video-suncg14_1.1.0-4.dsc cd39bfd1f0f3d81519895e7ea6c4bd47 111221 x11 optional xserver-xorg-video-suncg14_1.1.0-4.diff.gz 87797c76cad29e3663c32547aef37fc2 11436 x11 optional xserver-xorg-video-suncg14_1.1.0-4_sparc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG+MXdmEvTgKxfcAwRAuleAKC0ZCcdKciQalNk0Sli9GzgtnupjwCgvZcP BVL9+E4AFfCVwlUWJ0L4aFU= =Hg42 -END PGP SIGNATURE- Accepted: xserver-xorg-video-suncg14_1.1.0-4.diff.gz to pool/main/x/xserver-xorg-video-suncg14/xserver-xorg-video-suncg14_1.1.0-4.diff.gz xserver-xorg-video-suncg14_1.1.0-4.dsc to pool/main/x/xserver-xorg-video-suncg14/xserver-xorg-video-suncg14_1.1.0-4.dsc xserver-xorg-video-suncg14_1.1.0-4_sparc.deb to pool/main/x/xserver-xorg-video-suncg14/xserver-xorg-video-suncg14_1.1.0-4_sparc.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted scponly 4.6-1.1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 25 Sep 2007 10:06:31 + Source: scponly Binary: scponly Architecture: source i386 Version: 4.6-1.1 Distribution: unstable Urgency: high Maintainer: Thomas Wana [EMAIL PROTECTED] Changed-By: Steffen Joeris [EMAIL PROTECTED] Description: scponly- Restricts the commands available to scp- and sftp-users Closes: 437148 Changes: scponly (4.6-1.1) unstable; urgency=high . * Non-maintainer upload by the testing-security team * Disable unison, rsync and svn usability, because all three could be exploited. (Closes: #437148) - The maintainer is working on splitting the packages and providing a binary package, which enables these features, but warns about them and one, which is safe and has them disabled, like this Files: cbc36940db279059d177f6fcef59ecec 592 utils optional scponly_4.6-1.1.dsc e5c1efbf4f95143271b5259d6a3765f2 28435 utils optional scponly_4.6-1.1.diff.gz f8e48b6b8bb8066570ce13eec06647a7 33012 utils optional scponly_4.6-1.1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG+OKK62zWxYk/rQcRAs3JAJsEcXcVgHSn2YQXjkdRnwZq0zk2DACgqtLr QPFLwPP1jhLEjtQLfqDAnjA= =ePCh -END PGP SIGNATURE- Accepted: scponly_4.6-1.1.diff.gz to pool/main/s/scponly/scponly_4.6-1.1.diff.gz scponly_4.6-1.1.dsc to pool/main/s/scponly/scponly_4.6-1.1.dsc scponly_4.6-1.1_i386.deb to pool/main/s/scponly/scponly_4.6-1.1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted epiphany-extensions 2.20.0-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 21 Sep 2007 17:55:37 +0200 Source: epiphany-extensions Binary: epiphany-extensions Architecture: source amd64 Version: 2.20.0-1 Distribution: unstable Urgency: low Maintainer: Josselin Mouette [EMAIL PROTECTED] Changed-By: Josselin Mouette [EMAIL PROTECTED] Description: epiphany-extensions - Extensions for Epiphany web browser Changes: epiphany-extensions (2.20.0-1) unstable; urgency=low . * New upstream release. + Use --enable-gecko. * Depend on epiphany-gecko, not epiphany-browser. * 01_download_dir.patch: removed, obsoleted by improvements in the epiphany patch. * 50_fr-po.patch: removed, merged upstream. * Enable livehttpheaders and permissions extensions. Files: 10939e59358b8e5e9c26fc9563addccf 1177 gnome optional epiphany-extensions_2.20.0-1.dsc b59beb53eec83a32518cdf6a46ab881c 1355728 gnome optional epiphany-extensions_2.20.0.orig.tar.gz c27e4e1123d618b7689d7a86114e971c 5179 gnome optional epiphany-extensions_2.20.0-1.diff.gz 3e148cb2518c69c40cfe2c2ece0da600 827594 gnome optional epiphany-extensions_2.20.0-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG+OaOrSla4ddfhTMRAs2KAKDoKE1QuE70J7iMHO0uqALrPfaFYwCdGCc4 ilMAwrcuzhn5xBCYnsqV0EU= =//nm -END PGP SIGNATURE- Accepted: epiphany-extensions_2.20.0-1.diff.gz to pool/main/e/epiphany-extensions/epiphany-extensions_2.20.0-1.diff.gz epiphany-extensions_2.20.0-1.dsc to pool/main/e/epiphany-extensions/epiphany-extensions_2.20.0-1.dsc epiphany-extensions_2.20.0-1_amd64.deb to pool/main/e/epiphany-extensions/epiphany-extensions_2.20.0-1_amd64.deb epiphany-extensions_2.20.0.orig.tar.gz to pool/main/e/epiphany-extensions/epiphany-extensions_2.20.0.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gtkhtml3.14 3.16.0-2 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 25 Sep 2007 13:31:45 +0200 Source: gtkhtml3.14 Binary: libgtkhtml3.14-dev libgtkhtml3.14-dbg gtkhtml3.14 libgtkhtml3.14-19 Architecture: source i386 Version: 3.16.0-2 Distribution: unstable Urgency: low Maintainer: Debian Evolution Maintainers [EMAIL PROTECTED] Changed-By: Loic Minier [EMAIL PROTECTED] Description: gtkhtml3.14 - HTML rendering/editing library - bonobo component binary libgtkhtml3.14-19 - HTML rendering/editing library - runtime files libgtkhtml3.14-dbg - HTML rendering/editing library - debug files libgtkhtml3.14-dev - HTML rendering/editing library - development files Closes: 443931 Changes: gtkhtml3.14 (3.16.0-2) unstable; urgency=low . [ Loic Minier ] * Merge never uploaded 3.15.3-1 changelog entry into 3.16.0-1. . [ Heikki Henriksen ] * Add versioned replaces and conflicts gtkhtml3.14 ( 3.16.0) to libgtkhtml3.14-19 (closes: #443931) . [ Loic Minier ] * Set GNOME_MODULE to gtkhtml. Files: 658282a7ad4ef84cbcd08a88595f73a6 1168 gnome optional gtkhtml3.14_3.16.0-2.dsc 1a0a277e719b173f477a406bbe61b5c2 8248 gnome optional gtkhtml3.14_3.16.0-2.diff.gz c5abed7ed804b099abe6b08a4f975414 133218 gnome optional gtkhtml3.14_3.16.0-2_i386.deb 4034025258cb10a942b23c0333b0c6ab 810986 libs optional libgtkhtml3.14-19_3.16.0-2_i386.deb d12c7eb9a7553caa0a867106e2816aa2 354542 libdevel optional libgtkhtml3.14-dev_3.16.0-2_i386.deb 111df4d6a04c92dec74ce0b0fd0c4bd9 1315726 libdevel extra libgtkhtml3.14-dbg_3.16.0-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG+PNv4VUX8isJIMARAhCvAJ92GgPBr7DR9HIckLEPp7p3ohKEjwCeO+hl uNbvFEFgnuwEdqf/dqsoUhE= =7GA1 -END PGP SIGNATURE- Accepted: gtkhtml3.14_3.16.0-2.diff.gz to pool/main/g/gtkhtml3.14/gtkhtml3.14_3.16.0-2.diff.gz gtkhtml3.14_3.16.0-2.dsc to pool/main/g/gtkhtml3.14/gtkhtml3.14_3.16.0-2.dsc gtkhtml3.14_3.16.0-2_i386.deb to pool/main/g/gtkhtml3.14/gtkhtml3.14_3.16.0-2_i386.deb libgtkhtml3.14-19_3.16.0-2_i386.deb to pool/main/g/gtkhtml3.14/libgtkhtml3.14-19_3.16.0-2_i386.deb libgtkhtml3.14-dbg_3.16.0-2_i386.deb to pool/main/g/gtkhtml3.14/libgtkhtml3.14-dbg_3.16.0-2_i386.deb libgtkhtml3.14-dev_3.16.0-2_i386.deb to pool/main/g/gtkhtml3.14/libgtkhtml3.14-dev_3.16.0-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted elinks 0.11.1-1.5 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 25 Sep 2007 13:31:18 +0200 Source: elinks Binary: elinks-lite elinks Architecture: source i386 Version: 0.11.1-1.5 Distribution: unstable Urgency: high Maintainer: Peter Gervai [EMAIL PROTECTED] Changed-By: Nico Golde [EMAIL PROTECTED] Description: elinks - advanced text-mode WWW browser elinks-lite - advanced text-mode WWW browser (lite version) Closes: 443891 443914 Changes: elinks (0.11.1-1.5) unstable; urgency=high . * Non-maintainer upload by testing security team. * Fixed bug in http.c which could lead to secret information disclosure via POST requests for https URLs (CVE-2007-5034) (Closes: #443914, #443891). Files: 28570cb79f8fdceafd651d32eb4a07e4 768 web optional elinks_0.11.1-1.5.dsc dcf412b2fe9fbe08a425369c0febfae1 31355 web optional elinks_0.11.1-1.5.diff.gz 1bb7bd13581ce45e0707af321720826f 1183132 web optional elinks_0.11.1-1.5_i386.deb ddcb1e71e898f86d43e07d255fc873b7 424910 web optional elinks-lite_0.11.1-1.5_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG+PYaHYflSXNkfP8RAhH0AJ0QRA9/O1FdlwSrPoDQquv7iPUyxACgnWv2 5A/f3eAxAL0udHBEcMdLJ2U= =LcDr -END PGP SIGNATURE- Accepted: elinks-lite_0.11.1-1.5_i386.deb to pool/main/e/elinks/elinks-lite_0.11.1-1.5_i386.deb elinks_0.11.1-1.5.diff.gz to pool/main/e/elinks/elinks_0.11.1-1.5.diff.gz elinks_0.11.1-1.5.dsc to pool/main/e/elinks/elinks_0.11.1-1.5.dsc elinks_0.11.1-1.5_i386.deb to pool/main/e/elinks/elinks_0.11.1-1.5_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted dpkg 1.14.7~newshlib.1 (source i386 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 25 Sep 2007 13:42:20 +0200 Source: dpkg Binary: dpkg dselect dpkg-dev Architecture: source i386 all Version: 1.14.7~newshlib.1 Distribution: experimental Urgency: low Maintainer: Dpkg Developers [EMAIL PROTECTED] Changed-By: Raphael Hertzog [EMAIL PROTECTED] Description: dpkg - package maintenance system for Debian dpkg-dev - package building tools for Debian dselect- user tool to manage Debian packages Changes: dpkg (1.14.7~newshlib.1) experimental; urgency=low . * Fixes dpkg-gensymbols to use Dpkg::Gettext instead of recently removed dpkg-gettext.pl. Files: 69abd4bce284fdbcfc329632f93844b4 973 admin required dpkg_1.14.7~newshlib.1.dsc aa082b4eb790c2912c81c97264b93469 5939992 admin required dpkg_1.14.7~newshlib.1.tar.gz 35e5e2bc86226fe3afad01b3867bc583 2089830 admin required dpkg_1.14.7~newshlib.1_i386.deb fe2c6104cf0006eb527d6992f55b04cd 508778 admin required dselect_1.14.7~newshlib.1_i386.deb 3ea63bdebcfdfa275daad777aec1aa1b 240350 utils optional dpkg-dev_1.14.7~newshlib.1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG+QG2vPbGD26BadIRAmtuAKCWDPe44vKDklN15jnvbYab4C7+NwCfS5UW KATvHyfBH8MnddIGGoNZ1vQ= =i1V/ -END PGP SIGNATURE- Accepted: dpkg-dev_1.14.7~newshlib.1_all.deb to pool/main/d/dpkg/dpkg-dev_1.14.7~newshlib.1_all.deb dpkg_1.14.7~newshlib.1.dsc to pool/main/d/dpkg/dpkg_1.14.7~newshlib.1.dsc dpkg_1.14.7~newshlib.1.tar.gz to pool/main/d/dpkg/dpkg_1.14.7~newshlib.1.tar.gz dpkg_1.14.7~newshlib.1_i386.deb to pool/main/d/dpkg/dpkg_1.14.7~newshlib.1_i386.deb dselect_1.14.7~newshlib.1_i386.deb to pool/main/d/dpkg/dselect_1.14.7~newshlib.1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
