Re: Reviving schroot as used by sbuild
Hi, On 2024-06-29 22:21, Christian Kastner wrote: At the moment, rootless Podman would seem like the obvious choice. As far as I'm aware, it has the same user namespaces requirements as the unshare backends in mmdebstrap, autopkgtest and schroot (user namespaces enabled, setuid newuidmap, 65536 uids in /etc/subuid, 65536 gids in /etc/subgid). As a datapoint, I use rootless podman containers extensively both for autopkgtest and as an sbuild backend (though the latter is affected by #1033352 for which I still need to implement a cleaner workaround). I think the only problem I encountered was a corner case when passing in a device into a container: at some point, autopkgtest runs su which uses the setgroups() syscall, and group permissions get lost. The solution was to setup up the proper gidmaps. I documented my findings here [1]. Though this latter issue shouldn't be a problem on buildds, where devices aren't passed in. How well does this setup nest? I had a lot of trouble trying to run the unshare backend within an unprivileged container as setup by systemd-nspawn - mostly with device nodes. In the end I had to give up and replaced the container with a full-blown VM. I understand that some of the things compose a little if the submaps are set up correctly, with less IDs allocated to the nested child. Is there a way to make this work properly, or would you always run into setup issues with device nodes at this point? Specifically I'm concerned about what this means for tests and if they should be able to use unprivileged containers themselves to test things. I guess we made the decision that we just assume "root" for testing. But right now you could - presumably - also setup more things under that assumption that would not work in an unprivileged setup. Is that a problem? Relatedly it'd be great if we actually had a VM in-between us and the build. But that only works well on some architectures, only composes well on even less (e.g. arm64 not having nested virtualization yet), and only provides a marginal benefit if you execute the build outside of the VM as well. But it'd shield us more from supply chain issues. Kind regards Philipp Kern
Re: Bug#1076153: ITP: dh-rust -- debhelper buildsystem for Rust code
Hi,
On 11.07.24 18:06, Jonas Smedegaard wrote:
* Package name: dh-rust
Version : 0.0.1
Upstream Contact: build-common team
* URL : https://salsa.debian.org/build-common-team/dh-rust
This ("build-common") reminded me of cdbs. Can we not have another
schism and actually work together?
cdbs also got orphaned but its legacy not cleaned up. I still count 1.6k
reverse build-depends in unstable.
I'd - at the very least - would like to see a statement why a fork is
necessary. Innovation can happen in forks. But they don't necessarily
need to be in the archive to make a point.
Kind regards
Philipp Kern
Re: i686 require SSE4.1-capable processor?
[Also adding Phil] On 15.07.24 14:52, Andreas Ronnquist wrote: Packages built for the i386 arch need to conform to the i386 baseline, which is currently i686. If a package contains a newer instruction it's a bug in that package and gcc is not the cause of it, the package is. https://buildd.debian.org/status/fetch.php?pkg=filezilla&arch=i386&ver=3.63.0-1%2Bdeb12u3&stamp=1704758683&raw=0 indeed contains at least one compile command with -msse4.1. [...] Yeah, I have discovered that it is indeed a cause of the d/rules in the filezilla package. I blame having taken over it recently, and still haven't learned the ins and outs of it. It'd also be good to document reasons for such workarounds next time. Both the changelog and the surrounding comments don't really tell you what to watch out for in a new gcc version. There's no bug reference (GCC or Debian bug) or example error message or a pointer to possible miscompilation. Kind regards Philipp Kern
Re: i686 require SSE4.1-capable processor?
Hi, On 2024-07-16 14:14, Andrey Rakhmatullin wrote: On Tue, Jul 16, 2024 at 12:46:01PM +0100, Phil Wyett wrote: > > > Packages built for the i386 arch need to conform to the i386 baseline, > > > which is currently i686. If a package contains a newer instruction it's a > > > bug in that package and gcc is not the cause of it, the package is. > > > https://buildd.debian.org/status/fetch.php?pkg=filezilla&arch=i386&ver=3.63.0-1%2Bdeb12u3&stamp=1704758683&raw=0 > > > indeed contains at least one compile command with -msse4.1. > [...] > > Yeah, I have discovered that it is indeed a cause of the d/rules in the > > filezilla package. I blame having taken over it recently, and still > > haven't learned the ins and outs of it. > It'd also be good to document reasons for such workarounds next time. > Both the changelog and the surrounding comments don't really tell you > what to watch out for in a new gcc version. There's no bug reference > (GCC or Debian bug) or example error message or a pointer to possible > miscompilation. The addition to 'debian/rules' was in response to the below. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053804 That bug report looks like the outcome of the "addition", not the reason for it. Did you mean https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034195 ? Yeah it'd have been good if there had been a link to that. E.g. in the changelog or as a comment in debian/rules. The interactions in both bugs look very weird to me, especially when the same person proposes compiling software with SSE4.1 and then complains that it fails on older hardware, and the reason for closing the newer bug also looks weird to me. I think it should be reopened and bumped to RC. I'm a bit confused as to why Filezilla bundles an ancient version of Putty. The official Putty code does compile *that specific unit*[1] with -msse4.1 but there is also a gate in the code to only use the accelerated path if cpuid signals support for the new instructions. As far as I can see you added the flag to all source files in the putty/ subtree, thus more compilation units will use the new instructions that are not necessarily ready for it (i.e. have extensive checking logic upfront). It's not entirely surprising that the compiler then finds more efficient ways to do operations using the new instructions, which will then fail execution with invalid opcode. I'm with Andrey that the bug should be reopened and RC'ed because this is effectively producing a miscompilation on i386. Kind regards Philipp Kern [1] https://sources.debian.org/src/putty/0.81-2/crypto/CMakeLists.txt/?hl=88#L130 (it checks for the capability and then adds a specific library just for that source file if successful)
Re: Look for keysign
On 7/17/24 2:15 PM, Brian Smith wrote: Good luck with that. Getting my key signed was the most difficult part of becoming a Debian Maintainer. I couldn't find anyone in Central Texas to do so and finally got mine signed at SC18. Key endorsements[1] exist these days. Kind regards Philipp Kern [1] https://lists.debian.org/debian-devel-announce/2020/11/msg3.html
Re: Who is taking care of storm.debian.net?
On 12.08.24 10:57, Carsten Schoenert wrote: Am 12.08.24 um 10:27 schrieb Carsten Schoenert: Hi, the certificate for the domain storm.debian.net has expired yesterday. The site is not listed on https://wiki.debian.org/DebianNetDomains Knows someone who runs this service so the certificate could get renewed? O.k., I was unable to find the dedicated wiki page for this service. :-( https://wiki.debian.org/Services/storm.debian.net I contacted Laura and Kyle. For the next person who has access to master (i.e. is a DD): master$ ldapsearch -x '(dnsZoneEntry=storm*)' That will give you the account name of the domain "owner". What I'd suggest is a CNAME for _acme-challenge.storm instead of putting TXT records into Debian LDAP. Kind regards Philipp Kern OpenPGP_0x50C3634D3A291CF9.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Why does Salsa use reCAPTCHA?
Hi, On 14.09.24 15:07, Preuße, Hilmar wrote: Currently an example page [1] reports Error: https://salsa.debian.org/api/v4/projects/hilmar%2Fwp2latex API request failed: 401 Unauthorized at /srv/qa.debian.org/data/vcswatch/ vcswatch line 408. But the "Debian changelog in Git:" below is recent, although the phenomenon now exists for 1-2 weeks. So, it seems there is no issue except the bogus error message. Hilmar [1] https://qa.debian.org/cgi-bin/vcswatch?package=wp2latex That's a qa code problem. I fixed it. (Although I need to still figure out how to commit the change.) Kind regards Philipp Kern
Re: Bits from the DAMs ( & Co)
On 1 Apr 2005, at 08:31, Joerg Jaspert wrote: - a NM must pay both DAMs a sum of money, randomly choosen at the time he applies. This ensures that we always have enough money to process the request of NMs, you know it needs time to create accounts! I still think it's just to finance you your meals. It sounds like this one guy from Freenode who wanted some funds for him watching IRC full-time. :D Be prepared for a 1GB Debian Mirror in the future, carrying all useful stuff you need to have. Define useful... but at least I could then keep a complete one at home. I feel the l33tness already... As we considered the climate on the lists to be BAD, we just decided to randomly shut them down. Whenever we[2] don't like a thread this list will be dropped for at least a week. We are sure that this will help us to get to a much friendlier atmosphere, as random people already announced that need a while ago. Right, no more ftp-master bashing. Strong ACK. What for? With the end of this day we will remove sarge and woody. We all run sid anyways, so why bother keeping something always outdated? Its so much simpler to just work on sid. Believe us, we are the Cabal, we know that. Did you file such a bug against ftp.debian.org already? I didn't see one. Or do you want to work without having a BTS? I mean it's easy to change all the policies if only the cabal members have voting rights! Yes, some ice cream for you. You fool, do not talk about something to eat in a *serious* e-mail these days. Kind regards, Philipp Kern Debian Developer PGP.sig Description: This is a digitally signed message part
Bug#303810: ITP: mpdscribble -- Music Player Daemon interface to Audioscrobbler
Package: wnpp Severity: wishlist Owner: Philipp Kern <[EMAIL PROTECTED]> * Package name: mpdscribble Version : 0.2.4 Upstream Author : Kuno Woudt <[EMAIL PROTECTED]> * URL : http://scribble.frob.nl/ * License : GPL Description : Music Player Daemon interface to Audioscrobbler mpdscribble is a client to the Music Player Daemon (MPD) which submits information about tracks being played to the Audioscrobbler online service. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#303811: ITP: net6 -- Network access framework for IPv4/IPv6
Package: wnpp Severity: wishlist Owner: Philipp Kern <[EMAIL PROTECTED]> * Package name: net6 Version : 1.0.0 (currently 0.9.9.20050408) Upstream Author : Armin Burgmeier <[EMAIL PROTECTED]> * URL : http://darcs.0x539.de/net6 * License : GPL Description : Network access framework for IPv4/IPv6 net6 is a library which eases the development of network-based applications as it provides a TCP/UDP protocol abstraction for C++. It is portable to both Windows and Unix-like platforms. An own website for this project is not yet available. The repository is browsable on <http://darcs.0x539.de/cgi-bin/darcs.cgi/net6>. This library is a direct dependency of libobby, a package which will be submitted as another ITP bugreport within the next few weeks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#304652: ITP: libobby -- Network text editing library
Package: wnpp Severity: wishlist Owner: Philipp Kern <[EMAIL PROTECTED]> * Package name: libobby Version : 0.1.0 (currently 0.0.20050410) Upstream Author : 0x539 dev group <[EMAIL PROTECTED]> * URL : http://darcs.0x539.de/libobby/ * License : GPL Description : Network text editing library libobby is a library which provides synced document buffers. It supports multiple documents in one session. Thus it serves as the basis of a free collaborative editor. It is portable to both Windows and Unix-like platforms. An own website for this project is not yet available. The repository is browsable on <http://darcs.0x539.de/cgi-bin/darcs.cgi/libobby>. This library depends on net6, for which an ITP is filed as #303811, and is a direct dependency of gobby, a package which will be submitted as another ITP bugreport within the next few weeks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#308047: ITP: gobby -- A collaborative editor
Package: wnpp Severity: wishlist Owner: Philipp Kern <[EMAIL PROTECTED]> * Package name: gobby Version : 0.1.0 (currently 0.0+20050506) Upstream Author : 0x539 dev group <[EMAIL PROTECTED]> * URL : http://darcs.0x539.de/gobby/ * License : GPL Description : A collaborative editor Gobby is a free collaborative editor based on libobby, a library which provides synced document buffers. It supports multiple documents in one session and a multi-user chat. It is portable to both Windows and Unix-like platforms. It uses GTK+ 2.6 as its windowing toolkit and thus integrates nicely into the GNOME desktop environment. An own website for this project is not yet available. The repository is browsable on <http://darcs.0x539.de/cgi-bin/darcs.cgi/gobby>. This application depends on net6, for which an ITP is filed as #303811, and libobby, with #304652 as its ITP. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFC: A new video-related section
Dear Debian fellows, when does a group of packages warrant the introduction of a new section? At least I could request some comments without any obligation. I know of some users which were distracted by our "graphics" section, as they searched for multimedia or more precisely movie players and found it in this section among other programs like image editors, viewers and converters, actually there are also themes in it. I do not know if there were previous discussions on this topic, but the new section I propose would seperate media players from image processing tools. Plugins for those players which are currently put into "libs" should also be put into this new section. So it would probably be more "multimedia" than "video". Any thoughts on this? Kind regards, Philipp Kern Debian Developer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: A new video-related section
Gergely Nagy wrote: Then media players are just fine in graphics or sound, depending on which is their main focus (or they could even be in gnome or kde, or whatever). Please see it from a user's point of view. If one wants a media player why should (s)he look in "gnome" or "kde"? And I personally would not expect it in graphics either. In fact some players are currently in the section of their corresponding desktop environment. But following your statement all media players should go into "sound", as they play sound files and movies (which also have a sound track in them). Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: A new video-related section
Benjamin Mesing wrote: Exactly. The debtags system is quite mature now - what it still lacks is a complete set of data. If you want to help completing the data, you should consider downloading debtags-edit. Also have a look at http://debtags.alioth.debian.org/ for more details. Is it already used in any package management tools? Or is the debedit GUI currently the only program using the preliminary database? By the way debedit spew some debugging output at me and seems also a bit laggy. Is it still beta? (: Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Linda warnings
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eric Dorland wrote: > Yes, they are necessary tools for developers. But nearly ever project > I've ever seen ships the files generated from the auto* tools. However I feel the use of a build-dependency is a legitimate one if the package is built directly from the upstream's tagged SCM sources and thus contains no Autotools output. Kind regards, Philipp Kern -BEGIN PGP SIGNATURE- Comment: Fingerprint: 1710 7DB1 9A28 42FF B699 7654 ED1A 3933 B2CF CDD8 Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iEYEARECAAYFAkKbcuIACgkQ7Ro5M7LPzdhBVwCePCCQ6BnkbAElemgSvROyEGdt 1JMAoIRxeJQG4wr8viOWVSIYZ0Wj+NOC =L7iY -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Libraries with ABI changes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear list readers, I got some questions to library packaging. If the ABI of a library breaks, the SONAME of it gets updated and thus the binary package's name. As soon as the new revision gets uploaded the old binary package should get NBS (Not Built From Source) status assigned by rene and the ftp-masters would notice it after NEW processing. But would such a package kept so long in the archive until all packages which depend on the old library have been rebuilt? And will the removal of the old version then happen semi-automatically (as in listed in the normal rene output)? Kind regards, Philipp Kern -BEGIN PGP SIGNATURE- Comment: Fingerprint: 1710 7DB1 9A28 42FF B699 7654 ED1A 3933 B2CF CDD8 Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iEYEARECAAYFAkKbdPsACgkQ7Ro5M7LPzdi3jACfbdVS7AxQ6q6tBey7o74PGYm4 ZVgAoKxwcGNlF95vtrIipnjdEQzQZWs4 =PXWx -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Libraries with ABI changes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wouter Verhelst wrote: > Uh, no. The old binary package should either be removed completely from > the archive (in which case all packages that depend on it are instantly > uninstallable), or be moved to a separate source package in section > oldlibs. So on a new ABI-incompatible version the library maintainer should contact the maintainers of all dependendent packages and arrange a new upload as soon as the new version gets cleared from the NEW queue? The timespan until the other uploads are installed into the archives is only a problem if the melanie run by the ftp-masters happens in between, correct? Kind regards, Philipp Kern -BEGIN PGP SIGNATURE- Comment: Fingerprint: 1710 7DB1 9A28 42FF B699 7654 ED1A 3933 B2CF CDD8 Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iEYEARECAAYFAkKbiJIACgkQ7Ro5M7LPzdjgAwCfcf+uGo3XBA45S4qXM5ENRN9L vS8AoOq5AdEiT9vb7SNMgeumrWy4D7Fg =zoUP -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Linda warnings
Eric Dorland wrote: > Why? Just run auto* on the unpacked tarball and ship them in the > .diff.gz? What makes it more legitimate in that case? That the > upstream developers didn't run the autotools? They would have, if it > were a proper release. Well, I did not talk about regular snapshots, but about direct exports. Some tools in Debian (like "darcs-buildpackage", thank you John for this) make it possible to make such SCM builds. However the Autotools output is not versioned, so not included in the tarball. Could you please state why it is discouraged? I could not find it in the thread. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: A new video-related section
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp Kern wrote: > I do not know if there were previous discussions on this topic, but the > new section I propose would seperate media players from image processing > tools. Plugins for those players which are currently put into "libs" > should also be put into this new section. So it would probably be more > "multimedia" than "video". Any thoughts on this? So to sum it up: As any change related to a new "multimedia" section instead of the current "graphics" and "sound" sections would only be a half-hearted one, debtags is possibly getting implemented into Etch together with support in user tools like Aptitude and Synaptic? (Apart from the database issue with an incomplete dataset.) Kind regards, Philipp Kern -BEGIN PGP SIGNATURE- Comment: Fingerprint: 1710 7DB1 9A28 42FF B699 7654 ED1A 3933 B2CF CDD8 Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iEYEARECAAYFAkKd46sACgkQ7Ro5M7LPzdj8MwCfasGJbcD/8rf62GZI/PczISN3 zwUAn2X5hpjtU0o6HxSQiXTqcf0VIz9O =rY0m -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Reportbug and RFS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Moreno Garza wrote: > Now spread the word between maintainers of prospective packages to use > the RFS reportbug template once it is ready. :) Perhaps it should just be announced to debian-mentors and put into all those FAQs related to it (apart from the fact that many still do not read these...). Kind regards, Philipp Kern -BEGIN PGP SIGNATURE- Comment: Fingerprint: 1710 7DB1 9A28 42FF B699 7654 ED1A 3933 B2CF CDD8 Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iEYEARECAAYFAkK7HvwACgkQ7Ro5M7LPzdg8IACg5/0lMyMs93uQW1kqzBMGzC73 25MAnRJb842Wg/8exxQ/vjqr2o3e1uu6 =ok1R -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mass bug filing for libjack dependant packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Jordens wrote: > I uploaded a new release of jack-audio-connection-kit to unstable. The > following source packages have been built against libjack0.80.0-dev and > must now be rebuilt against libjack0.100.0-dev due to incompatible API > changes. I plan to file important bugs and then upgrade them to > something RC after a few weeks. Is that OK? While you probably mean ABI changes instead of incompatible API changes, I would recommend that you first mail all maintainers by using the [EMAIL PROTECTED] aliases before you mass file any bugs. You could do this after some weeks, with those packages where nothing happened. Kind regards, Philipp Kern -BEGIN PGP SIGNATURE- Comment: Fingerprint: 1710 7DB1 9A28 42FF B699 7654 ED1A 3933 B2CF CDD8 Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iEYEARECAAYFAkLANrQACgkQ7Ro5M7LPzdigtQCdFBUwA2OewEnyUP1EhpCTbJIF 7TQAn1/ZEX2JwmQ15esEV0ahQRmKXpDi =fX+n -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Referring http://debblue.debian.net
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bartosz Fenski aka fEnIo wrote: > It can be changed via mail2ldap gateway. More information at > http://db.debian.org/doc-mail.html Are zonefile entries "owned" by those who once set it up? They are at least saved in their LDAP records, so probably others cannot modify it? Kind regards, Philipp Kern -BEGIN PGP SIGNATURE- Comment: Fingerprint: 1710 7DB1 9A28 42FF B699 7654 ED1A 3933 B2CF CDD8 Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iEYEARECAAYFAkLAN+YACgkQ7Ro5M7LPzdgprQCdGAhprcieeOJ6p/akOf5kzR1U dDUAoIcAXComxyQqKwQjSUBfO2XbmlUM =Bw0W -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shared library -dev package naming proposal
On Thu, 2005-07-14 at 20:16 +0900, Junichi Uekawa wrote: > I'd like to propose, for new -dev packages, to > name -dev packages after their runtime library counterparts. I personally found it very handy that the dev packages automatically selects the most recent API compatible version. Why do you want this switch by the way? You did not name reasons as far as I could see. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: API/ABI in -dev package name?
On Fri, 2005-07-15 at 22:33 +0900, Junichi Uekawa wrote: > Currently people just package libwhatever-dev and break API whenever they > please. That's an upstream issue more or less. With libtoolised packages -release has to be used if the API breaks in a non backwards-compatible way. This would also be encoded in the dev-package's name. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: API/ABI in -dev package name?
On Fri, 2005-07-15 at 09:14 -0700, Steve Langasek wrote: > Not consistently. Indeed, I've never heard of such a practice; can you give > an example? Well in fact I saw quite some projects doing it that way and found it to be the cleanest. gtk(mm) and glib(mm) come to my mind if I recall it correctly. They change -release as soon as the API breaks. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Gradual mass bug filing for C++ transition / gcc-4.0 issues
On Fri, 2005-07-15 at 11:00 -0700, Daniel Schepler wrote: > I might also do NMU's for some of the more important packages, with a > delay of 2 days, or 5 days minus the time since the last dependent > package transitioned, whichever is longer. Right now I have my eyes > on jade/opensp/openjade, and possibly db*. I am currently working on getting Bradley Bell's C++ packages transitioned. These include[1] the following: gconfmm*, glademm*, glibmm*, gnome-vfsmm*, gnomemm*, gtkmm* and several other *mm* libs. On some I am waiting for the dependencies. But please contact Bradley and me if you intend to NMU any of these. Kind regards, Philipp Kern Debian Developer [1] The complete list: http://qa.debian.org/developer.php?login=btb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: snownews maintainership
On Mon, 2005-07-18 at 13:01 +0200, Nico Golde wrote: > I read it and thats why I asked before I have done > something. There is nothing in the MIA database about him and Echelon says that his last message is dated Wed, 06 Jun 2005. Probably he is just suffering from temporary mail failures. Kind regards, Philipp Kern signature.asc Description: This is a digitally signed message part
Re: debian mentors & ubuntu
On Tue, 2005-07-19 at 23:06 +1000, Hamish Moffatt wrote: > Unrelated question: why was mentors.debian.net delegated (historically) > to non-DDs? Because a DD delegated it to them. Kind regards, Philipp Kern signature.asc Description: This is a digitally signed message part
Re: debian mentors & ubuntu
On Tue, 2005-07-19 at 09:07 -0400, David Nusinow wrote: > It's rather pathetic that the Debian mentors site doesn't run the operating > system that's the reason for its existence. Well, at least it's Debian-derived? Just one leaf lower in the tree. I don't see or have any problem with mentors.debian.net running Ubuntu, but I still don't get why the button is displayed on the front page. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GPG Key sign
On Wed, 2005-07-20 at 14:42 -0700, mina fahmy wrote: > Are there any Debian developers in the Egypt, area? Those two are returned when querying db.debian.org for people in Egypt: * Ayman Negm ([EMAIL PROTECTED]) * Muhammad Hussain Yusuf ([EMAIL PROTECTED]) You have to contact them directly to receive more precise information about their location and to negotiate a key signing. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The BTS and bug subscriptions
On Sat, 2005-07-23 at 00:33 +1200, Nigel Jones wrote: > now, how about [EMAIL PROTECTED] because I have a > feeling that co-maintainers/uploaders get bug reports for a project. Use the package tracking system[1] for this. Kind regards, Philipp Kern [1] http://packages.qa.debian.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Testing requirements stalled
On Mon, 2005-07-25 at 18:20 -0700, Shaun Jackman wrote: > It's been saying that "ncurses is only 3 days old" for the past four > days. Any idea what's up? Well, ftp-master is down, so the testing scripts (aka britney) do not run. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: "at" package unmaintained??
[Truncated unnecessary crosspost] On Tue, 2005-07-26 at 15:56 +0200, Mathis Dirksen-Thedens wrote: > Ryan Murray did not answer my email which I sent some months ago, so I propose > someone helps him with his work and takes over the "at" package. Most of the > bugs are very old, and usernames longer than 8 chars are STILL NOT WORKING, > though http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=101919 says they > would. > I tested it and it did NOT work. I suffered from the same problem with the `at' package. Ryan, could you consider orphaning it if you lack time for its maintenance? Thus one or more could adopt it and fix the long list of outstanding bugs without the need to do NMUs. > This is getting on my nerves, because I have to reinstall my patched "at" > package every time "apt-get upgrade" overwrites it with the old one. > Could please anybody take over and fix the mess? What about setting your package to `hold' or using an epoch? Kind regards, Philipp Kern Debian Developer signature.asc Description: This is a digitally signed message part
Re: Problemes with the debian archives or apt?
On Thu, 2005-07-28 at 22:34 +0200, Olaf van der Spek wrote: > I think it'd be nice to have some status (HTML) page that lists all > current issues. Perhaps on the wiki[1] so that it *can* actually be updated by most who want to inform about issues? Kind regards, Philipp Kern [1] http://wiki.debian.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ignoring upstream's version number?
On Sun, 2005-07-31 at 21:21 +0200, Harald Dunkel wrote: > And how is this going to be fixed? The broken version > number might be much higher than upstream's version > number. AFAIK there is no way to turn it back, is it? The maintainer could use an epoch to fix it. (It's like a 1: prefix.) > 2.5.130.CVS.2005.07.19.01-1 > 2.5.13-0.CVS.2005.07.19.01-1 Is it really important to have the 0 split away? I think while dashes are perfectly valid when there is a Debian revision they are not really loved by the maintainers. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: fresh blood gets congested: long way to become DD
On Mon, 2005-08-01 at 15:23 +0200, Andreas Barth wrote: > On the very day I got my account, Frontdesk asked me in IRC whether I > want to become AM. That speaks against that theory. :) Apart from that it's not just a theory. ;) Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: allow new upstream into stable when it's the only way tofix security issues.
On Tue, 2005-08-02 at 17:19 -0400, Joe Smith wrote: > I think the no new upstream versions is stable rule needs to be more > flexible anyway. I have seen times where EVERY SINGLE change except for the > version number have been backported. That is often the case where the new > release consists of nothing but the desired changes. In those cases it is > illogical not to just go with the new versions. But that's only possible when there were no releases in between. And those are probably rare cases anyway. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Asking Debconf questions about database data
Dear Debian fellows, what's the common practise if a package gets purged and depends on user-supplied data in a database? In this case these are DNS zones (it's about `mydns-mysql'). Currently there is a Debconf question in postrm, which is definitely wrong because I cannot rely on Debconf being installed at purge time. So I wanted to move it to prerm, but then I don't know if the package is really purged. Should one ask such a question at all? And if so, upon installation? I personally feel that it should be presented on removal if at all possible because then the user really knows what he wants to do. The policy itself is about removing all configuration files on purge, but does this include user data like supplied DNS records? I noticed that BIND won't delete /etc/bind, if this is considered as a ``default'' location for zone files anyway. It uses rmdir which would refuse to delete a directory which still contains files. The opinions on what you need to delete on purge seem to be quite different, so I would like to try to reach a consensus about this. Kind regards, Philipp Kern signature.asc Description: This is a digitally signed message part
Re: status of jackd? (bug #318098)
On Tue, 2005-08-09 at 15:18 -0700, Erik Steffl wrote: > all in all, if you offer a distro that is several years old it's not > suitable for _general_ desktop use (I'm sure it would be OK for _some_ > dektop users), regardless of how much you dislike people running unstable. Then stick with testing. Just my few cents, Philipp Kern -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#322762: /usr/doc still exists (transition tracking bug)
On Fri, 2005-08-12 at 13:53 -0400, Joey Hess wrote: > Set any bugs about /usr/doc stuff to being blockers of this bug report. > Use this as a tracking/coordination bug for the remainder of the transition. Since when do we have this feature in the BTS? Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ia32-libs{-tools}, multiarch, squeeze
On 2009-07-05, Stefano Zacchiroli wrote: > 3) How to maintain the chroot. With the chroots that I use (I've 4 of >them: three for cowbuilding in different suites, and a 32 bit one) >they always end up being out of date. I developed the habit of >updating them just before building on top of them. For users we >really need a way to update them in a semi-automated way that takes >care of security upgrades (at least). Maybe unattended-upgrades >with a specific configuration can be the way to go? OTOH the main system is not automatically upgraded neither. Maybe a post- upgrade hook or similar would be appropriate in this case? How could one help to get multiarch happen by the way? Or does it currently depend on Guillem coding up the foundation in dpkg anyway? Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: binNMUs for arch:all packages too
On 2009-07-06, Kari Pahula wrote: >> > What's needed to get this working? >> I don't think it should be made to work. > So you think that sourceful uploads for Haskell libraries is the > expected thing to do? We're talking about tens of packages. You can do no-change sourceful uploads, yes. And indeed I think we should have some means to do them automatically like we do binNMUs. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: mail server broken: are debian reject messages logged ?
On 2009-07-16, Joerg Jaspert wrote: >>> Yes, you can find them on merkel:/srv/ftp.debian.org/queue/reject/*.reason >> there are not many files there. Is there a place where the rejection mails to >> ‘NEW’ uploads are archived? Otherwise, how about sending them to the >> package's >> ITP bug when available? > There is no reliable way to detect that a bug# is for an ITP. grep 'Subject: ITP:' /org/bugs.debian.org/spool/db-h/NN/NN.summary. If you want, you could also match up the source package name. Now you'll say that's not reliable. Maybe not, but a pretty strong indication and very few misdirected mails won't hurt anybody if he chose a not so useful bug title. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Should we improve our (internal) communication?
Hi, On 2009-07-16, Sandro Tosi wrote: > today ries (aka ftp-master) was down due to a scheduled maintenance activity. more or less scheduled, as already stated. > Now, scheduled means programmed, and suddenly this question comes to > me: should the project be notified of such core activities? should we > only relay on #debian-devel irc channel topic to know this? Interestingly that is even mirrored to a public location[1], especially as downtimes at short notice have in the past been put there. While I agree that they could have mailed d-i-a I, for myself, don't deem that necessary for such a short outage. DSA regularly update ries with new kernels and notice ries interactive users sufficiently ahead, so I have nothing to complain in this regard. (It's mostly on IRC, true, but for the current userbase that seems to be sufficient because we're there when/while working.) > ries is not a barely used machine, it's the one of our fundamental > servers, and it went down without notification (to my knowledge, or at > least to a wide audience). I tend to differ. Of course it's heavly used interactively by both FTP and release team, but well, leaning back for half an hour also does some good, right? There are (to my knowledge) three services served from that machine that the public could access: 1) incoming, 2) the upload queue, 3) release stuff like britney output. The upload queue was pointed somewhere else, incoming might be critical for buildds but in general they cope if it isn't reachable and the latter is partially put onto packages.qa.d.o. > Other times, when I asked on irc why a given machine when down I often > have received a reply that sounded like "WTF you want? go and do > something else and don't bother us", not really encouraging, but I > moved along. I suppose you did get an indication why it was down, right? Maintenance activity. So nothing is wrong per se, which is a good sign. People are taking care of it. > Should we improve how we communicate in the project? Shouldn't there > be more information on what's moving "behind the scenes"? It's just me > that would like to know it? I find weasel's reports on what DSA did very interesting in the past. Granted, they were internal notes put out into the public, but it gives you some impression of "behind the scenes". Just my thoughts, Philipp Kern [1] http://wiki.debian.org/TopicDebianDevel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: The wider implications of debhelper/dbus breakage
On 2009-07-17, Wouter Verhelst wrote: >> AFAIK the FTP Team is working on a system to prevent uploads which >> have lintian errors. The whole category of lintian errors has >> already been assessed and possible overrides are planned to arrive >> in the NEW queue at least once... Please do note that I'm talking >> about errors, not about warnings. > Right. However, having sbuild run lintian would allow a buildd > maintainer to assess issues with packages by looking at *warnings*, > rather than 'just' errors. This isn't something an automated system can > do. While that's true (and would require having an up-to-date lintian on the buildd which does not emit false warnings for packages built in the testing/stable/oldstable queues), some people are working to get autosigning happen. This might drop review except for special cases. Of course we could put lintian into that set, though. And that might actually be a good compromise. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: The wider implications of debhelper/dbus breakage
On 2009-07-18, Wouter Verhelst wrote: > Ah, so this is about not interfering with testing migration, I guess? It's not only testing migration. As an example: If you have a large chain of binNMUs which all need some dep-wait on a package upper in the chain you get the effect that the whole thing takes several days just because each step of the chain first blocks on signing and uploading once a day to do the next one. Even if the once a day doesn't hold it still affects slow architectures. I see it like Luk that we want porters to care about logs of build failures. I don't see why anyone should get bothered by the huge bunch of successful logs. Of course it can be scripted, but then, why are we even putting the human in between of this. If it's just about some simple regexp to highlight them we can also weed out known patterns on the buildd and pass them on for manual review. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: The wider implications of stuffing the NEW queue with issues it was not designed for.
On 2009-07-19, Charles Plessy wrote: > Do we have evidence that maintainers have damaged the project in the past by > willingfully upload packages with overriden lintian errors? Damaged the project... no. Caused a RC bug to be overlooked... yes. I recently encountered a package where the library's binary package was not named after the SONAME. This caused a lintian error which was... overridden. And it broke horribly when the SONAME change went unnoticed because... well... the binary was never named after the SONAME and thus the check wasn't active anymore. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: The wider implications of debhelper/dbus breakage
On 2009-07-20, Stéphane Glondu wrote: > For example, each OCaml transition involve rebuilding a lot of packages > (about 139), with 6 levels of dependencies. So if some build takes 2 > days or more (for the current transition, on some builds, it was even > more than a week) to be uploaded, it means that transition will last at > least 12 days (for the current transition, all packages were > rebuilt/uploaded/installed after 21 days). But most of the builds are > successful (and fast). If packages were automatically uploaded on > success, a dependency level would be cleared at each dinstall run, > meaning the whole recompilation would take less than 2 days. Haskell is even more intense. But it's not exactly true because we are autobuilding from accepted, so you do not need to wait for dinstall runs to complete but can get it done much quicker. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: The wider implications of debhelper/dbus breakage
On 2009-07-21, Goswin von Brederlow wrote: > Philipp Kern writes: > >> On 2009-07-20, Stéphane Glondu wrote: >>> For example, each OCaml transition involve rebuilding a lot of packages >>> (about 139), with 6 levels of dependencies. So if some build takes 2 >>> days or more (for the current transition, on some builds, it was even >>> more than a week) to be uploaded, it means that transition will last at >>> least 12 days (for the current transition, all packages were >>> rebuilt/uploaded/installed after 21 days). But most of the builds are >>> successful (and fast). If packages were automatically uploaded on >>> success, a dependency level would be cleared at each dinstall run, >>> meaning the whole recompilation would take less than 2 days. >> >> Haskell is even more intense. But it's not exactly true because we are >> autobuilding from accepted, so you do not need to wait for dinstall runs >> to complete but can get it done much quicker. >> >> Kind regards, >> Philipp Kern > > The long wait is the signing, not the dinstall run. Even without > accepted dinstall runs 4 times a day now. > > But I have to say I'm totaly against unsigned uploads. The buildds are > insecure enough as it is. > > MfG > Goswin > > -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Intend to create an -fPIC library package...
On 2009-07-21, Christian Hammers wrote: > First, thanks for the long answer, Wouter! > > To wrap it up: > * static libraries are a PITA in case of security problems > * static libraries are a PITA for other projects as they have no versions > * shared libraries with self chosen soname or --release= versions are even > PITA as I, as a maintainer, surely won't watch for ABI breakages Well, actually... I would expect that from a maintainer of a... shared library. dpkg-gensymbols helps with that, though. > * MySQL is a ... :) We already have a real database server in Debian. :-P Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: The wider implications of stuffing the NEW queue with issues it was not designed for.
On 2009-07-23, Steve Langasek wrote: > On Sun, Jul 19, 2009 at 07:12:57AM +0000, Philipp Kern wrote: >> On 2009-07-19, Charles Plessy wrote: >> > Do we have evidence that maintainers have damaged the project in the past >> > by >> > willingfully upload packages with overriden lintian errors? >> Damaged the project... no. Caused a RC bug to be overlooked... yes. >> I recently encountered a package where the library's binary package >> was not named after the SONAME. This caused a lintian error which was... >> overridden. And it broke horribly when the SONAME change went unnoticed >> because... well... the binary was never named after the SONAME and thus >> the check wasn't active anymore. > Lintian's error on soname mismatches references both the binary package > name, and what lintian thinks the package name should be based on the actual > soname. AFAIK you can only override lintian errors by spelling them out > fully, so surely the lintian error should have reappeared in this case as > soon as the soname changed? That would have prevented this indeed. But it looks that it did not work that way because the only override present was this one: libbotan1.8: package-name-doesnt-match-sonames This obviously didn't need changing. According to [0] there was also no other Lintian warning. Kind regards, Philipp Kern [0] http://lintian.debian.org/maintainer/dan...@debian.org.html#botan-devel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash without dash essential
On 2009-07-23, Manoj Srivastava wrote: >> As long as /bin/sh refuses extensions to posix I agree with you, but >> bashism has been a cuss word for years before 2004. > Source? Policy does not even ban bashims for maintainer scripts. Surely not, it just tells you to use bash in the shebang. """ You may wish to restrict your script to SUSv3 features plus the above set when possible so that it may use /bin/sh as its interpreter. If your script works with dash (originally called ash), it probably complies with the above requirements, but if you are in doubt, use /bin/bash. """ Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash without dash essential
On 2009-07-23, Frans Pop wrote: > In addition all shells supported as defaults would need to be included on > CD images. And the selected shell would of course have to be set as the > default for new users. Strike the "of course". If I want my users to have zsh as a default that's different from the question where I want to point my /bin/sh to. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash without dash essential
On 2009-07-25, Goswin von Brederlow wrote: > The existing dash package uses dpkg-divert, which is unsuitable on a > larger scale (larger than the one dash package). And to have bash > removable dash has to force itself as /bin/sh. So there goes even that > little choice. > > What alternative do you speak off where the user will have a choice of > what is /bin/sh? I don't see us supporting anything else than dash and bash for /bin/sh for squeeze. So the current solution is acceptable. You can try to prove me wrong, of course. But someone would need to collect the falling out pieces when /bin/sh is switched to something they want to see supported (and commit to that). zsh is certainly not suitable for /bin/sh, sorry. Kind regards, Philipp Kern PS: I do use zsh as user shell, though and would like to thank for his work on that. ;-) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: dash pulled on stable when APT::Default-Release is used
On 2009-07-29, Michael S. Gilbert wrote: > it is a bug in the sense that stable's behavior is being unduly > influenced by unstable's "essential packages" list. i would suggest > submitting a report to the bts so the problem can be tracked and > eliminated in future releases. That's somewhat by definition, sorry. If you have unstable packages activated they may be relying on essential packages from unstable to work. So they have to be installed. No bug there. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#535833: marked as done (general: Slow internet on iceweasel, epiphany and so on...)
On 2009-08-02, Tollef Fog Heen wrote: >| Not only do you have the local loopback, you also have link-local >| addresses which you can legitimately use. Does zeroconf support >| these? Fundamentally breaking IPv6 for these use cases to work around >| broken routing hardware is IMO a step too far. > Does anybody use IPv6-only link-local? I occassionally did and I think Gobby even supports that now in conjunction with Zeroconf. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Debian GNU/Linux 6.0 "Squeeze" release goals
On 2009-08-02, Julien BLACHE wrote: >> There will be a Build-Arch field or some other way to make sure the >> arch:all packages can be built reliably. > How will this work wrt non-Linux ports? > > If you declare Build-Arch: i386, and that means the package should be > built only from Linux/i386, that makes the kfreebsd (and hurd) port > dependent on the Linux port. We could make that list multiple architectures so that any of those would satisfy the buildable criteria for the arch:all. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Status of new source formats project
On 2009-08-02, Vincent Danjean wrote: > Unpacking a source package is not needed during an upgrade. However, it > occurs before > a build. > > So, I understand the question of Charles as "do we want that stable dpkg be > able to > unpack all packages from testing ?". I have no strong opinion for this. Our infrastructure relies on this. So yes. Both dak and sbuild do this. (At least the latter used to do it in older versions, I didn't check the new one.) Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bits from the release team and request for discussion
Hi Anthony, On 2009-08-03, Anthony Towns wrote: > So arm's dropped off that page, kfreebsd-* have been bumped to "TBD", > and alpha, hppa are still accompanied by ia64, powerpc, mips and s390 as > being "at risk". There's lots of fields with just a "?" -- apparently > there's no info on whether the RMs have concerns about everything but > amd64, m68k, s390 and sparc... Anyway, some suggestions: I'm grateful for those suggestions, Anthony. That page is just a pain to maintain though. Not everything on it is up-to-date yet but I updated quite some chunks. > m68k isn't "available" anymore, afaics -- it's not in unstable; > doesn't seem any point having it in the list afaics Yep, I thought the same but didn't dare to drop it. I agree. > amd64 has d-i support, surely? it did for lenny, despite lenny's > page... I marked it as green now, together with upstream support. > querying port maintainers for amd64 and i386 seems like a waste of > time. is there really any concern that no one will be > around to support them? I guess there is no real concern there as glibc/gcc maintainers are mainly working on that architectures. So porter requirements can be waived, IMHO. However there should be port maintainers for the others and I see some lacking in that regard. (One gets hit by a bus and the port dies or similar.) > the -concerns should probably have two possible states: "no", > or "yes" with one or more links to mailing list threads > stating those concerns ACK. > having the "Porting machine" answer be "yes" with a link to > the appropriate http://db.debian.org/machines.cgi?host=foo > page would be as informative and help make the table > take up less space True. I'm even not sure if everything's up-to-date there, yet. Aliases would be great like machine=$arch-porterbox. > using blue to distinguish waived requirements might be helpful, > with something like Users: "45 (w)" to save space. Having > (w) link to a list post explaining the waiver would > probably be helpful for people who'd like to understand > why armel gets a waiver for multiple buildds but hppa > doesn't, eg. hppa has currently 4 buildds because at least one is very crashy. But maybe we should decommission that twin then. I fully agree on the waiver thing, it also helps when revisiting the decisions. > both s390 and alpha seem to be keeping up with the build > up-to-dateness requirements, based on the buildd.d.o > graphs. probably worth linking the row headings for those > percentages to the buildd.d.o graphs, really While that might be currently true for alpha I expect that to drop rapidly as soon as problems pop up because nobody will care. That's probably playing into the number of porters part, but still. > redoing the qualification page every release seems pointless; it's > a wiki page so it's not automatically up to date or > correct, and still needs to be validated by the release > team; and arch maintainers don't seem to particularly be > excited about doing it for exiting architectures... after > initial qualification, why not have the status page be > the canonical summary, linking to list posts for further > information as necessary? There is still the problem that we want porters to commit themselves for a cycle. I don't see how we should find out about them, too, if they do not reply on mailinglists for example. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bits from the release team and request for discussion
Hi Anthony, On 2009-08-04, Anthony Towns wrote: > On Tue, Aug 04, 2009 at 01:09:14PM +0200, Philipp Kern wrote: >> I'm grateful for those suggestions, Anthony. That page is just a pain >> to maintain though. Not everything on it is up-to-date yet but I updated >> quite some chunks. > So make it easy to maintain... Attached is an example converting it to > yaml with python table generation, coping with waivers. wow thanks, that was unexpected. I'll try to get the YAML ready soon and deploy it. > It'd be really nice to have all the buildd criteria be measurable (and then > automated). One idea might be to change "fast security" and "redundancy" into > speed/load measures, something like: > > alpha amd64 armels390 > buildd-speed 95%100% 50%113% > (%ge of i386/amd64) > > buildd-load 55% 60% 95% 20% > > n-buildds 2 3 6 1 > > idle-buildds 0.9 1.2 0.3 0.8 > > where speed is calculated as the overall average of: > > time-to-build-on-$ARCH / time-to-build-on-i386/amd64 > > (ie, dpkg takes 20s to build on alpha, versus 13s to build on i386 after > and amd64+source upload would give 154%) > > load is the percentage of time on average that each buildd is actually > building something, and idle-buildds is "n-buildds * (1 - buildd-load)". > Release criteria are then something like "buildd-speed >= 50%", > "idle-buildds >= 1". This does assume though, that every buildd is doing everything which is not true for all architectures. And the buildd load is currently only calculated and stored on the buildd and not centrally. It could however be collected at some point. (We do not have all logs neither because security ones are not mailed to the log repository but only to security people.) Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Automatic Debug Packages
On 2009-08-10, Manoj Srivastava wrote: >> dpkg "knows" about them the same way it "knows" about debs, AFAICS. > Why, then, the .ddeb suffix? Why are these not just .debs, with > a specific naming schema? At least they shouldn't clash with maintainer-defined ones, IMHO, as they are created differently. The main point is probably that they shouldn't live in the main archive due to space reasons. Of course we could also filter out '*-ddeb*' or '*-dbgsym*' as long as it's not '*-dbg*', which should be dropped at some point but should live in the main archive if present as they're defined in debian/control. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Automatic Debug Packages
On 2009-08-10, Manoj Srivastava wrote: >> Most -dbg packages *shouldn't* live in the archive, but maintainers >> keep adding them by hand anyway, and we don't have anywhere else to >> put them. > Well, right now there is nowhere to put the .ddebs either, and > they are really just .debs with a funny name too. Not very different. I agree that we do not really need the .ddeb extension as we need to avoid clashes in the package namespace anyway, with the extension not helping us with that. >> I'm not sure we would ever want to take packages that are >> referenced in the source debian/control and move them to the separate >> debug archive, I think that would play havoc with database >> consistency. It also gives us no clear way to tag files referenced in >> a .changes file as belonging to the debug archive *except* for the >> package name, and there are certainly -dbg packages that intentionally >> contain things other than detached debugging symbols and which should >> not be grouped with the ddebs. > How is a .ddeb package going to change things by the time it > gets into the archive? .ddebs will be there in the .changes file, and > the only way they are different is in the file name. I'd guess we could also invent another section or priority for it if we want to. (But we didn't rely on such provided data yet, the authoriative data always comes from the override database.) >> The other end is that we need a usable hook for detaching the symbols >> instead of discarding them, which is trivial for all debhelper-using >> packages, and not at all trivial for packages not using debhelper. > > Why is it not trivial? I have such a hook in my pakages, and it > is not rocket science. > > If you think that adding stuff like > --8<---cut here---start->8--- > filelib_or_exec_file > objcopy --only-keep-debug lib_or_exec_file debug_file > objcopy add-gnu-debuglink debug_file lib_or_exec_file > > strip --remove-section=.comment --remove-section=.note \ > --strip-unneeded lib_file > strip --remove-section=.comment --remove-section=.note exec_file > --8<---cut here---end--->8--- > > to a rules file is "not at all trivial", then heaven help us. Plus lines to actually create the package with appropriate control info or/and putting it into debian/control which we wanted to avoid (I think). Of course if we then go and try to modify the behaviour slightly (like having build-ids and stuff) we still have to modify all those packages and not just the helper and a binNMU. But I guess I can't argue with you about that anyway. From a policy PoV you're right, we do not impose debhelper upon everyone. I already consider debhelper coverage as a worthy goal. :-P Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: default character encoding for everything in debian
On 2009-08-10, Norbert Preining wrote: > On Mo, 10 Aug 2009, Roger Leigh wrote: >> Of course there's a penalty for certain operations. But UTF-8 is about >> as compact as an extended encoding is going to get. > Rubbish. You know why in Japan and other Asian countries UTF8 is not > so common? Because many of their glyphs need 4 (four!) bytes, while > for example jis-2022 (AFAIR) is much more compact. > We are not living in an ASCII world anymore. Really because of the size? We are not living in a byte beancounting world anymore. At worst you double the *text* size (we're not talking about images or anything, which are far larger), going from 2 bytes that you need anyway to four. ISO 2022 also wastes one bit per byte to be 7bit safe. If I read the Wikipedia article correctly at least the JP escaping only needs to be put into the document once. (Well, or maybe several times switching back and forth if you're embedding latin-encoded words into the text.) Maybe I'm an ignorant European but I'm not sure that equation still holds. Of course there are certain tradeoffs about latin characters being the privileged few to get a short encoding, but that doesn't make UTF-8 bad per se to call it "rubbish". Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Automatic Debug Packages
On 2009-08-10, Roger Leigh wrote: > That's what I meant (just not sure of the correct dak terminology). > Would this present problems for the ftp-masters, since TTBOMK currently > source and binary packages are restricted to the same area? i.e. would > work on projectb/dak be required to implement such functionality? IMHO you can build single binaries that live e.g. in contrib from a package in main so this should be a non-issue. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Ubuntu's crash reporting with "apport" -> Debian ?
On 2009-08-11, Steffen Moeller wrote: > KDE has improved rather dramatically with its crash reporting UI in its > past few releases, I think. Now Ubuntu comes up with something along > these lines for all kinds of applications: apport > (https://launchpad.net/apport/). > Is anything speaking against someone (me?) repackaging apport for Debian? For that to be useful we need debug symbol creation first. Refer to the corresponding thread currently running on the same mailinglist. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Automatic Debug Packages
["Followup-To:" header set to gmane.linux.debian.devel.general.] On 2009-08-11, Russ Allbery wrote: >> If it's legal to ship debugging symbols for them, I can't see why we >> couldn't support them normally. > The point is that you can't do this with an archive area, at least using > the simple algorithm I proposed above. Well you can. I always thought concrete sections etc. are an implementation detail that has nothing to do with policy, but ok. Volatile uses volatile/main/ (which is a pain yet to be solved by moving to ftp-master), but you could as well do debug//. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Automatic Debug Packages
On 2009-08-13, Manoj Srivastava wrote: >> Ah, and it looks like the automated crash reporting offers to download the >> -dbgsym packages and install them. > Reading the spec, it seems to me that the primary motivation was > for users to provide crash dumps with bug reports, and not much screen > time is given to users debugging their own applications linked to > vendor libraries, or for the developer user in general. I think that > use case should be addressed as well. This use case is IMHO implicitly addressed by making them downloadable and installable on the local system. And I have to agree with Emilio that I don't see the point of a 1:1 relationship of ddeb to binary package just for the sake of library transitions. I wonder if we could just unpack the debugging build-id objects to some other location than globally and point gdb to that in addition to the global debug store. Someone should've pointed a summary of how Ubuntu does it, it seems. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Automatic Debug Packages
On 2009-08-13, Eugene V. Lyubimkin wrote: >> Maybe you should spend some time and read the thread before stating such >> things. > Really? So, they are already first-class deb packages? Maybe you should spend some time and read the thread before stating such things. > What percent of their (and other tools') functionality did you test to say > that? It's already used in production by Ubuntu. With no changes made to them. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bits from the release team and request for discussion
On 2009-08-04, Anthony Towns wrote: > So make it easy to maintain... Attached is an example converting it to > yaml with python table generation, coping with waivers. I deployed that now. Result available on [1], still quite some question marks, though. Kind regards, Philipp Kern [1] http://release.debian.org/squeeze/arch_qualify.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Compilers and GCC-X.Y-SOURCE build-deps
On 2009-08-17, Hector Oron wrote: > I am wanting to build packages (cross compilers) that build depend on > gcc-X.Y-source binary package containing source and other packages (C > library, kernel headers, linker packages). The plan visualization is > available at my home on the emdebian server[1]. > > In the archive I can find a couple of examples, a) gcc-mingw32 and b) > gcj/gnat packages. While a) duplicates gcc source, b) build depend on > the binary package containing the source. The reason gcc-mingw32 > contains the source it is AFAICT that it was rejected by ftp masters. > > So, if I want to build the compilers, so those can be available on the > Debian archive, is it posible to do it the b) way or is there any > restriction against it. We need to do two things: a) declare against what you built in the deb, b) make dak keep those sources to ensure GPL compliance. Doesn't sound like rocket science but someone has to do it. Another potential user would be those extra modules for the kernel where we need to fix up compliance manually at the moment. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Debian Policy 3.8.3.0 released: localized manpages
On 2009-08-18, Andrea Bolognani wrote: > This also means localized manpages will always fail the simple > date check, unless you use the same .TH line in every localized > manpage. Doing so, however, would make it as impossible to know > which manpages are outdated based on the .TH line. And what should we do if a localized manpage is in fact the authoriative one? Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Help needed on mipsel #541706: gpe-expenses_0.1.7-2+b1(mipsel/unstable)
On 2009-08-19, Andreas Moog wrote: > Another way to fix this is to have the scripts use /bin/bash as shell > (as Daniel Leidert suggested, this is a problem with dash as /bin/sh). I guess I need to point out that dash as default will propagate to the buildds when chroots are redone. (Which does not happen all that often, but it's possible that some are switching in the next weeks when they're switched to the "new"[0] version of sbuild.) That's somehow due to the transition strategy so that existing installations are not touched. Kind regards, Philipp Kern [0] Actually an older version of the sbuild in unstable, I tried rebasing against the current version and got stuck with an unusable buildd binary. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Unable to install any .deb pkg
On 2009-08-21, shampavman.cg wrote: > Would like to know if there is a work around? apt-get remove sunwspro sprosslnk Sorry, but we do not support broken third-party software. (The package ships a conflicting file without declaring the conflict to the package manager.) Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Changes to Debian Maintainers handling
On Sun, Aug 30, 2009 at 12:07:01PM +0200, Joerg Jaspert wrote: > Thanks to this change we FTPMasters can now allow Debian Maintainers to > also use our various upload queues[2] for their uploads. You are no > longer bound to ftp-master only. > [2] With the exception of security. DMs continue to be unable to do > security uploads, as that archive has no knowledge of DMUA status of > packages. Of course the same applies to backports (still unofficial) and volatile (official) due to the way they're set up. Kind regards, Philipp Kern -- .''`. Philipp KernDebian Developer : :' : http://philkern.de Stable Release Manager `. `' xmpp:p...@0x539.de Wanna-Build Admin `-finger pkern/k...@db.debian.org signature.asc Description: Digital signature
Re: For the grub maintainers II
On 2009-09-05, Norbert Preining wrote: > Already reported as a bug, but I think that should be discussed here, too. > > Upgrading to grub-pc does not carry over static stanza for Windows, nor > does the os-detecting code find my Windows on sda2. Do you have os-prober installed? Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: udev and /usr
On 2009-09-05, Goswin von Brederlow wrote: >>> Mounting NFS volumes from >>> the initramfs is probably not worth the effort. >> How do you make root on NFS work without this? > By building a kernel with nfsroot support and mounting without > locking and specific nfs version. > > I'm not sure if initramfs also supports it but I would rather doubt it > can build an initramfs with nfs support on its own. See /usr/share/initramfs-tools/scripts/nfs. (If I understood your concerns correctly; I'm doing NFS root with an initrd created by initramfs just fine.) Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Explicitely Cc bug reporters
On 2009-09-12, Michelle Konzack wrote: > And as I have written, I was several times bombed on my cellphone with > messages up to 20 MByte And I was bombed with six from you, where I assume that one would've been sufficient, summarising your points. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Packages that download/install unsecured files
On 2009-09-18, Tom Feiner wrote: > Looks like this method works well for clamav-data and other similar packages > which needs to update databases frequently on stable/oldstable. clamav-data is scheduled for deletion as soon as volatile moves onto ftp-master, so that's no precedent. (I.e. there is opposition against daily builds entering the archive without real developers signing them.) Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: opposition against clamav-data in debian volatile (was: Packages that download/install unsecured files)
On 2009-09-19, Marc Haber wrote: > On Fri, 18 Sep 2009 15:56:07 + (UTC), Philipp Kern > wrote: >>On 2009-09-18, Tom Feiner wrote: >>> Looks like this method works well for clamav-data and other similar packages >>> which needs to update databases frequently on stable/oldstable. >>clamav-data is scheduled for deletion as soon as volatile moves onto >>ftp-master, so that's no precedent. (I.e. there is opposition against >>daily builds entering the archive without real developers signing them.) > Why does the person responsible for these uploads not know about this > opposition? Why was the person doing the significant work not informed > about the fact that every single minute put into the package is wasted > anyway? If I recall the channel discussion correctly you were present and aware of the discontinuation. Maybe I recall it incorretly, though. Please see also: http://lists.debian.org/debian-volatile-announce/2009/msg3.html However progress in the move is currently non-existant. It looked better at some point back then. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: opposition against clamav-data in debian volatile
On 2009-09-21, Hilko Bengen wrote: > I have written and maintained scripts that download signature file > updates for several commercial antivirus scanners and built packages for > them -- which is pretty much the same thing that clamav-getfiles does. > 10 updates to the signature files per day are not uncommon in the > proprietary space and I'd be very surprised if things were any different > for ClamAV. Well, there was also the problem that when asked what problem it tries to solve nobody came up with something sane. If boxes have no internet access freshclam could ask through a proxy, or similar. So I guess the usecase is really that you shut off your machines from the internet, only able to access internal hosts and the packaging mirror to fetch the signatures from? How is that different from just setting up a signature mirror on an internal host? Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: DEB_MAINTAINER_MODE: is it popular and should we document it?
On 2009-09-27, Charles Plessy wrote: > in a discussion on how to force network-dependant regression tests (that must > be disabled in our build network, but whose result I want to see before > uploading), I was suggested by Jonas Smedegaard, who got this idea from Romain > Beauxis, to use a DEB_MAINTAINER_MODE environment variable that is detected in > debian/rules. > > I was just wondering if other people were using something similar and if there > would be ground for standardisation.s Although the goal to enable more tests is laudable the approach of modifying a maintainer build that is later uploaded to the archive from a buildd build doesn't sound right. Maybe the build could then fail in the end through dpkg-buildpackage so that the result cannot be uploaded? Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#550860: ITP: gnaughty -- downloader for adult content
On 2009-10-14, Russ Allbery wrote: >> But also if the _free_ software is for downloading etc. pay-only content >> like music, I do not think that it has to enter contrib, because it does >> not has got a real dependenie on non-free stuff. > Yeah, it's a bit of a marginal case. We have, for instance, Perl modules > to talk to the Amazon APIs in main, although in most of those cases the > API is relatively open and some other sites also implement it. The appearance of Eucalyptus is pretty recent, though. So you'd need to wait until a free service of an API gets released? How feature complete does it need to be? If I release a "compliant" porn directory with only one pic, would that be appropriate? And I could easily make it non-porn too. zsnes used to be in contrib, but somebody made the case that there could be, in fact, free roms, because the way how to program the box is not exactly secret anymore. (If they would be buildable on Debian is another question.) It lives in main now and my gut feeling is that it's the right thing to do, given that the code base is free to modify, share and gives you the usual rights of a free software license (here: GPL2). Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: binNMUs v.s. source-only uploads.
On 2009-10-28, Charles Plessy wrote: > By the way, I just realised that binNMUs directly update the binary packages > in > Testing, shortcutting the 10 day evaluation period. (See > http://packages.debian.org/squeeze/amd64/r-cran-epibasix/download for example, > where r-cran-epibasix was only binNMUed five days ago). This does not only affect binNMUs but all builds. If a build for, say, hppa arrives on day 9, it won't get much testing. Now you can debate the amount of testing on a specialized package on hppa, though it's basically the same case. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: debian/rules "make -f" restriction
On 2009-10-29, Joerg Jaspert wrote: > It is not an overridable error, and I haven't seen any reason yet to > convince me to make it one. You do have some reasons, but none I have > seen that would not be simple to do in make directly as well. > > As long as you have those packages wherever, feel free to do what you > want. Those you (want to) upload into Debian do need to follow policy. Looks like policy is in need of changing here. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Can linux-any arch and friends be used?
On 2009-10-29, Goswin von Brederlow wrote: > We just had a similar issue (Architecture: linux-any) on irc yesterday > and the outcome was that linux-any will only work post squeeze because > the buildd need to grog that syntax too and run stable outside the > build chroot. However the newer sbuild uses the tools within the chroot to fetch and work with the packages. Apart from the fact that Architecture is only read by the build system, no? (But well, quinn-diff is not adapted to understand this, so it wouldn't be scheduled for building at the moment, but the reason of this are not the buildds.) Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: debian/rules "make -f" restriction
On 2009-10-29, Manoj Srivastava wrote: > On Thu, Oct 29 2009, Philipp Kern wrote: >> On 2009-10-29, Joerg Jaspert wrote: >>> It is not an overridable error, and I haven't seen any reason yet to >>> convince me to make it one. You do have some reasons, but none I have >>> seen that would not be simple to do in make directly as well. >>> As long as you have those packages wherever, feel free to do what you >>> want. Those you (want to) upload into Debian do need to follow policy. >> Looks like policy is in need of changing here. > Given that this policy rule i massively followed (all but one > set of packages from a single maintainer), that while there are a lot > of elegant languages and different ways to build packages, and we had > to chose one (I do not want to see ./debian/rules written in, say, > shoop or algo, or the ultimately elegant smalltalk), I see no reason > yet to change well established and uniformly followed policy. I didn't say that, right? Please don't lay words into my mouth. I said "here" to specify the concrete case of policy describing the first n bytes of debian/rules despite the interface being completely in accordance with the normal procedures (i.e. being a Makefile and even make -f compliant). Lintian's executable-not-elf-or-script speaks about scripts in general but I don't see anything at first glance that specifies the first 3 bytes of executables that are not scripts in the policy neither. Regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Can linux-any arch and friends be used?
On 2009-10-29, Goswin von Brederlow wrote: > Philipp Kern writes: >> On 2009-10-29, Goswin von Brederlow wrote: >>> We just had a similar issue (Architecture: linux-any) on irc yesterday >>> and the outcome was that linux-any will only work post squeeze because >>> the buildd need to grog that syntax too and run stable outside the >>> build chroot. >> However the newer sbuild uses the tools within the chroot to fetch and work >> with the packages. Apart from the fact that Architecture is only read by >> the build system, no? (But well, quinn-diff is not adapted to understand >> this, so it wouldn't be scheduled for building at the moment, but the >> reason of this are not the buildds.) > buildd as in wanna-build, quinn-diff, buildd, sbuild and whatever else > in involved as a whole. > > Build-Depends are checked for auto dep-wait-ing packages so the > problem arises there too, just in revers. One won't build while the > other won't dep-wait. Apart from the fact that the dep-wait count went back quite a bit thanks to BD-Uninstallable, IIRC it should just work because the result of a linux-any in the .dsc Architectures will result in a arch:any Dep and thus be listed as such in the Packages file where the dep-waiting acts upon. It looks to me that only quinn-diff will need a bit of poking. (Of course you never know in the current mess, but still.) Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Cross compiler ITP (armel)
On 2009-11-02, Hector Oron wrote: > 2009/11/2 Mike Hommey : >> On Mon, Nov 02, 2009 at 12:25:16PM +0100, Bernd Zeimetz wrote: >>> So if that is a problem - why not enhance the gcc packaging to build the >>> cross-compiler packages? >> Combinatorial explosion ? > We took this approach, and we have been building this way. > Binutils, GCC, GDB, EGLIBC have cross built in capability, but some > tricks (relaying on dpkg-cross) must be done in order to build the > cross toolchain and Debian autobuilders do not know how to keep with > this. This is the reason we have been keeping the cross tools at > emdebian.org site. > > Then relaying on -source packages approach was suggested by Matthias > and not entirely rejected by Ganeff when I talked to him about it. A > visualization of the build dependencies can be found at: > http://www.emdebian.org/~zumbi/docs/deps.pdf > > There already packages in the archive build depending on -source, like > binutils-z80, which is not much different from binutils-armel > approach. Of course it is a sane approach but very special care needs to be taken when releasing to ensure GPL compliance. So what we should get is support in the toolchain to declare against what source package the upload was built to keep that around. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Minimal kernel version raised to 2.6.27
On 2009-11-10, Marco d'Itri wrote: >> Since it's seeming more and more common for udev to be tied to specific >> kernel versions, have you considered allowing major versions of udev >> to be installed in parallel? > Yes, it would not work because they also tend to be incompatible with > older configurations and so packages would need to provide two sets of > configuration files (for a start). Uh, so the reboot to get a newer kernel before the upgrade could possibly fail due to outdated configuration files by packages which are not upgraded yet? Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Build logs from local builds
On 2009-11-11, Mike Hommey wrote: >> Yes, you're missing at least the lintian checks that happen on ftp-master. > You mean, the ones that should be running on buildd generated packages > anyway ? Sadly there is no easy way to let buildd cope with packages vanishing on ftp-master and not being accepted into the archive (stuck in state Uploaded) unless we parse REJECT messages directly on the buildd or unless we can get some out-of-band notification that a package needs to be reset into some other state. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Build logs from local builds
On 2009-11-11, Stefano Zacchiroli wrote: > Personally, I think that the extreme trade-off of making source upload > the default (which seems to be what you are arguing for) would be too > risky in term of degraded package quality. Look for the "FTBFS" string > in the current RC bug list, do you think the number of occurrences we > have now would decrease implementing such a proposal? I wonder if most of those are either a) not present at source package upload time because the libraries changed later on and b) they are arch-specific, i.e. how much of those FTBFS are left if you remove those and of the "maintainer failed in a very bad way and it compiled on no architecture available to Debian" kind. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bits from the FTPMaster meeting
On 2009-11-15, Goswin von Brederlow wrote: > If Architecture: all is kept then maybe allow source+all uploads? Those are already possible. If they're allowed is another question, though. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bits from the FTPMaster meeting
On 2009-11-16, Simon Huggins wrote: > If you throw away the binaries, a DD can upload a binary package with a > sole binary that prints out banana and a source package that builds the > right thing presumably. Are there any checks to prevent that? > > I'm trying to work out if you get what you think you do from building > but throwing away that makes it better than entirely source-only. You can run lintian on the resulting binaries, which you can't on source-only uploads. (Well, you can only check the source package.) Now, if that stub binary you upload is free from errors ftp-masters reject upon, then you can still work around that. And I didn't bother to check now if they really rely on binary checks yet, however I'd at least assume something like binary-package-is-empty. ;-) Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bits from the FTPMaster meeting
On 2009-11-18, Andreas Tille wrote: > Well, I do not think that you can do gene sequencing or number crunching > on current mobile phones. So there are really programs which are not > needed on all architectures and even if you find a binary package which > claims to do the job it is just useless. Even if I agree with your > arguing that each program at least theoretically should build on any > architecture (if not it is a bug) in some cases it looks foolish to > provide binary packages just for the sake of it. This is was Charles > meant when he wrote: We should trust the maintainer if a specific > program is not needed for a certain architecture. Or the porters (c.f. xorg video or drivers on s390). But that's what P-a-s is for, at the moment. Still it ought to be buildable everywhere, there might not be clusters of arm yet but I saw offers for clusters of mips. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bits from the FTPMaster meeting
On 2009-11-18, Felipe Sateler wrote: > This is not generally true. There are are classes of bugs that appear on > different platforms _due to being different platforms_, not just because > they were latent bugs waiting to be discovered. I presume that packages > that require as much efficiency as possible (like Charles is implying in > his packages) are very likely to implement platform-specific > hacks/optimizations to run faster. It can be considered bad design, ugly > and whatnot, but it is irrelevant if nobody ever uses other platforms. However that's one *exact* use-case for P-a-s. If you do such optimizations. (C.f. zsnes with its x86 assembly as a hard example.) Mostly, though, I'd guess that it's written in a higher-level language without resorting to architecture-dependent assembly. And this code should, barring alignment issues, also run on other platforms. (Ok, there are weird cases of stack growing upwards, that's a special case I agree upon. However in most programs you do not need to deal with this fact.) Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bits from the FTPMaster meeting
On 2009-11-19, Luk Claes wrote: > This could only work if the built package is needed on the same buildd > it was built. That depends on the assumptions. If the assumption is that the buildds are trusted (the same as for autosigning) it would also be easy to argue that setting up some kind of collective protected repository for sharing among the buildd would not be totally insane. But then, just implement autosigning, get rid of that step and reuse autobuilding accepted, or however it's called nowadays. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bits from the FTPMaster meeting
On 2009-11-19, Goswin von Brederlow wrote: >> This could only work if the built package is needed on the same buildd >> it was built. > What part of "require some coordination with wanna-build" did you not read? Well, maybe because wanna-build wouldn't be involved except for an updated data source for edos-debcheck. Otherwise wanna-build does not really care from which repositories the buildds fetch. Sadly. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: nexuiz-data does not fit on a single CD
On 2009-11-20, Stefano Zacchiroli wrote: > Personally I completely agree with what you said, CD (at least as a > medium to get the whole of Debian) are the past and I couldn't care less > about supporting them. That, in my eyes, does not solve our problem of > deciding whether we want to support them _nevertheless_, given that CD > are not so long in the past, and given that not every citizen in the > world has a bandwidth capable of downloading 750 Mb. Sorry, but there are more options than CD and downloading: DVDs. And that's a viable solution here, IMHO. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
On 2009-11-23, Joerg Jaspert wrote: > So for that, yes, you want to think about the dput solution. Which would > have the nice added benefit to actually save people form uploading and > wasting bandwidth and time. Everybody should pipe his uploads through lintian. That's nothing that should be in the upload tool, IMHO. A unixy tool does one job, not two. Of course the Lintian standards for rejects could vary between package build and upload time and it hitting the archive. But then that's nothing a dput hook would catch neither. Kind regards, Philipp Kern PS: A working p-u-new would be much appreciated. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
