Re: APT public key updates?
On Fri, Jan 06, 2006 at 08:21:14AM -0500, Joey Hess wrote: In that case I suggest you rotate it every month for a few cycles. That might not be such a bad idea; having unstable on a weekly rotation cycle that continues until we've worked out how to handle updates, with a final rotation back to the current 2006 key then. BTW, has anyone thought about what will happen when we have a stable release that has the 200n key in it and 200n+1 rolls around[1]? Will stable even be installable anymore? How will the updated key be pushed out to stable quickly enough? Will we have to rebuild CDs and obsolete all the old ones then too? Is the current scheme of having overlapping signatures for 1 month long enough, given that stable users might well only update their machines quarterly or so? Perhaps expiry isn't exactly what we want -- it's possible we want an archive key that will only verify Release files with a date earlier than a given date; but will continue to do so for an extended period of time. Cheers, aj signature.asc Description: Digital signature
Re: APT public key updates?
On Sat, Jan 07, 2006 at 02:32:20AM -0800, Steve Langasek wrote: This is inconsistent with Debian's past policies wrt stable releases, namely, that it should be possible for a user to skip all point releases and security updates (at the peril of their system's security...) and still be able to upgrade when a new stable release comes out. OTOH, past policies have also required manually tweaking various things in order to do the upgrade (first, upgrade libc5 and install libc6, then install dpkg, then use dselect). Cheers, aj signature.asc Description: Digital signature
Re: Need for launchpad
Romain Francoise wrote: Automatic import of the Debian LDAP data? I don't think Debian'd give the data away. Also, the accounts correspond to package maintainers rather then Debian developers (I don't use my @d.o address for packages). If it was the latter, surely they could have done better with identification of DDs [1]. Kind regards T. 1. https://launchpad.net/people/debiandevelopers -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Need for launchpad
On Mon, Jan 09, 2006 at 08:45:02AM +0100, Romain Francoise wrote: Matt Zimmerman [EMAIL PROTECTED] writes: Developers will choose to use them when and where it makes sense for them to do so. Ironically enough, it looks like all Debian Developers already have an account there... because I have one, and I never ask for one: URL: https://launchpad.net/people/rfrancoise Automatic import of the Debian LDAP data? URL: https://launchpad.net/people/asuffield URL: https://launchpad.net/people/srivasta etc... I shall upload some of Manoj's pornography immediately. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
ITP: gtk-chtheme -- A little program to change your GTK+ 2.0 theme
Subject: ITP: gtk-chtheme -- A little program to change your GTK+ 2.0 themePackage: wnppOwner: Troyo Boyo [EMAIL PROTECTED]Severity: wishlist*** Please type your report below this line *** * Package name : gtk-chtheme Version : 0.3.1 Upstream Author : Aristotle Pagaltzis [EMAIL PROTECTED]* URL : http://plasmasturm.org/code/gtk-chtheme/* License : GPL Description : A little program to change your GTK+ 2.0 themeDerived from gtk-theme-switch, but better, imho.-- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable')Architecture: i386 (i686)Shell: /bin/sh linked to /bin/bashKernel: Linux 2.6.15-trx1Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -- Please do not send me HTML e-mail or proprietary attachments.If you want a Gmail invite, just ask :)
Re: Need for launchpad
Thomas Viehmann [EMAIL PROTECTED] writes: I don't think Debian'd give the data away. Hmm? The data is was referring to is public (login and full name). I wasn't implying that Launchpad had data from the private part of our LDAP db (it doesn't). -- ,''`. : :' :Romain Francoise [EMAIL PROTECTED] `. `' http://people.debian.org/~rfrancoise/ `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: packages for sale
Hi Clint! On 1/9/06, Clint Adams [EMAIL PROTECTED] wrote: I intend to orphan the following packages: bricolage dbacl I intend to adopt the above packages. If you want one of these, upload it with yourself as Maintainer. Immediately. Unfortunately, I cannot upload myself as I am not yet a DD. Should I file ITA bugs to wnpp, or will I just ping you when I have the packages ready for sponsoring/upload? Cheers, Zakame -- Zak B. Elep || http://zakame.spunge.org [EMAIL PROTECTED] || [EMAIL PROTECTED] 1486 7957 454D E529 E4F1 F75E 5787 B1FD FA53 851D
Re: poppler
Moritz Muehlenhoff [EMAIL PROTECTED] wrote: Frank Küster wrote: poppler (#344738), orphaned 4 days ago Reverse Depends: libpoppler-glib-dev libpoppler-dev abiword-plugins libpoppler-qt-dev libkpathsea4 evince libpoppler0c2-qt tetex-bin libpoppler0c2-glib ... and hopefully some more in the future. There are a couple of packages with copies of xpdf code in them (different minor versions, of course...), and they have been an annoying source of work every time a security issue pops up in xpdf. As we (or rather Martin Pitt) have shown with tetex-bin, switching to poppler is quite easy; but for that the package should be well maintained. These source packages embed xpdf source and should be fixed to use poppler if possible: gpdf pdftohtml kdegraphics (kpdf) koffice libextractor AFAIK, poppler was created by the freedesktop people specifically in order to replace xpdf code in Gnome and KDE applications. Therefore I expect that at least kpdf an gpdf, and probably koffice will link against poppler in a new release (and already do in CVS?) cupsys also embeds xpdf source, but uses xpdf-utils for current versions. Yes, so this is not an issue for Debian currently, but it might be good to urge upstream to do the switch. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Canonical's business model
Le lundi 09 janvier 2006 à 06:58 +, Andrew Suffield a écrit : ...damnit, I never thought of that. And you know why not? Because on some level I thought that all the noise they make about 'contributing back to Debian' was more than just lip service. I had (stupidly) wanted to believe that it wasn't *just* their PR machine at work. I've never received *any* contribution brought back from Ubuntu. Not a single bug report. Only a bogus web page with outdated and unuseful diffs. On the other side, important improvements to my packages are sometimes integrated to Ubuntu in an amazingly short amount of time. This is fair. After all, that's what Free software is about. But I know for sure that contributing back to Debian stuff is 100% talk and 0% reality. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: ITP vexim
On Sun, 8 Jan 2006 23:58:04 +0100, Daniel Knabl [EMAIL PROTECTED] wrote: @Marc: the packaging was done with source prepared by dh_make. I don't know what you're talking about. This is e-mail. References: Headers are a useful thing. Please don't break them on purpose by introducing conventions originating in web forums. As to your beginner-level packaging questions, I'd like to kindly point you to debian-mentors. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: Bug#346606: ITP: personalbackup -- Company-wide solution for backing up machines and shares.
On Mon, 09 Jan 2006 02:27:28 +0100, Kim Kuylen [EMAIL PROTECTED] wrote: No client software is needed at all to pull backups of your critical data. Is client software needed to back up non-critical data? Which network protocol is used for the backup? What privileges are necessary? Are the backups generated fully restoreable? What about the registry? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Packet radio and foul language
On Sun, 2006-01-08 at 09:02 +0100, Stephan Hermann wrote: - Do not use foul language; besides, some people receive the lists via packet radio, where swearing is illegal. This sentence surprised me in quite some ways: - besides: besides what? Do not swear, and apart from that, some people receive it over radio. There seems to be something missing. - Are there really people known to receive these lists over packet radio?? - Is swearing actually illegal on packet radio? What authority issues and enforces those rules? - Is it actually true that when sending encoded data over this medium, it's illegal when it can be decoded in some way into a foul word? Since I know virtually nothing about packet radio, I'd really appreciate some light shed on these things :) Thijs signature.asc Description: This is a digitally signed message part
unsolvable circular dependencies and package splitting
I wanted to report a circular dependency bug in fontconfig, but found the discussion http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%23310877%3A with apparent outcome: the fontconfig -libfontconfig1 dependency cannot be resolved. If a circular dependency cannot be resolved because both packages always need eachother, would policy not mandate that both packages be merged? Or maybe policy should be updated to allow circular dependencies in cases that they are `unsolvable', and list those cases? Jan. -- Jan Nieuwenhuizen [EMAIL PROTECTED] | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unsolvable circular dependencies and package splitting
On Mon, Jan 09, 2006 at 11:21:28AM +0100, Jan Nieuwenhuizen wrote: I wanted to report a circular dependency bug in fontconfig, but found the discussion http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%23310877%3A with apparent outcome: the fontconfig -libfontconfig1 dependency cannot be resolved. Huh? The bottom of that bug log shows a proposed solution that should work just fine. If a circular dependency cannot be resolved because both packages always need eachother, would policy not mandate that both packages be merged? Shipping files in /usr/bin as part of a lib package causes problems for coinstallability when there's an soname change. Even if you could guarantee forwards-compatibility of interfaces, and as a result ship /usr/bin/fc-cache in each lib package with Replaces:, there's the possibility you might remove a later version of the lib and take the config files with it... Or maybe policy should be updated to allow circular dependencies in cases that they are `unsolvable', and list those cases? There shouldn't be any cases that are unsolvable AFAICT. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#347202: ITP: xmms-midi -- MIDI plugin for XMMS
Package: wnpp Severity: wishlist Owner: Paul Wise [EMAIL PROTECTED] * Package name: xmms-midi Version : 0.03 Upstream Author : Chris Reed [EMAIL PROTECTED] * URL : http://web.archive.org/web/20040401143932/http://ban.joh.cam.ac.uk/~cr212/xmms-midi/ * License : GPL Description : MIDI plugin for XMMS This plugin enables XMMS to play MIDI files through Timidity. Although upstream is long gone, I use this plugin quite a bit and will maintain it properly until such time as I no longer use xmms. I'll need a sponsor. Co-maintainers are welcome. -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Bug#346606: ITP: personalbackup -- Company-wide solution for backing up machines and shares.
Le lundi 09 janvier 2006 à 02:27 +0100, Kim Kuylen a écrit : Package: wnpp Severity: wishlist Owner: Kim Kuylen [EMAIL PROTECTED] * Package name: personalbackup Version : 1.0.1-1 Upstream Author : Name [EMAIL PROTECTED] * URL : http://users.skynet.be/linuxtuxie/debian/personalbackup_1.0.1-1_i386.deb This URL should be the upstream project URL. [..]
Re: Packet radio and foul language
Thijs Kinkhorst wrote: On Sun, 2006-01-08 at 09:02 +0100, Stephan Hermann wrote: - Do not use foul language; besides, some people receive the lists via packet radio, where swearing is illegal. This sentence surprised me in quite some ways: - besides: besides what? Do not swear, and apart from that, some people receive it over radio. There seems to be something missing. - Are there really people known to receive these lists over packet radio?? - Is swearing actually illegal on packet radio? What authority issues and enforces those rules? Yes, the FCC. See part 97 of the FCC rules (US CFR Title 47), specifically § 97.113(1) [0] - Is it actually true that when sending encoded data over this medium, it's illegal when it can be decoded in some way into a foul word? Yes. And actually, it wouldn't be sent encoded that much (unless it's base64 encoded server to server or something), it'd be an ASCII transmission. Since I know virtually nothing about packet radio, I'd really appreciate some light shed on these things :) Glad to help. 73, Benjamin, KI4CXN Thijs [0] http://ecfr.gpoaccess.gov/cgi/t/text/text-idx?c=ecfrview=textnode=47:5.0.1.1.6idno=47#47:5.0.1.1.6.2.155.7 signature.asc Description: OpenPGP digital signature
Bug#347203: ITP: millerquest -- non-interactive role-playing simulator game
Package: wnpp Severity: wishlist Owner: Guido Trotter [EMAIL PROTECTED] * Package name: millerquest Version : 0.9.1 Upstream Author : Urpo Lankinen * URL : http://www.beastwithin.org/users/olf/games/millerquest/ * License : GPL Description : non-interactive role-playing simulator game Miller's Quest! is a role-playing simulator game. It could also be described as a fire-and-forget role-playing game. In other words, it is not a role-playing game in the most traditional sense, because there is absolutely no player interaction. The emphasis on this game is the simulation of role-playing. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Canonical's business model
On Monday 09 January 2006 10:02, Josselin Mouette wrote: This is fair. After all, that's what Free software is about. But I know for sure that contributing back to Debian stuff is 100% talk and 0% reality. There is at least one area where there is a substantial contribution from people working on Ubuntu and that is Debian Installer. I also think that X.Org maintenance has benefitted a lot from work done earlier for Ubuntu. So 0% is just not true. pgptxlk4fY6j5.pgp Description: PGP signature
Cooperating With Canonical Employees
On Mon, Jan 09, 2006 at 01:42:23PM +0100, Frans Pop wrote: On Monday 09 January 2006 10:02, Josselin Mouette wrote: This is fair. After all, that's what Free software is about. But I know for sure that contributing back to Debian stuff is 100% talk and 0% reality. There is at least one area where there is a substantial contribution from people working on Ubuntu and that is Debian Installer. I also think that X.Org maintenance has benefitted a lot from work done earlier for Ubuntu. So 0% is just not true. An important point about both of these cases is that it comes down entirely to the people, not the technology. It's not arch or launchpad or Scott's patchlist that lets these two examples happen. It's that Colin has decided to remain heavily involved with the d-i team and Daniel and I have decided to collaborate closely on Xorg. Note that in the Xorg case Daniel very publicly wanted nothing to do with the XSF (I'm not going to dig up the ugly link for this) but I've made an effort to do more than just take his work, but instead to reach out and establish a strong tie with him. I think we've both benefitted from it. The way to collaborate well with Canonical employees or MOTU remains the exact same as it does for collaborating with anyone else inside or outside of Debian. Establish a good working relationship with them on a personal level by asking questions, soliciting advice politely, and rolling up your sleeves and getting some work done. Free software on the scale that Debian exists is fundamentally a social activity, and if you want it to work you have to make an effort on the human level. All this crap about launchpad, arch vs svn, and other such tools is entirely the wrong debate to be having. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: hppa dependency problems on build of pdns
Matthijs Mohlmann [EMAIL PROTECTED] wrote: Hi, I don't know where to send this else, so forgive me if this is the wrong mailinglist. See: http://buildd.debian.org/fetch.php?pkg=pdnsver=2.9.19-2arch=hppastamp=1135294848file=logas=raw [..] [...] As you can see, tetex-base depends on tex-common (= 0.12). But the hppa build daemon doesn't install tex-common. So can somebody tell me what's going on here ? The same happened to the planner package, and has been reported as #344538. It seems that hppa buildd is broken, don't know yet whether the buildd admin (Lamont) or anybody of the debian-admin (responsible for the hardware) is at it. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: gconf transition
* Josselin Mouette | /usr/lib/libgconf2-4/gconf-sanity-check-2: error while loading shared | libraries: libpangocairo-1.0.so.0: cannot open shared object file: No such | file or dir | | Ladies and gentlemen, this is a perfect example of why linking indirect | dependencies is a very bad thing. Let me explain. No, it's not. At least not in the way GTK friends work. | Of all binaries shipped with GConf, gconf-sanity-check is the only one | using GTK+. The only application using gconf-sanity-check is | gnome-session. On first sight, it looks safe to exclude | gconf-sanity-check for the computation of gconf dependencies, Uhm, this is where you go wrong. You can't just exclude binaries nilly-willy like this. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ITP vexim
Am Mon, 09 Jan 2006 10:30:32 +0100 Marc Haber [EMAIL PROTECTED] schrieb: ... Please don't break them on purpose by introducing conventions originating in web forums. It seems, there is something misconfigured in my Sylpheed-Claws. I will try to fix this as soon as possible. As to your beginner-level packaging questions, I'd like to kindly point you to debian-mentors. I agree ;-) BTW debian-mentors sounds useful. Greetings Marc Greetings Daniel -- mfg Daniel Knabl http://www.tirolinux.net PGP Fingerprint [EMAIL PROTECTED] A069 671B 39F2 E9B9 FB34 68BB 4BEC 1344 C8A4 3F0B pgpUFI22EWwtS.pgp Description: PGP signature
Re: Need for launchpad
* Roland Mas | I don't see why the poor oppressed non-elite should have tools | they find easy to use and the arrogant elite shouldn't. If my | not-quite-geek sister wants to use her web browser to translate stuff, | I don't see why she should be prevented from doing that, but then if | I, as an arrogant bastard, want to use my ~/bin-full of ugly shell, | Perl and awk scripts, why should I not be allowed to? AIUI, launchpad is going to be accessible through XML-RPC which will make it possible to write decent command line interfaces working with it. It will obviously be slower than accessing data on local hard drives, but it should, hopefully, be fully-functional. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Requesting NMU for toshutils
Greetings, [Please do not reply to this email as my @yahoo.es account is a junk account which I do not check.] Bug #346896 was recently filed against toshutils. I am not able to correct this bug right now and would sincerely appreciate it if someone could NMU it for me. Due to a catastrophic hardware failure last month and now waiting for Internet access to be installed at my new place, there is really no way I can fix this in a reasonable time frame. If you do NMU to fix this bug, please attach a diff of the debian/ directories in the source package to this bug and also CC to [EMAIL PROTECTED] I will not get the email right away, but I will eventually, as Sean Finney has graciously agreed to collect my emails for me until I get Internet access at home (thanks Sean). Regards, -Roberto Sanchez __ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y moviles desde 1 centimo por minuto. http://es.voice.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
My New Years' resolution: fix one RC bug a day
Le Mardi 03 Janvier 2006 21:24, Andreas Barth a écrit : However, we need to start *now* to give the RC-bug count some more attention. This means also that we're going to start again an everlasting BSP: For RC-bugs, you can upload 0-days NMUs for RC-bugs open for more than one week. However, you are still required to notify the maintainer via BTS before uploading. And of course, you need to take care of anything you broke by your NMU. I've had an idea on a good way to decrease the RC-bug count without burning myself out: I've resolved to fix one RC bug a day at least until there are no more trivial RC bugs left. I started Friday by NMU'ing libxklavier; over the weekend I worked on uploads for tcl8.* and tk8.* and then fortunately found the maintainer is working on fixing bugs for those packages. For today, unless I hear something on bug #335137 within a couple hours, I'll do an NMU for libwmf; and for tomorrow, I just noticed there's an RC bug against kdeedu for me to fix myself. I figure if I keep this up, I can take care of 30 RC bugs a month; and if just 9 other people join me, that will make 300 RC bugs a month. -- Daniel Schepler
Re: Cooperating With Canonical Employees
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Nusinow [EMAIL PROTECTED] writes: The way to collaborate well with Canonical employees or MOTU remains the exact same as it does for collaborating with anyone else inside or outside of Debian. Establish a good working relationship with them on a personal level by asking questions, soliciting advice politely, and rolling up your sleeves and getting some work done. No disagreements here. One problem I do see is that many (most?) Ubuntu packages do not have a maintainer; big packages like X are probably an exception. When I check my own I see that each upload has been by a different person almost every time, which makes it difficult to firstly know who I should contact, and secondly I have doubts about their familiarity with the package if there's no one who really cares for it. Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ http://mailcrypt.sourceforge.net/ iD8DBQFDwm+dVcFcaSW/uEgRAqEfAJ0c1TUFN5Jg20ANL5Yh88LRuW914gCggXt3 XVGuABHtgTSCwPVGUgTpB8k= =Ya5y -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gconf transition
On Sat, Jan 07, 2006 at 03:09:34PM +0100, Josselin Mouette wrote: Le vendredi 06 janvier 2006 à 14:28 -0600, Alejandro Bonilla a écrit : /usr/lib/libgconf2-4/gconf-sanity-check-2: error while loading shared libraries: libpangocairo-1.0.so.0: cannot open shared object file: No such file or dir Ladies and gentlemen, this is a perfect example of why linking indirect dependencies is a very bad thing. Let me explain. Linking indirect dependency isn't a good thing, but not linking to them isn't magicly going to fix bugs like this. Of all binaries shipped with GConf, gconf-sanity-check is the only one using GTK+. The only application using gconf-sanity-check is gnome-session. On first sight, it looks safe to exclude gconf-sanity-check for the computation of gconf dependencies, as gnome-session will always require libgtk2.0-0, and gconf-sanity-check isn't susceptible to use any symbols that could be added to GTK+. You should _never_ exclude anything for the calculation of the dependencies, because it will result in such errors. Even if you think some other dependency will (now) take care of this for you doesn't mean you shouldn't have a depends on it. There are cases where excluding something can make sense, but this isn't one of them. Now, let's have a look at gconf-sanity-check: NEEDED libgtk-x11-2.0.so.0 [...] NEEDED libpangocairo-1.0.so.0 [...] So gconf-sanity-check-2 (from the libgconf2-4 package) NEEDS libpangocairo-1.0.so.0 from the libpango1.0-0 package. So libgconf2-4 should depend on libpango1.0-0. And it doesn't. This is an RC bug in the libgconf2-4 package. It's also missing all those other depends, specially the one on libgtk2.0-0. The only libraries from which it actually uses symbols are libgconf2, libgtk-x11, libglib and libc. It seems to be: libgtk-x11-2, libgconf-2, libpopt, libgobject-2, libpthread, libglib-2 and libc. So make it only link to those libraries instead. This shouldn't be that hard. And I think that using --as-needed as you did is the wrong way to go. This should be a last resort option in case you really can't fix it some other way. So in short you should: - Remove the -Xgconf-sanity-check from DEB_DH_SHLIBDEPS_ARGS This is something you should do in _any_ case since it's just wrong. - Remove the LDFLAGS=-Wl,--as-needed from DEB_CONFIGURE_SCRIPT_ENV - Use Debian's libtool - Only link (gconf-sanity-check-2) to the libraries it needs. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unsolvable circular dependencies and package splitting
* Steve Langasek | Shipping files in /usr/bin as part of a lib package causes problems for | coinstallability when there's an soname change. Even if you could guarantee | forwards-compatibility of interfaces, and as a result ship /usr/bin/fc-cache | in each lib package with Replaces:, there's the possibility you might remove | a later version of the lib and take the config files with it... That will also get you into an «interesting» situation with multiarch paths. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: Canonical's business model
Frans Pop [EMAIL PROTECTED] wrote: On Monday 09 January 2006 10:02, Josselin Mouette wrote: This is fair. After all, that's what Free software is about. But I know for sure that contributing back to Debian stuff is 100% talk and 0% reality. There is at least one area where there is a substantial contribution from people working on Ubuntu and that is Debian Installer. I also think that X.Org maintenance has benefitted a lot from work done earlier for Ubuntu. Let me add - security patches for packages with copies of xpdf code - a very much longed-for patch to build pdftex (in tetex-bin) against libpoppler instead of against its copy of xpdf code. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: gconf transition
Le lundi 09 janvier 2006 à 14:41 +0100, Tollef Fog Heen a écrit : | Ladies and gentlemen, this is a perfect example of why linking indirect | dependencies is a very bad thing. Let me explain. No, it's not. At least not in the way GTK friends work. Why so? | Of all binaries shipped with GConf, gconf-sanity-check is the only one | using GTK+. The only application using gconf-sanity-check is | gnome-session. On first sight, it looks safe to exclude | gconf-sanity-check for the computation of gconf dependencies, Uhm, this is where you go wrong. You can't just exclude binaries nilly-willy like this. Of course I can. The gconf-sanity-check binary is absolutely not necessary for the rest of the gconf functionality. This is an optional add-on, which isn't even in /usr/bin. It is perfectly safe to put its dependencies in Recommends:. A more elegant solution would be to make a separate package for gconf-sanity-check, but it is only 11K. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: gconf transition
Le lundi 09 janvier 2006 à 15:45 +0100, Kurt Roeckx a écrit : Linking indirect dependency isn't a good thing, but not linking to them isn't magicly going to fix bugs like this. How so? Please show me a case where the bug will still be here. You should _never_ exclude anything for the calculation of the dependencies, because it will result in such errors. Even if you think some other dependency will (now) take care of this for you doesn't mean you shouldn't have a depends on it. The gconf-sanity-check functionality is optional. As such, its dependencies can go in the Recommends: field. The bug was that these dependencies were missing indirect libraries the binary actually requires. So gconf-sanity-check-2 (from the libgconf2-4 package) NEEDS libpangocairo-1.0.so.0 from the libpango1.0-0 package. So libgconf2-4 should depend on libpango1.0-0. And it doesn't. This is an RC bug in the libgconf2-4 package. It's also missing all those other depends, specially the one on libgtk2.0-0. Nothing linking with libgconf2-4 will stop working when these dependencies aren't installed. Some optional functionality will, but it is not part of the functionality almost all packages using gconf2 actually need. It seems to be: libgtk-x11-2, libgconf-2, libpopt, libgobject-2, libpthread, libglib-2 and libc. So make it only link to those libraries instead. This shouldn't be that hard. You haven't investigated how to do it, have you? And I think that using --as-needed as you did is the wrong way to go. This should be a last resort option in case you really can't fix it some other way. I don't believe --as-needed should be a last resort option. Is dh_fixperms a last resort option when you cannot fix the build system to install files with proper permissions? Even with a fixed build system, you still use dh_fixperms, just to be sure. The same goes for --as-needed. As for relibtoolizing, it is currently not possible to relibtoolize all GNOME packages, because of a lack of manpower. If you want to see them relibtoolized, you'd better get libtool upstream to accept the Debian patches. Even with relibtoolized packages, the problem remains, because of pkg-config. As GNOME headers have a spurious tendency to include headers from most of their dependencies, it isn't possible to move them to private dependencies. Regards, -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: apt-torrent (WAS: Re: apt PARALLELISM)
It'll take me some time to find a new, and more appropriate home for apt-torrent. The Debian archive (experimental distribution) would be a *very* appropriate home. It won't provide a testbed package seeder or place to download .torrent files, but that can be done later (and by any number of different people, actually). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gconf transition
* Josselin Mouette | Le lundi 09 janvier 2006 à 14:41 +0100, Tollef Fog Heen a écrit : | | Ladies and gentlemen, this is a perfect example of why linking indirect | | dependencies is a very bad thing. Let me explain. | | No, it's not. At least not in the way GTK friends work. | | Why so? Because GTK exports and depends on the definitions of GLib (and pango, in this case) types, so if any of those definitions change, you must get the right ones. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: gconf transition
Le lundi 09 janvier 2006 à 16:42 +0100, Tollef Fog Heen a écrit : Because GTK exports and depends on the definitions of GLib (and pango, in this case) types, so if any of those definitions change, you must get the right ones. That's why GTK itself depends on GLib and pango. I don't get your point. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: poppler
Frank Küster wrote: These source packages embed xpdf source and should be fixed to use poppler if possible: gpdf pdftohtml kdegraphics (kpdf) koffice libextractor AFAIK, poppler was created by the freedesktop people specifically in order to replace xpdf code in Gnome and KDE applications. Therefore I expect that at least kpdf an gpdf, and probably koffice will link against poppler in a new release (and already do in CVS?) I've heard that gpdf is to be replaced by evince in GNOME, which already links dynamically, so it's probably best to remove it for Etch. Unfortunately kpdf upstream seems quite reluctant to switch to poppler, see http://bugs.kde.org/show_bug.cgi?id=119455. I don't know the status of koffice. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: APT public key updates?
Paul TBBle Hampson wrote: On Sat, Jan 07, 2006 at 12:16:36PM +0100, Bernd Eckenfels wrote: Paul TBBle Hampson [EMAIL PROTECTED] wrote: Maybe the one-true-stable-key idea is the way to go after all... One key by distribution? Well, I meant a different one for each stable, which I guess logically becomes yes... Although as Steve Langasek has pointed out, the Sarge-Etch upgrade will be hard unless the etch key becomes available to Sarge users who've not touched their system since Sarge r0a... I guess this comes down to making the etch key available in some kind of Sarge-signed repository, that you have to add as part of the Etch upgrade, and after which apt-key update will bring you up to Etch key currentness. Assuming apt-key is supposed to be updating from a file in debian-keyring, maybe a new dist (oldstable-upgrade) which really only contains debian-keyring from (new)stable, but which is signed with the oldstable key. Then the online upgrade procedure becomes: Add oldstable-upgrade to your apt-sources apt-get update apt-get install -t oldstable-upgrade debian-keyring apt-key update apt-get update == To recheck signatures... I dunno if this is needed? apt-get dist-upgrade ... time passes echo Welcome to etch! (Or maybe using aptitude, if that's the recommended upgrade method for Etch as well...) I dunno exactly how apt-cdrom works, but maybe it could automatically pick up that an etch CD has both oldstable-upgrade and stable dists, and therefore the process for CD upgrades becomes: apt-cdrom apt-get install -t oldstable-upgrade debian-keyring apt-key update apt-get update == To recheck signatures... I dunno if this is needed? apt-get dist-upgrade ... time passes echo Welcome to etch! You'll still get complaints during apt-get update the first time, but the apt-get install at least won't try to reject debian-keyring for being unsigned, because _it_ is signed with a known signature. For the intervening time, security updates and rX releases thereof allow for stable key rollover as needed, either yearly or when compromised. This way oldstable-upgrade gets rolled-away with the rest of oldstable, and isn't part of oldstable per se and so doesn't complicate security updates or whatnot, and is easy to include on the first CD of the new release for upgraders. And the (new) stable key is therefore (transitively) signed with the oldstable key, maintaining the chain of trust, without actually having to muck about with gpg signatures. Consider the following keys: * sarge key (expires after the date we expect to release etch +1) * etch key (expires after the date we expect to release etch +2) * etch+1 key (likewise for etch +3) * 2005 testing/unstable key (expires at the end of 2006) * 2006 testing/unstable key (expires at the end of 2007) * 2007 testing/unstable key (expires at the end of 2008) The following distributions should be signed as follows on the following dates: etch in 2006: sarge key, etch key, 2005 key, 2006 key etch in 2007: sarge key, etch key, 2006 key, 2007 key testing/unstable in 2006: 2005 key, 2006 key testing/unstable in 2007: 2006 key, 2007 key -- I usually have a GPG digital signature included as an attachment. See http://www.gnupg.org/ for info about these digital signatures. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: poppler
On Monday, 9 January 2006 15:03, Moritz Muehlenhoff wrote: Frank Küster wrote: These source packages embed xpdf source and should be fixed to use poppler if possible: gpdf pdftohtml kdegraphics (kpdf) koffice libextractor AFAIK, poppler was created by the freedesktop people specifically in order to replace xpdf code in Gnome and KDE applications. Therefore I expect that at least kpdf an gpdf, and probably koffice will link against poppler in a new release (and already do in CVS?) I've heard that gpdf is to be replaced by evince in GNOME, which already links dynamically, so it's probably best to remove it for Etch. Unfortunately kpdf upstream seems quite reluctant to switch to poppler, see http://bugs.kde.org/show_bug.cgi?id=119455. I don't know the status of koffice. Hi. From an hour ago: #kpdf: 16:22 isaac uhm, refresh my memory 16:22 isaac will kpdf ever use poppler? 16:22 isaac will it be replaced by okular? 16:24 tsdgeos maybe 16:24 tsdgeos maybe 16:24 Niedakh well if poppler's development process becomes more open 16:24 isaac I see :) 16:24 Niedakh and if someone feels like porting to poppler 16:25 tsdgeos i can do both 16:25 isaac sounds scary! :P 16:25 tsdgeos just need more time 16:25 tsdgeos and more karma 16:25 tsdgeos :D #koffice: 16:30 isaac it would definitely better to be able to use poppler as a external library :) 16:31 mart isaac: indeed, I heard talk about it - I _think_ someone was planning to do it... 16:31 isaac mart: nice to know:) 16:31 mart ... but I don't remember who, or if they were just saying we ought to 16:37 -!- bram85_ is now known as bram85 16:48 mart what's with the complete lack of poppler docs online? 16:53 -!- tsdgeos [EMAIL PROTECTED]/aacid] has joined #koffice 16:53 tsdgeos hi? 16:53 BCoppens mart: isaac : tsdgeos was planning on doing that 16:53 BCoppens :P 16:53 tsdgeos yup i was planning 16:53 tsdgeos just did not have time 16:53 BCoppens tsdgeos: isaac was complaining that it sucks to update 16:53 tsdgeos so i can give some guidance 16:53 mart tsdgeos: 'was planning' != 'still planning' ? 16:54 tsdgeos well it sucks koffice code is xpdf 2.0 based 16:54 BCoppens tsdgeos: biggest issue: 12th is feature freeze (although, you might considder it more 'bugfix' 16:54 tsdgeos mart: not for koffice 1.5 16:54 tsdgeos maybe for 2.0 Best regards -- Isaac Clerencia at Warp Networks, http://www.warp.es Work: [EMAIL PROTECTED] | Debian: [EMAIL PROTECTED] pgpvynEQPCC7C.pgp Description: PGP signature
Re: poppler
On Monday, 9 January 2006 17:00, Isaac Clerencia wrote: #kpdf: #koffice: So it seems that Etch will ship with kpdf and koffice embedding xpdf source.:( Best regards -- Isaac Clerencia at Warp Networks, http://www.warp.es Work: [EMAIL PROTECTED] | Debian: [EMAIL PROTECTED] pgp7CiZdilnh1.pgp Description: PGP signature
Re: APT public key updates?
Anthony Towns wrote: That might not be such a bad idea; having unstable on a weekly rotation cycle that continues until we've worked out how to handle updates, with a final rotation back to the current 2006 key then. xactly Perhaps expiry isn't exactly what we want -- it's possible we want an archive key that will only verify Release files with a date earlier than a given date; but will continue to do so for an extended period of time. Is possible to implement that using gpg? -- see shy jo signature.asc Description: Digital signature
Re: poppler
Isaac Clerencia [EMAIL PROTECTED] wrote: #koffice: 16:30 isaac it would definitely better to be able to use poppler as a external library :) 16:31 mart isaac: indeed, I heard talk about it - I _think_ someone was planning to do it... 16:31 isaac mart: nice to know:) 16:31 mart ... but I don't remember who, or if they were just saying we ought to 16:37 -!- bram85_ is now known as bram85 16:48 mart what's with the complete lack of poppler docs online? JFTR: There's no documentation about xpdf code internals, either. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
lintian problem [shared-lib-without-dependency-information]
Hi,
I'm trying to make my first package... Everything goes fine except one
thing. Lintian says:
W: libvrb0: shared-lib-without-dependency-information
./usr/lib/libvrb.so.0.4.0
I understand what this means, know how to fix it (by adding -lc to ld
arguments). Unfortunately the upstream source uses some strange
(non-auto{make,conf}) build system, meaning (among other things) that
the arguments of ld are hard-coded into the configure script.
Solutions may be:
* modifying the configure script
* manually adding libc to 'Depends:' line
* overriding the warning
Which one sould I choose? Any other idea?
The upstream source is available from http://vrb.slashusr.org/
Thanks for your help,
--
Sze'kelyi Szabolcs
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: poppler
On Mon, Jan 09, 2006 at 03:03:07PM +0100, Moritz Muehlenhoff wrote: I've heard that gpdf is to be replaced by evince in GNOME, which already links dynamically, so it's probably best to remove it for Etch. While evince is nice it is unfortunately unbearably slow compared to gpdf/gv/acroread with some PDF files, so I personally won't be removing gpdf from my system anytime soon. So if someone has some time to fix gpdf once again, it may still worth it. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
yorick package maintainer
Hello, An etch release-blocking bug (#346861) has been reported against my yorick package, as part of the mass xlib-dev build dependency bug. I'm ashamed to admit that I can't fix it myself because my PGP(!) key is no longer supported by Debian. I've made a few attempts to get myself reinstated via [EMAIL PROTECTED] and [EMAIL PROTECTED], but so far no one has been able to help me. If anyone can help me get back to the point that I can use the automated LDAP system described at https://db.debian.org/doc-mail.html I would greatly appreciate it. (Needless to say, I've followed the instructions posted there and the [EMAIL PROTECTED] mail daemon does not respond, even when I sign the request with the obsolete PGP key that is used to sign the current yorick-1.5.14-1 package.) Thank you very much for any help you can provide; I apologize for letting things slide for so long. Dave Munro -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: APT public key updates?
Anthony Towns aj@azure.humbug.org.au writes: On Sat, Jan 07, 2006 at 02:32:20AM -0800, Steve Langasek wrote: This is inconsistent with Debian's past policies wrt stable releases, namely, that it should be possible for a user to skip all point releases and security updates (at the peril of their system's security...) and still be able to upgrade when a new stable release comes out. OTOH, past policies have also required manually tweaking various things in order to do the upgrade (first, upgrade libc5 and install libc6, then install dpkg, then use dselect). This is true, but with suitable use of package scripts and pseudo-packages to manage the upgrade, apt should now be capable of making this happen automagically. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: poppler
Gabor Gombas [EMAIL PROTECTED] wrote: On Mon, Jan 09, 2006 at 03:03:07PM +0100, Moritz Muehlenhoff wrote: I've heard that gpdf is to be replaced by evince in GNOME, which already links dynamically, so it's probably best to remove it for Etch. While evince is nice it is unfortunately unbearably slow compared to gpdf/gv/acroread with some PDF files, so I personally won't be removing gpdf from my system anytime soon. So if someone has some time to fix gpdf once again, it may still worth it. Currently it is probably trivial to change gpdf just for the Debian package, so that it uses libpoppler instead of its copy of xpdf. For pdftex, it was just some -l options in the Makefile.in's, changes to #include statements, and renaming one or two functions from goo which were also used by glib. The patch is at http://svn.debian.org/wsvn/pkg-tetex/tetex-bin/trunk/debian/patches/patch-poppler?op=filerev=0sc=0, and it could probably made even simpler if the #include statements would not be changed and -L/usr/include/poppler etc. used instead. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Requesting NMU for toshutils
Roberto Sanchez wrote: Greetings, Hi Bug #346896 was recently filed against toshutils. I am not able to correct this bug right now and would sincerely appreciate it if someone could NMU it for me. I've tried to fix this bug, but the package FTBFS with the following error: gcc -mtune=i486 -O1 -Wall -I../pixmaps -DLINUX -DXTHREADS -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/X11R6/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -DVERSION=\2.0.1\ -DBINDIR=\/usr/bin\\ -DXMESSAGE=\/usr/bin/X11/xmessage\ -DWALL=\/usr/bin/wall\ -c thotswap.c thotswap.c: In function 'DisplayXMessage': thotswap.c:187: error: 'XMESSAGE' undeclared (first use in this function) thotswap.c:187: error: (Each undeclared identifier is reported only once thotswap.c:187: error: for each function it appears in.) make[2]: *** [thotswap.o] Error 1 make[2]: Leaving directory `/home/luk/tmp/toshutils-2.0.1/src' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/luk/tmp/toshutils-2.0.1' make: *** [build-stamp] Error 2 Any hint to fix this is welcome. Cheers Luk -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D signature.asc Description: OpenPGP digital signature
Re: APT public key updates?
On Sat, Jan 07, 2006 at 04:34:48PM +, Colin Watson wrote: On Thu, Jan 05, 2006 at 04:32:29PM -0800, Matt Zimmerman wrote: On Fri, Jan 06, 2006 at 01:22:50AM +0100, Petter Reinholdtsen wrote: Isn't Ubuntu using the signed apt stuff? How are they handling the new archive keys? Ubuntu's apt package ships only the Ubuntu archive keyring, not the Debian archive keyring, so no update is needed when Debian keys change. That doesn't mean we (Ubuntu) have solved the problem of how to rotate *our* keys in the event of a key compromise. (To my knowledge, we haven't.) Petter's question was about the key which recently expired, not about a hypothetical compromise. That said, we do have a simplistic mechanism for handling key revocations (as does Debian; it's in mainline apt). It is far from ideal, as there isn't a means for establishing an independent trust path to the new key (it'll be authenticated indirectly by the old key), but it has that flaw in common with the old approach of downloading the key from a Debian web server. Most users probably don't have a trust path to the keys used to sign the archive keys. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gconf transition
On Mon, 2006-01-09 at 16:10 +0100, Josselin Mouette wrote: Le lundi 09 janvier 2006 à 15:45 +0100, Kurt Roeckx a écrit : Linking indirect dependency isn't a good thing, but not linking to them isn't magicly going to fix bugs like this. How so? Please show me a case where the bug will still be here. You should _never_ exclude anything for the calculation of the dependencies, because it will result in such errors. Even if you think some other dependency will (now) take care of this for you doesn't mean you shouldn't have a depends on it. The gconf-sanity-check functionality is optional. As such, its Why is gconf-sanity-check optional? It seems pretty vital to me. -- - Ron Johnson, Jr. Jefferson, LA USA Thinking men cannot be ruled. Ayn Rand
udev 080 in experimental
I uploaded to experimental a udev new package with the (theoretical) potential of breaking some custom rules referencing sysfs attributes. I expect that the supporters of experimental will install it today and report their experience. (Lack of reports will be considered positive.) -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: yorick package maintainer
David H. Munro wrote: Hello, Hi An etch release-blocking bug (#346861) has been reported against my yorick package, as part of the mass xlib-dev build dependency bug. I could prepare an NMU if you like, though... I'm ashamed to admit that I can't fix it myself because my PGP(!) key is no longer supported by Debian. I've made a few attempts to get myself reinstated via [EMAIL PROTECTED] and [EMAIL PROTECTED], but so far no one has been able to help me. If anyone can help me get back to the point that I can use the automated LDAP system described at https://db.debian.org/doc-mail.html I would greatly appreciate it. (Needless to say, I've followed the instructions posted there and the [EMAIL PROTECTED] mail daemon does not respond, even when I sign the request with the obsolete PGP key that is used to sign the current yorick-1.5.14-1 package.) you might want to have a look at [1] as that is the procedure to follow to have a new key added to the keyring when you don't have any existing valid key anymore AFAICT. Thank you very much for any help you can provide; I apologize for letting things slide for so long. You're welcome :-) Cheers Luk [1] http://keyring.debian.org/replacing_keys.html -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D signature.asc Description: OpenPGP digital signature
Re: gconf transition
On Monday, 9 January 2006 19:26, Ron Johnson wrote: The gconf-sanity-check functionality is optional. As such, its Why is gconf-sanity-check optional? It seems pretty vital to me. AFAIK only gdm (or gnome-settings-daemon) uses gconf-sanity-check and both depend on libgtk2.0-0. Best regards -- Isaac Clerencia at Warp Networks, http://www.warp.es Work: [EMAIL PROTECTED] | Debian: [EMAIL PROTECTED] pgpuVW97Rn9Wo.pgp Description: PGP signature
Re: Need for launchpad
On Mon, Jan 09, 2006 at 08:45:02AM +0100, Romain Francoise wrote: Matt Zimmerman [EMAIL PROTECTED] writes: Developers will choose to use them when and where it makes sense for them to do so. Ironically enough, it looks like all Debian Developers already have an account there... because I have one, and I never ask for one: URL: https://launchpad.net/people/rfrancoise There's no irony here; metadata for packages in Ubuntu is imported into Launchpad, which includes the name of the Debian package maintainer, and Launchpad allows this information to be browsed in the form of web pages. For any known person in the launchpad database, there is a corresponding web page view under /people/. If you click Packages on that page, you'll see exactly where this information came from. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Getting rid of circular dependencies, stage 3
Hello Debian developers, Here the lists of packages involved in circular dependencies listed by maintainers. This list is also available as http://debian.semistable.com/unstable_developers.txt (update daily, courtesy of Robert Lemmen). I reported around 1/3 to the BTS. I simply hope I won't need to report the remaining 2/3. http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=circular-deps;[EMAIL PROTECTED] Cheers, Bill. Adeodato Sim?? [EMAIL PROTECTED] amarok amarok-arts amarok-engines amarok-gstreamer amarok-xine Alain Schroeder [EMAIL PROTECTED] fsviewer-icons Alastair McKinstry [EMAIL PROTECTED] console-common console-tools Alberto Gonzalez Iniesta [EMAIL PROTECTED] libapache-mod-security libapache2-mod-security mod-security-common Andreas Tille [EMAIL PROTECTED] wordnet wordnet-base Andrew Mitchell [EMAIL PROTECTED] phpgroupware phpgroupware-admin phpgroupware-phpgwapi phpgroupware-preferences phpgroupware-setup Andrew Mitchell [EMAIL PROTECTED] libxsharp0 pnet-assemblies Bdale Garbee [EMAIL PROTECTED] amanda-client amanda-common Bernd Schumacher [EMAIL PROTECTED] bootcd bootcd-hppa bootcd-i386 bootcd-ia64 Brendan O'Dea [EMAIL PROTECTED] perl perl-modules Carlo Contavalli [EMAIL PROTECTED] wipl-client-exec wipl-client-standard wipl-daemon Christian Marillat [EMAIL PROTECTED] librep9 rep Christian T. Steigies [EMAIL PROTECTED] luola luola-data luola-levels Daniel Baumann [EMAIL PROTECTED] lush lush-library Daniel Burrows [EMAIL PROTECTED] heroes-common heroes-ggi heroes-sdl lbreakout2 lbreakout2-data David Coe [EMAIL PROTECTED] iamerican ispell David Moreno Garza [EMAIL PROTECTED] gxmms-bmp gxmms-common gxmms-xmms liferea liferea-gtkhtml liferea-mozilla Davide Puricelli (evo) [EMAIL PROTECTED] xchat xchat-common Debian Catalyst Maintainers [EMAIL PROTECTED] libhtml-tree-perl Debian GCC Maintainers debian-gcc@lists.debian.org g++-3.3 g++-3.4 g++-4.0 gcj gcj-4.0 java-gcj-compat lib64gcc1 libgcj-dev libgcj6-dev libstdc++5-3.3-dev libstdc++6-4.0-dev libstdc++6-dev Debian GCC maintainers debian-gcc@lists.debian.org g++-2.95 libstdc++2.10-dev Debian GNOME Maintainers [EMAIL PROTECTED] gamin libgamin0 libgnomevfs2-0 libgnomevfs2-common Debian GNUstep maintainers [EMAIL PROTECTED] gnustep-back0.10 gnustep-base-common gnustep-gpbs gnustep-gui-common gnustep-ppd libgnustep-base1.11 libgnustep-gui0.10 Debian Italian Maintainers Task Force [EMAIL PROTECTED] festlex-ifd festvox-italp16k festvox-itapc16k Debian Java Maintainers pkg-java-maintainers@lists.alioth.debian.org antlr eclipse-jdt eclipse-jdt-common gjdoc kaffe kaffe-jthreads kaffe-pthreads libgnucrypto-java libjessie-java libswt3.1-gtk-java libswt3.1-gtk-jni Debian LyX Maintainers [EMAIL PROTECTED] lyx-common lyx-qt lyx-xforms Debian Mono Group [EMAIL PROTECTED] libapache-mod-mono mono-apache-server monodoc-browser monodoc-http monodoc-manual Debian NTP Team [EMAIL PROTECTED] ntp-refclock ntp-server ntp-simple Debian OpenOffice Team debian-openoffice@lists.debian.org openoffice.org-common openoffice.org-core Debian Qt/KDE Maintainers debian-qt-kde@lists.debian.org kdelibs-bin kdelibs4c2a koffice-data koffice-libs libkcal2b libkdepim1a Debian Webmin maintainers [EMAIL PROTECTED] webmin-core webmin-mailboxes Debian X Strike Force debian-x@lists.debian.org libx11-dev libxi-dev Debian Xfce Maintainers [EMAIL PROTECTED] xfce4-mixer xfce4-mixer-alsa xfce4-mixer-oss Debian Zope Team [EMAIL PROTECTED] zope-ploneerrorreporting Debian/Ubuntu Zope Team [EMAIL PROTECTED] zope-atcontenttypes zope-cmfplone Denis Barbier [EMAIL PROTECTED] belocs-locales-bin belocs-locales-data kbd Dirk Eddelbuettel [EMAIL PROTECTED] gretl gretl-common libgretl1 Drew Parsons [EMAIL PROTECTED] mirrormagic mirrormagic-data Emmanuel Lacour [EMAIL PROTECTED] libapache-mod-suphp libapache2-mod-suphp suphp-common Erich Schubert [EMAIL PROTECTED] enigma enigma-data Fabian Fagerholm [EMAIL
wpa_supplicant: looking for a co-maintainer
Hi, A couple months ago, I registered a pkg_wpa project at alioth with the intent of moving wpasupplicant to a more collaborative packaging effort, mostly due to lack of time on my part. I'd forgotten I'd done this for a while, and then lost use of my laptop for a few months, so wpasupplicant became quite neglected. Anyway, I'd like some help fixing it up, so if anyone wants to help co-maintain the package, I'll get things going on the alioth project... just submit some bugfixes to show that you care... :) Cheers, Kyle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gconf transition
[Re-sending, my previous reply didn't made it.] Le lundi 09 janvier 2006 à 15:45 +0100, Kurt Roeckx a écrit : Linking indirect dependency isn't a good thing, but not linking to them isn't magicly going to fix bugs like this. How so? Please show me a case where the bug will still be here. You should _never_ exclude anything for the calculation of the dependencies, because it will result in such errors. Even if you think some other dependency will (now) take care of this for you doesn't mean you shouldn't have a depends on it. The gconf-sanity-check functionality is optional. As such, its dependencies can go in the Recommends: field. The bug was that these dependencies were missing indirect libraries the binary actually requires. So gconf-sanity-check-2 (from the libgconf2-4 package) NEEDS libpangocairo-1.0.so.0 from the libpango1.0-0 package. So libgconf2-4 should depend on libpango1.0-0. And it doesn't. This is an RC bug in the libgconf2-4 package. It's also missing all those other depends, specially the one on libgtk2.0-0. Nothing linking with libgconf2-4 will stop working when these dependencies aren't installed. Some optional functionality will, but it is not part of the functionality packages using libgconf2-4 actually need. It seems to be: libgtk-x11-2, libgconf-2, libpopt, libgobject-2, libpthread, libglib-2 and libc. So make it only link to those libraries instead. This shouldn't be that hard. You haven't investigated how to do it, have you? And I think that using --as-needed as you did is the wrong way to go. This should be a last resort option in case you really can't fix it some other way. I don't believe --as-needed should be a last resort option. Is dh_fixperms a last resort option when you cannot fix the build system to install files with proper permissions? Even with a fixed build system, you still use dh_fixperms, just to be sure. The same goes for --as-needed. As for relibtoolizing, it is currently not possible to relibtoolize all GNOME packages, because of a lack of manpower. If you want to see them relibtoolized, you'd better get libtool upstream to accept the Debian patches. Even with relibtoolized packages, the problem remains, because of pkg-config. As GNOME headers have a spurious tendency to include headers from most of their dependencies, it isn't possible to move them to private dependencies. Regards, -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
Re: Need for launchpad
On Mon, Jan 09, 2006 at 01:28:00AM +0100, Wouter Verhelst wrote: On Sun, Jan 08, 2006 at 11:25:28AM +0100, Stephan Hermann wrote: Everything what is on https://wiki.launchpad.canonical.com/ is free to use. Read and think again. Or use another example: Amazons code is not free to see, but you can use the interfaces described in their developers documents, same applies to google api. This point is moot unless you can point me to the launchpad public API. Which, AFAIK, does not exist. Today there are at least two public APIs to Launchpad, the gpg-authenticated email interface to Malone (https://wiki.launchpad.canonical.com/MaloneEmailInterface) and the RDF export facility (https://launchpad.net/rdf). Some others have been specified but not yet implemented, e.g. some XML-RPC APIs defined here: https://wiki.launchpad.canonical.com/?action=fullsearchcontext=180value=xml-rpcfullsearch=Text People in glass houses, and all that. Last time I got a serve from someone on an Ubuntu channel, I raised the issue of the Code of Conduct and got told so what?. I don't know if this guy who said that, ever signed the code of conduct, well I signed it, and I try to stick with it as hard as I can. Ok, nobody can take my sort of irony or sarcasm away. I'm sorry for that. Nobody here signed the CoC of the Debian lists. Go away. They were both referring to the Ubuntu Code of Conduct[1], which is digitally signed by members of the Ubuntu community as an acknowledgement of its terms, not the code of conduct for Debian mailing lists[2]. [1] http://www.ubuntulinux.org/community/conduct [2] http://www.debian.org/MailingLists/#codeofconduct -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies, stage 3
On Mon, 9 Jan 2006, Bill Allombert wrote: Andreas Tille [EMAIL PROTECTED] wordnet wordnet-base A new version of WordNet was uploaded just yesterday to experimental. It also solves this issue but there is something wrong with the dict-wn: http://lists.debian.org/debian-devel/2006/01/msg00417.html Once this is solved the circular dependency issue will be solved in Etch. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Canonical's business model
Andrew Suffield [EMAIL PROTECTED] writes: On Sun, Jan 08, 2006 at 10:30:07PM -0800, Russ Allbery wrote: They're investing in writing better tools, and they're keeping them private so as to maintain a competative advantage with them over Red Hat, SuSE, Fedora, and so forth. Including Debian, for that matter. ...damnit, I never thought of that. And you know why not? Because on some level I thought that all the noise they make about 'contributing back to Debian' was more than just lip service. I had (stupidly) wanted to believe that it wasn't *just* their PR machine at work. I think that more than one thing can be going on at once. There are commercial companies that keep things secret for competative advantage and *also* contribute other things back to the broader community. IBM, for instance, to take a prominant example. I don't believe that all of the rhetoric around Canonical is bogus; I think much of it is entirely true. However, they're also a company. Companies, no matter how generous the founder and no matter how strong the ideals, still do behave in certain ways. Sometimes that's delayed, and often they continue to work with a community while still finding other ways to make a profit, but the decisions at some point do become economic. This isn't necessarily a bad thing. It's just a splash of reality. It's not infrequent these days for a company to form around a free software project, and often the result is a burst of resources and significant improvements. But through that period, it's also important to maintain sight of why the free software project is bigger than any company that might form out of it, and to be constantly planning for the day when the company will go away, become hostile, stop giving back, or otherwise take its balls and go home. Since this almost *always* happens sooner or later. I'm not ideological about how other people work. If people want to work for a commercial company or not release their work or what have you, more power to them. I hope they make lots of money and live a wonderful life with lots of interesting things to play with. However, from the perspective of building a free infrastructure, the only work done by companies that matters in the long run is the work they release to the world. Everything else is just something more that will have to be rewritten or reinvented later by someone else until finally it's released as part of the commons. It's their work to waste (and from their perspective it may not be a waste -- putting food on the table of employees is also a useful activity, even if it's not the activity that I personally care to help), and I'm not going to fight with them about it, but neither am I going to pour my time and resources into helping with their business model unless it also benefits the information commons that I'm trying to expand and improve. As such, I think getting upset at them is fundamentally missing the point. Companies act like companies, sooner or later. Companies are fundamentally economic. I don't mind them buying goodwill -- the only actions a company *can* take, at a fundamental level, are buying and selling. However, I'm always going to expect a company to take whatever actions lead to the most return on their investment. If that's helping Debian, they'll help Debian. If at some point helping Debian is no longer good for the bottom line, they'll stop helping Debian. Because of that, they're fundamentally unpredictable in a way that a personal relationship is not, and I'm not going to rely on them and I don't want to see any infrastructure beholden to them. I agree with David; the best approach is to try to build personal relationships with the people doing the work, and insofar as their job at Canonical lets them do work that Debian can benefit from, to take advantage of those additional resources and not worry about looking gift horses in the mouth. As long as we don't become *dependent* on the actions of a company, we can certainly accept and use contributions that a company is willing to pay for, with good grace and expressed gratitude. For example, personally I really appreciate the Ubuntu patch archives. For me personally, it's been useful and helpful. If you're right, then it would mean that their concept of 'contributing back' means to purchase 'goodwill' at the lowest available price - which would be consistent with the behaviour we've seen from them so far. In effect, treating it as another asset, and behaving like a classical company that focusses on the bottom line. So that's actually plausible. It's also important to not completely conflate the people who work for Canonical with the actions of Canonical the company. Many people who work for companies contribute to free software as part of their job, as a hobby, or in that grey area of their days that's partly work and partly their own time. Many of free software's most valuable contributors have done this. -- Russ
Re: bits from the release team
On Tue, Jan 03, 2006 at 06:43:28PM -0500, Brian Nelson wrote: [EMAIL PROTECTED] (Marco d'Itri) writes: On Jan 04, Adam Heath [EMAIL PROTECTED] wrote: Not to mention that 2.6.15 requires a newer udev. Who knows what other newer things newer kernels might require. OTOH, old kernel are buggy and out of date wrt modern hardware, and we lack the manpower to backport for years fixes and new features RHEL-style. Do you have a better solution? Why don't we use RHEL's kernel, or collaborate with them to maintain a stable kernel tree, or something? or http://members.optusnet.com.au/ckolivas/kernel/ -- Chris. == Reproduction if desired may be handled locally. -- rfc3 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: lintian problem [shared-lib-without-dependency-information]
Székelyi Szabolcs [EMAIL PROTECTED] writes:
I'm trying to make my first package... Everything goes fine except one
thing. Lintian says:
W: libvrb0: shared-lib-without-dependency-information
./usr/lib/libvrb.so.0.4.0
I understand what this means, know how to fix it (by adding -lc to ld
arguments). Unfortunately the upstream source uses some strange
(non-auto{make,conf}) build system, meaning (among other things) that
the arguments of ld are hard-coded into the configure script.
You really shouldn't have to add -lc to the ld arguments; that indicates
that upstream is doing something very odd.
Solutions may be:
* modifying the configure script
* manually adding libc to 'Depends:' line
* overriding the warning
Which one sould I choose? Any other idea?
The upstream source is available from http://vrb.slashusr.org/
Upstream is explicitly writing out a Makefile that links the library with
-nostdlib -nostartfiles, despite the fact that the library calls libc
functions. This is broken. I'm not sure about the -nostartfiles,
although that seems very suspicious, but -nostdlib is simply wrong and
should be removed so far as I can tell.
You may want to ask upstream why they did that, but I'd patch Configure to
remove -nostdlib in the maketop function that writes out the Makefile.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Bug#347267: ITP: iec16022 -- GPL licensed program to generate datamatrix/semacode 2d barcodes
Package: wnpp Severity: wishlist Owner: Jan Luebbe [EMAIL PROTECTED] * Package name: iec16022 Version : 0.1 Upstream Author : Stefan Schmidt [EMAIL PROTECTED] * URL : http://www.datenfreihafen.org/projects/iec16022.html * License : GPL Description : iec16022 is a program to generate datamatrix/semacode 2d barcodes The program generates a 2d datamatrix/semacode barcode from a parameter or from a file and produces output in various formats (png, eps, ascii-art). http://www.semapedia.org/ for example uses semacode tags to create real-world links to wikipedia articles. The code was originally written by Andrews Arnold Ltd and placed under the GPL (see http://aa.gg/free/). The statement on the website is somewhat ambigous, but Stefan Schmit contacted the original author and obtained explicit authorization to continue development under the GPL. He has since taken over the development. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.4.20-021stab028.18.777-smp Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#346528: ITP: gnome-clipboard-daemon -- keeps the content of your X clipboard in memory so the clipboard won't get lost even after you close the application you copied from
On Sun, Jan 08, 2006, Joe Wreschnig wrote: You probably also meant 'Debian GNOME Maintainers [EMAIL PROTECTED]'. preferably: [EMAIL PROTECTED]; pkg-gnome-maints is more of a bug subscription list. -- Loïc Minier [EMAIL PROTECTED] Current Earth status: NOT DESTROYED -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packet radio and foul language
Benjamin Seidenberg wrote: Yes, the FCC. See part 97 of the FCC rules (US CFR Title 47), specifically § 97.113(1) [0] Err, sorry, I meant § 97.113(a)(4). Also, my previous message applies to amateur operators in the US. Amateurs in other nations are similiary regulated by their equivelent to the FCC, with similar rules which are all based on ITU regulations. signature.asc Description: OpenPGP digital signature
Re: Getting rid of circular dependencies, stage 3
On Mon, Jan 09, 2006 at 07:20:46PM +0100, Bill Allombert wrote: Debian Xfce Maintainers [EMAIL PROTECTED] xfce4-mixer xfce4-mixer-alsa xfce4-mixer-oss Can you remind me why circular dependencies are so terrible? These packages install fine and upgraded fine. What did we miss? -- Simon Huggins \ If at first you don't succeed, you'll get lots of advice. \ http://www.earth.li/~huggie/htag.pl 0.0.22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Any volunteers for ploticus in Debian?
Hi, Does anyone want to adopt/help with the ploticus packages in Debian? The maintainer, James Penny, is more or less MIA in that he doesn't have time for Debian work at the moment and hasn't for a while which you can see from say the bugs page. It seems sad that upstream have incorporated ideas from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=284080 in February 2005 and then it didn't make sarge and hasn't seemingly been touched since. My only interest in it is that a user of a shell box I admin wanted it. Having investigated upstream it looks like a neat piece of software so it really does seem like a shame that noone would pick this up. jpenny writes: I am, most ashamedly, MIA. I will be trying to resolve this, but it looks like another month before I can consider becoming active again. I am certainly willing to give ploticus up. No one has volunteered. So if you want it, or you can find a volunteer, please do so. Otherwise I will try to get current packaging out by Feb 28. Note: the ploticus package itself is not very challenging. However, the documentation is difficult to package. In the past it has required tools not in debian to build, and it has tons of references to features that could not be put in the debian version -- either due to patent issues or depending on removed libraries. Go on, you know you want to. Simon. -- UK based domain, email and web hosting ***/ If a tree fell on a /* http://www.blackcatnetworks.co.uk/ **/ florist, would he make a /** [EMAIL PROTECTED] */ sound? /*** Black Cat Networks / / -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: poppler
On Mon, Jan 09, 2006 at 05:00:53PM +0100, Isaac Clerencia wrote: On Monday, 9 January 2006 15:03, Moritz Muehlenhoff wrote: Unfortunately kpdf upstream seems quite reluctant to switch to poppler, see http://bugs.kde.org/show_bug.cgi?id=119455. I don't know the status of koffice. Hi. From an hour ago: #kpdf: 16:22 isaac uhm, refresh my memory 16:22 isaac will kpdf ever use poppler? 16:22 isaac will it be replaced by okular? 16:24 tsdgeos maybe 16:24 tsdgeos maybe 16:24 Niedakh well if poppler's development process becomes more open Also from that KDE bug report: It would be nice to see that KDE and GNOME developers really could work together. ;-) It would be even better to see the poppler people working with Xpdf's upstream. It's good that not all these packages will have statically-linked copies of xpdf code now. It would be even better if poppler wasn't a fork of Xpdf though. Already poppler is behind on a lot of bug fixes from Xpdf 3.01. I imagine most have been merged by now, but there's a lot of duplicate effort involved. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gconf transition
On Mon, 2006-01-09 at 19:50 +0100, Isaac Clerencia wrote: On Monday, 9 January 2006 19:26, Ron Johnson wrote: The gconf-sanity-check functionality is optional. As such, its Why is gconf-sanity-check optional? It seems pretty vital to me. AFAIK only gdm (or gnome-settings-daemon) uses gconf-sanity-check and both depend on libgtk2.0-0. So gconf-sanity-check should be in gconf, and gnome-settings-daemon should depend on gconf? ISTM that since gconf is so vital to GNOME, a sanity checker is vital to be able to fix corruptions. -- - Ron Johnson, Jr. Jefferson, LA USA When you see a rattlesnake poised to strike, you do not wait until he has struck before you crush him. Franklin D. Roosevelt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Any volunteers for ploticus in Debian?
* Simon Huggins ([EMAIL PROTECTED]) wrote: Does anyone want to adopt/help with the ploticus packages in Debian? I'm only slightly better than MIA (and some might dispute even that), but I'd really like to see ploticus in Debian updated/improved. I don't use it much myself but it's one of the packages we considered doing some of our web graphs in and I think is certainly something we'll probably use in the future. I can try and help. Thanks, Stephen signature.asc Description: Digital signature
Re: Getting rid of circular dependencies, stage 3
ma, 2006-01-09 kello 21:15 +, Simon Huggins kirjoitti: On Mon, Jan 09, 2006 at 07:20:46PM +0100, Bill Allombert wrote: Debian Xfce Maintainers [EMAIL PROTECTED] xfce4-mixer xfce4-mixer-alsa xfce4-mixer-oss Can you remind me why circular dependencies are so terrible? These packages install fine and upgraded fine. What did we miss? One things, if I've understood things correctly, is that it is not possible to reliably know how they're going to be removed -- dpkg will break the circle in a random place and this may or may not result in problems at the removal stage, depending on what the package does when being removed in various scenarios. Without circular dependencies, things are simpler and easier, since things happen in more deterministic ways. I don't know if that is sufficient reason to get rid of circular dependencies. -- On IRC, we sometimes like to watch silence. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Need for launchpad
On Sun, Jan 08, 2006 at 11:17:10AM -0800, Russ Allbery wrote: Stephan Hermann [EMAIL PROTECTED] writes: Well, we can't change the world totally, but avoiding a tool, because it's free, but non-free source, it's more a joke then anything else, because I had to avoid many of the services I need in my daily developers world. And this belief, in a nutshell, is the reason why I'm a Debian developer and, while I might use Ubuntu in a situation where it looks like a good distribution, I have no interest in contributing to it except insofar as Ubuntu, and anyone else, is welcome to reuse my contributions to Debian. Do you mean to say that you have been discouraged from contributing to Ubuntu because the Launchpad source code is not available to you? If so, I find this confusing, given that Ubuntu was released and active long before any of the Launchpad infrastructure, and one can contribute to Ubuntu even today (and many do) without interacting with Launchpad at all. I don't use Launchpad very much yet myself, though I expect that to change as some of the more exciting components mature. The response to this thread has been predictable, given the wording of the original post and the strong opinions that free software developers often hold regarding their toolset. A similar argument would surely ensue if someone proposed that all Debian developers use Subversion for source code management, for example. Manoj's analogy with human language, while dripping with sarcasm, is apt. The reality of the situation is much less controversial. If a Debian maintainer finds it useful to manage their translations in Rosetta, then they can do that today, as a matter of individual choice. If they or a future maintainer of the same package prefers to manage the translations by hand, they can do that, and never touch Rosetta. Launchpad is a collection of tools intended to promote more efficient collaboration on the development of free software, and if it is to succeed, it will be because individuals choose to use it, not because any organization requires that they do so. As for licensing, some code has already been released as open source, and Canonical has made commitments to do more of the same in the future. Anyone with specific questions about Launchpad is welcome to ask them on the Launchpad mailing list if they want authoritative answers: http://lists.ubuntu.com/mailman/listinfo/launchpad -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Canonical's business model
On 09-Jan-06, 13:52 (CST), Russ Allbery [EMAIL PROTECTED] wrote: I think that more than one thing can be going on at once. There are commercial companies that keep things secret for competative advantage and *also* contribute other things back to the broader community. IBM, for instance, to take a prominant example. I don't believe that all of the rhetoric around Canonical is bogus; I think much of it is entirely true. [etc.] Russ, if you continue to post reasonable analysis and commentary to debian-flame^Wdevel, instead of adopting one of two extremes available for a given war^Wdiscussion, you will be asked to leave. Steve, hoping the smiley (and appreciation) is obvious. -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Need for launchpad
Il giorno lun, 09/01/2006 alle 15.09 -0800, Matt Zimmerman ha scritto: The reality of the situation is much less controversial. If a Debian maintainer finds it useful to manage their translations in Rosetta, then they can do that today, as a matter of individual choice. If they or a future maintainer of the same package prefers to manage the translations by hand, they can do that, and never touch Rosetta. Launchpad is a collection of tools intended to promote more efficient collaboration on the development of free software, and if it is to succeed, it will be because individuals choose to use it, not because any organization requires that they do so. What really I don't understand is how a proprietary tool can promote more efficient collaboration on the development of _free software_. Sounds like an ossimoron to me. federico -- Federico Di Gregorio http://people.initd.org/fog Debian GNU/Linux Developer[EMAIL PROTECTED] INIT.D Developer [EMAIL PROTECTED] We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.-- D.E.Knuth signature.asc Description: Questa parte del messaggio è firmata
Re: Need for launchpad
Matt Zimmerman [EMAIL PROTECTED] writes: Do you mean to say that you have been discouraged from contributing to Ubuntu because the Launchpad source code is not available to you? It's far broader than just Launchpad. I am discouraged from contributing to Ubuntu because Ubuntu is not *fully* committed to free software, by which I mean building the entire infrastructure on free software and making available all tools, or at least as much as practically possible, as free software. Debian isn't perfect at this. There are portions of the Debian infrastructure where the exact version that Debian is running are not necessarily available. However, these are generally considered within the project to be anomolies and Debian *does* have a general committment to free software for its infrastructure. I'm not at all surprised that Ubuntu is drifting into closed-source software, as this is a standard development path for a company based around free software. I'm not upset. I'm simply not interested, and consider that path to be entirely predictable. The response to this thread has been predictable, given the wording of the original post and the strong opinions that free software developers often hold regarding their toolset. A similar argument would surely ensue if someone proposed that all Debian developers use Subversion for source code management, for example. Manoj's analogy with human language, while dripping with sarcasm, is apt. The whole web-based bit is mostly uninteresting to me. There are various ways of wrapping a command-line interface around a properly designed web service, such as SOAP or XML-RPC. The problem I have is that Launchpad isn't free. As such, it immediately becomes irrelevant to me as far as Debian infrastructure is concerned. Please note that I'm not picking on Ubuntu. I had this exact same discussion (even including hurt feelings and unnecessary drama) with the buildd.net folks just a few weeks ago. As for licensing, some code has already been released as open source, and Canonical has made commitments to do more of the same in the future. This is great, and I for one greatly appreciate any and all contributions that Canonical makes back to the broader community. For so long as Canonical doesn't contribute *everything* (or at least nearly so; see the above caveat) back to the broader community, I'm uninterested in working *directly* on Canonical's distribution, but I'm certainly interested in helping Canonical in return for Canonical's contributions to the general community. In other words, my unwillingness to work *directly* on a distribution that is backed even in part by a non-free infrastructure should not be taken to imply that I'm unwilling to even cooperate with the people who are working on it. I'm quite happy to have my work for Debian used in Ubuntu, and I'm quite happy to fix bugs, accept patches, and minimize divergence even if it doesn't affect Debian directly (see Bug#342607 for a trivial instance, where I also did the work of getting the patch and approved upstream). You just won't see me become an Ubuntu developer unless Ubuntu as a whole is committed to free software from the ground up. And certainly, I would oppose blessing any closed-source toolset as part of Debian's infrastructure, regardless of its origins. Which is where I entered this particular thread. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies, stage 3
On Tue, Jan 10, 2006 at 01:17:38AM +0200, Lars Wirzenius wrote: One things, if I've understood things correctly, is that it is not possible to reliably know how they're going to be removed -- dpkg will break the circle in a random place and this may or may not result in the problems occur when apt processes long lists of packages, and more specifically in the 'configure' stage. dpkg has only partly to do with this; the problem is in APT and the way it controls dpkg: due to a limited command line length, apt can only call dpkg with a certain number of packages on the same time. dpkg can handle circular dependencies fine as long as both 'ends' are fed in at the same time. but, at least the last time I checked the apt source, apt doesn't check for this condition when splitting the to-be-configured list and passing these chunks to dpkg. the last hack made by the apt people was to increase the length of these chunks (which decreases the probability of the bugs invokation). well, now people may say: who ever feeds so many packages into apt at the same time? - answer: try an 'apt-get dist-upgrade' from woody to sarge... I don't know if that is sufficient reason to get rid of circular dependencies. well, everything that makes package management tasks _interactive_ is a major showstopper for use in bigger installations (hpc clusters, enterprise desktops). ok. 'nuff ranted. -- c u henning signature.asc Description: Digital signature
Re: Need for launchpad
On Tue, Jan 10, 2006 at 12:32:32AM +0100, Federico Di Gregorio wrote: Il giorno lun, 09/01/2006 alle 15.09 -0800, Matt Zimmerman ha scritto: The reality of the situation is much less controversial. If a Debian maintainer finds it useful to manage their translations in Rosetta, then they can do that today, as a matter of individual choice. If they or a future maintainer of the same package prefers to manage the translations by hand, they can do that, and never touch Rosetta. Launchpad is a collection of tools intended to promote more efficient collaboration on the development of free software, and if it is to succeed, it will be because individuals choose to use it, not because any organization requires that they do so. What really I don't understand is how a proprietary tool can promote more efficient collaboration on the development of _free software_. Sounds like an ossimoron to me. Why? There are countless examples, past and present. Proprietary development tools, virtualization tools, even entire operating systems have all been used to accelerate the pace of free software development, both directly and indirectly. While some free software developers adopt a philosophy of avoiding the use of proprietary software where possible, that is a matter of personal preference, and different developers adopt different strategies. This is not only understandable, but possible and indeed commonplace. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How the kernel firmware loader works
On Sat, Jan 07, 2006 at 12:05:48AM +0100, Marco d'Itri wrote: (#104) How the kernel firmware loader works fEnIo[0] learnt an important lesson about the kernel firmware loader: it (usually) does not work as expected for non-modular drivers. Yeah... thanks a lot for your explanation. I'm now a little smarter. The reason is that the request_firmware()[1] interface is synchronous. Since it's usually called in the initialisation section of drivers, the userspace firmware loader is not available yet if the calling driver is built-in in the kernel. The request_firmware_nowait()[2] asynchronous interface was designed to replace it, but most drivers have not been ported yet. When a driver calls request_firmware(), a uevent[3] is sent by the kernel to udev over a netlink(7) socket, requesting that a specific file is uploaded. udevd runs /lib/udev/firmware.agent, a simple shell script which will look for the $FIRMWARE file in a few directories and then copy it to the designated place in the driver $DEVPATH in sysfs. If the driver is initialised before userspace is started then the loader will not be available, and the request will fail. A possible solution is to run udev in the early userspace environment (initramfs), but just compiling the driver as a module is usually simpler. So I suppose that it shouldn't be possible to compile in such drivers, if they work only as a module. At least since they aren't ported to new interface. Anyway, once again thanks for explanation, and now I'm glad that I posted this question in blog, otherwise I would probably lost more time to figure out what's going on. regards fEnIo -- ,''`. Bartosz Fenski | mailto:[EMAIL PROTECTED] | pgp:0x13fefc40 | irc:fEnIo : :' : 32-050 Skawina - Glowackiego 3/15 - w. malopolskie - Poland `. `' phone:+48602383548 | proud Debian maintainer and user `- http://skawina.eu.org | jid:[EMAIL PROTECTED] | rlu:172001 signature.asc Description: Digital signature
Re: Canonical's business model
On Mon, Jan 09, 2006 at 11:52:43AM -0800, Russ Allbery wrote: As such, I think getting upset at them is fundamentally missing the point. Companies act like companies, sooner or later. Companies are fundamentally economic. I don't mind them buying goodwill -- the only actions a company *can* take, at a fundamental level, are buying and selling. However, I'm always going to expect a company to take whatever actions lead to the most return on their investment. If that's helping Debian, they'll help Debian. If at some point helping Debian is no longer good for the bottom line, they'll stop helping Debian. Because of that, they're fundamentally unpredictable in a way that a personal relationship is not, and I'm not going to rely on them and I don't want to see any infrastructure beholden to them. I agree with most of what you've said, except for the assertion that individual people are fundamentally different in this respect. Debian developers, in general, work on Debian in their spare time, and make their living by other means. Often these pursuits come into conflict, being in competition for the same resources (primarily time), as many of us know all too well. If a developer's continued economic well-being requires that they reduce their free software workload, they generally do so. On the other hand, if they find a way to involve free software development in their for-profit activities, this allows them to contribute more than they might otherwise be able to. These are both considered normal and reasonable occurrences. The fact that for-profit companies need to create economic justification for free software contributions doesn't mean that they can't be valuable contributors. A huge volume of such contributions have come from profit-motivated initiatives, both at the individual and organizational level. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Need for launchpad
Federico Di Gregorio [EMAIL PROTECTED] wrote: What really I don't understand is how a proprietary tool can promote more efficient collaboration on the development of _free software_. Sounds like an ossimoron to me. I think it's hard to argue against the fact that Sourceforge has encouraged a great deal of collaboration on free software, despite now not being entirely open. (It's probably also hard to argue against the fact that Sourceforge has discouraged a great deal of collaboration, what with their inability to do things like run a stable CVS service. Thanks, Sourceforge) -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies, stage 3
On Tue, Jan 10, 2006 at 12:43:19AM +0100, Henning Glawe wrote: On Tue, Jan 10, 2006 at 01:17:38AM +0200, Lars Wirzenius wrote: One things, if I've understood things correctly, is that it is not possible to reliably know how they're going to be removed -- dpkg will break the circle in a random place and this may or may not result in the problems occur when apt processes long lists of packages, and more specifically in the 'configure' stage. dpkg has only partly to do with this; the problem is in APT and the way it controls dpkg: due to a limited command line length, apt can only call dpkg with a certain number of packages on the same time. dpkg can handle circular dependencies fine as long as both 'ends' are fed in at the same time. but, at least the last time I checked the apt source, apt doesn't check for this condition when splitting the to-be-configured list and passing these chunks to dpkg. Shouldn't apt be fixed rather than changing other packages, then? Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#347309: ITP: libtime-piece-mysql-perl -- Time::Piece::MySQL - Adds MySQL-specific methods to Time::Piece
Package: wnpp Severity: wishlist Owner: Ben Hutchings [EMAIL PROTECTED] * Package name: libtime-piece-mysql-perl Version : 0.05 Upstream Author : Marty Pauley [EMAIL PROTECTED] * URL : http://search.cpan.org/~kasei/Time-Piece-MySQL/ * License : dual Artistic/GPL Description : Time::Piece::MySQL - Adds MySQL-specific methods to Time::Piece Using this module instead of, or in addition to, Time::Piece adds a few MySQL-specific date-time methods to Time::Piece objects. This is a dependency of libclass-dbi-mysql-perl (see #321938). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Canonical's business model
Matt Zimmerman [EMAIL PROTECTED] writes: I agree with most of what you've said, except for the assertion that individual people are fundamentally different in this respect. Debian developers, in general, work on Debian in their spare time, and make their living by other means. Often these pursuits come into conflict, being in competition for the same resources (primarily time), as many of us know all too well. Hm, yes, that's a good point. I still feel like it's a bit different, in that at the level of individuals, it tends to be a different in quantity of contribution rather than time and one gets more warning and in ways that are easier to deal with, but this isn't *always* the case. The fact that for-profit companies need to create economic justification for free software contributions doesn't mean that they can't be valuable contributors. A huge volume of such contributions have come from profit-motivated initiatives, both at the individual and organizational level. Oh, absolutely. Definitely agreed. I think it's fantastic when people get to work on free software as part of their job, and those people are a huge resource for free software. There are inherent limits to how much one can do this as a hobby, and someone who's paid to work full-time on free software can simply do quite a bit more than someone who has to do it as a hobby and balance it against getting paid. Finding good ways of taking advantage of the work of people who are paid to work on free software is very important for any free software project, including Debian. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: apt-torrent (WAS: Re: apt PARALLELISM)
On Mon, 9 Jan 2006, Arnaud Kyheng wrote: Hello all and Happy New Year, Thanks to George, apt-torrent has been mentioned in the Debian Devel list :o) I've just noticed it, and the fun part of this discovery, is that I also found why my ISP has closed sianka.free.fr: Too much hits since the latest Debian Weekly News, and the new apt-torrent 0.3.1-1 package ! I apologize, but, victim of its success, the apt-torrent homepage is down, and so is, its repository. It'll take me some time to find a new, and more appropriate home for apt-torrent. What stats are needed? Brainfood is offering. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gconf transition
On Mon, Jan 09, 2006 at 04:42:05PM +0100, Tollef Fog Heen wrote: * Josselin Mouette | Le lundi 09 janvier 2006 à 14:41 +0100, Tollef Fog Heen a écrit : | | Ladies and gentlemen, this is a perfect example of why linking indirect | | dependencies is a very bad thing. Let me explain. | | No, it's not. At least not in the way GTK friends work. | Why so? Because GTK exports and depends on the definitions of GLib (and pango, in this case) types, so if any of those definitions change, you must get the right ones. How can those definitions change without changing the ABI of GTK itself? If the ABI of GTK changes, so must the soname. I don't see a problem here. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Canonical's business model
Canonical's business model doesn't belong in -devel. If Canonical as a company is being fair, cool, whatever with Debian project i think we can discuss it in -project, but why not do the same exercise about Linspire? Do they sponsor conferences? Oh, i think Canonical does it too. It's up to Canonical how they will contribute back to the community, IMHO. I don't the same rant over others Debian related companies so i'm assuming that we're wasting time shooting Canonical, (mainly) because Ubuntu is sucessful. I did a different opinion a month ago, but the fact is that i tried to start a collaborative dicussion two times with Canonical employees and it's going well. I recommend you do the same, and discuss in -project what we (as a project) need from Canonical: free tools, better formatted patches, whatever, ... I don't think they will waste time and money thinking about it for us. It's going to far, after all some people here and there are just criticizing old time friends before asking them if they can share resources and workload for the better of both projects. -- Gustavo Franco
Re: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=265920
i've thought for a long time about how to reply to your message. which, now that i re-read it, i notice that it is extremely patronising, and all possible thought of being nice and non-confrontational goes out the ing window. given that you are happy to write patronising messages, i am not therefore too surprised at your statement. i therefore invite you to accept reality. the reality is: there are too many people using debian who have found reportbug and use it for you to whine about how the world does not revolve around debian. the mozilla team accept the reality that bugs are going to come in from several sources. why the can't you? get with it, get off your damn high horse, and accept that intelligent and stupid people alike are going to report bugs - not to suit _your_ whims but because the reporting method is _there_ and they haven't been told any different. if you _want_ people to stop using the debian system, then here are your options, in no particular order: 1) write a program to sabotage bugs.debian.org or a subsection of it. 2) write a program that slurps bugs of certain debian package names and duplicates the contents in the kde bugs. 3) write a program that monitors the bugs of certain debian package names and sends a message to each notifying them of your fucking dipshit disposition that this bug will be totally ignored because i am so up my own arse i cannot be bothered to read it unless you post it on _my_ system. 4) put in a bugreport against the debian reportbug package about this entire issue you find so objectionable 5) write a patch to reportbug to have an exclusionary list or an advisory / warning saying that the debian bug reporting for any kde package is _specifically_ for reporting debian packaging problems _not_ for reporting bugs on kde, and plasse pretty please could you go go _ourr_ nice bug-reporting system 6) stick your head in a bucket of cold water and CHILL OUT (i'll be doing likewise in a couple of minutes, just as i get to about no 8 or so on this list of suggestions) 7) develop an RSS/XML-lovely-intercommuney-system of bug-communicationey-stuff protocol thing that allows free software bugs to be pushed across to different interoperable systems. i strongly advise you to consider looking up AS/2 which is an RFC on how to communicate XML documents and also to have a digitally signed receipt indicating acceptance of the transfer. perhaps that's a bit overkill, but worth considering. the basic principle: allow bugs to be searched across multiple systems (not just your own system); allow a bug to be transferred by the thingies. bug maintainer people. for them with one easy push-of-a-browser-button say here. _you_ deal with it. ahh, why didnt' _you_ think of some of these ideas, instead of just bitching about how debian and its users are so XXX XX we interrupt this email to bring you some light refridgerator i mean elevator music. ahh, i feel better now. calm, calm. i am at oe with the universe. i am bleeeded in. On Wed, Dec 07, 2005 at 04:06:54AM +0100, Dirk Mueller wrote: On Tuesday 06 December 2005 02:52, Luke Kenneth Casson Leighton wrote: was the issue mentioned in this report ever resolved? I'm not sure why I have to state the obvious, but the world does not rotate around Debian, and unless you report the bug at an upstream place where the actual maintainer can read about it, its unlikely that bugs get fixed in a magically automated way. -- Dirk//\ -- -- a href=http://lkcl.net;http://lkcl.net/a -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Heimdal and openssh
Juha Jäykkä [EMAIL PROTECTED] writes: * Interoperate with ssh-krb5 3.8.1p1-1 servers, which used a slightly different version of the gssapi authentication method (thanks, Aaron M. Ucko; closes: #328388). Perhaps this is THE patch which makes them all work together while openssh folks claim they don't? This is a side-issue, but it would be nice to know. That may very well be the case, yeah. I've not done a lot of experimentation. Ahem... my krb5.conf says permitted_enctypes = aes256-cts-hmac-sha1-96 (in libdefaults). So this is the culprit here? [Please, do not patronize me on using a non-recommended config. =) It's simply that I think DES has no security to speak of these days. 3DES might be worth trying, though.] In further discussion, this turned out to be the problem that started all the attempts at rebuilding things (in case anyone else happens upon this thread). The versions of everything in sarge aren't set up to support 256-bit AES as the only supported enctype, but this will probably work in etch. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: hppa dependency problems on build of pdns
On Mon, Jan 09, 2006 at 02:37:53PM +0100, Frank Küster wrote: Matthijs Mohlmann [EMAIL PROTECTED] wrote: I don't know where to send this else, so forgive me if this is the wrong mailinglist. See: http://buildd.debian.org/fetch.php?pkg=pdnsver=2.9.19-2arch=hppastamp=1135294848file=logas=raw [..] [...] As you can see, tetex-base depends on tex-common (= 0.12). But the hppa build daemon doesn't install tex-common. So can somebody tell me what's going on here ? The same happened to the planner package, and has been reported as #344538. It seems that hppa buildd is broken, don't know yet whether the buildd admin (Lamont) or anybody of the debian-admin (responsible for the hardware) is at it. Hasn't the problem on the hppa buildd been fixed for a while? The pdns package (both versions 2.9.19-2 and 2.9.19-3) has built fine on that arch now. If the buildd wasn't installing a package that was part of the dependencies, then it surely thought for some reason it was already installed. If this wasn't actually the case, it points to a buildd problem or a bug in some maintainer script or other; either way, it seems to be corrected now. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Packet radio and foul language
Benjamin Seidenberg [EMAIL PROTECTED] writes: Err, sorry, I meant § 97.113(a)(4). Also, my previous message applies to amateur operators in the US. Amateurs in other nations are similiary regulated by their equivelent to the FCC, with similar rules which are all based on ITU regulations. So what's the likelihood that this is actually a problem? 0.1%? 0.001%? And by what bizarre standard is saying foo sucks really profane??? Ok, by the wackos like ed meese standard maybe -- but nobody cares about that. In the extremely unlikely event that it is a problem, why should it be up to list posters to deal with it? If some readers use a service governed by authorities that are prudish to an absurd degree, it seems like the onus is on them to try and deal with the probably technically; at the least it's up to them to demonstrate that it is a _real_ issue before asking people to modify their behavior based on this. I assume that in truth, you're not really worried about the FCC breaking down your door, but rather don't like the language you see, and are trying to come up with a less subjective reason to object to it. Probably most posters would agree that extreme torrents of abuse are annoying and (usually) out of place, but for many speakers mild profanity is a normal part of informal language; most people understand that (even if they don't like it), and deal with it. -Miles -- Ich bin ein Virus. Mach' mit und kopiere mich in Deine .signature.
Re: Need for launchpad
Federico Di Gregorio [EMAIL PROTECTED] writes: Right. Everybody just think about BitKeeper and the Linux kernel. Now, who still wants to use proprietary tools provided by a company that first or later will need to find a way to make money? Er, I'm no great fan of Ubuntu, and don't use any of their software, but comparing them with the BitKeeper debacle seems a bit extreme. From the beginning, Larry McVoy was practically screaming I will screw you !!! daily on the LKML; the only surprise was that some people managed to not see this for so long. -miles -- Freedom's just another word, for nothing left to lose --Janis Joplin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=265920
Luke Kenneth Casson Leighton [EMAIL PROTECTED] wrote: i've thought for a long time about how to reply to your message. Let's quickly outline what's happened here: 1) Luke files a bug agains Debian. So far, so good. 2) Some time later, Luke contacts a KDE developer and asks if the bug has been fixed. 3) The response is, approximately, This is the first I've heard of it. We (Debian) have a bug tracking system in order to keep track of bugs in our distribution. It's the job of either the bug submitter or (more usually) the Debian maintainer to contact upstream to make sure that they're aware of the bug. It is *not* the upstream maintainer's job to examine Debian's bug database. Which is, uh, pretty much what Dirk said. Luke, what the christ are you upset about? Nobody's said Don't report this bug to us, they've said If you report a bug to Debian and nobody forwards it, we know nothing about it. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packet radio and foul language
Miles Bader wrote: Benjamin Seidenberg [EMAIL PROTECTED] writes: Err, sorry, I meant § 97.113(a)(4). Also, my previous message applies to amateur operators in the US. Amateurs in other nations are similiary regulated by their equivelent to the FCC, with similar rules which are all based on ITU regulations. So what's the likelihood that this is actually a problem? 0.1%? 0.001%? Probably a bit higher (not too much), given that radio waves propagate, and anyone in a large area could see them, but you're right it's very low. However it's also a fact of professionalism. Do you tolerate bugs in your software? What about policy violations in your packages? Even if no one sees them, you still avoid them, because you agreed to the rules, and consider yourself bound to them as a matter of course. And by what bizarre standard is saying foo sucks really profane??? Ok, by the wackos like ed meese standard maybe -- but nobody cares about that. FCC has specific rules about what's obscene, although they're not in part 97. Think George Carlin's Words you can't say on the radio. In the extremely unlikely event that it is a problem, why should it be up to list posters to deal with it? If some readers use a service governed by authorities that are prudish to an absurd degree, it seems like the onus is on them to try and deal with the probably technically; at the least it's up to them to demonstrate that it is a _real_ issue before asking people to modify their behavior based on this. That's a matter for the list managers to decide, and I won't speak on this issue, as I have no opinion. The debian-ham mailing list (of which I am not a part) might however, you could try asking them. Regardless, I think the rules are based on common courtesy; in that one should curb their language on any publicly distributed medium such as this. Think of the 80 year old grandmother rule (Would someone's 80 year old grandmother be offended by what you say?) It's just being polite and courteous to others. This is my interpretation of the listmaster's rules, I'm not taking a position on them, although I will say that I think that people sound more reasoned when they make an arguement with ideas rather than profanity or namecalling. I assume that in truth, you're not really worried about the FCC breaking down your door, but rather don't like the language you see, and are trying to come up with a less subjective reason to object to it. The FCC would actually send a letter of notice, and possibly a fine (which can get quite high, especially if actions are repeated). Anyway, I'm not arguing for or against the rules, just giving some references and explanations to someone who asked them. Probably most posters would agree that extreme torrents of abuse are annoying and (usually) out of place, but for many speakers mild profanity is a normal part of informal language; most people understand that (even if they don't like it), and deal with it. I think this is a reasonable arguement, but I think there are reasonable arguements on both sides. -Miles I just want to add something. I don't know why, but at my high school, which has fairly restrictive internet filters, lists.debian.org is blocked. The strage part is that it's under the catagory Abortion/Abortion Advocacy Groups. This is done by SonicWall, which is a very large provider of filter technologies. Even if it's miscatagorized, one wonders if foul language could cause other filtering groups to block it as obscene. Just food for thought. 73, Benjamin, KI4CXN signature.asc Description: OpenPGP digital signature
Re: Aptitude question
Daniel Burrows [EMAIL PROTECTED] writes: [0] alert readers will note that the caveat if the user waits for a sufficient amount of time has to be added here; however, this is typically much less than one second per solution on my hardware. Er, what _is_ your hardware anyway? Though I love the aptitude interface and functionality, I've noticed that on my home machine (not so fast, but not too bad with average software), normal aptitude operation has been getting more and more slothlike in recent times, to the point where I often just hit ^C to exit after upgrading, instead of waiting ages for all the updating random stuff #11, very slowly... 2% stuff to finish before I can type q -miles -- 1971 pickup truck; will trade for guns -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Powerfulness
Juergen Salk [EMAIL PROTECTED] writes: According to their package descriptions, we seem to have exactly six powerful text editors in Debian. These are elvis, jove, mined, ne, nedit and zed. Emacs, vim and many others do not belong to them. Does that mean these are less powerful than the powerful ones? You're right in general, but there actually seems to be a fairly distinct divide in editors, between simple editors for newbs and not-so-simple but, er, powerful editors -miles -- Run away! Run away! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packet radio and foul language
On Mon, 09 Jan 2006, Benjamin Seidenberg wrote: Miles Bader wrote: So what's the likelihood that this is actually a problem? 0.1%? 0.001%? Probably a bit higher (not too much), given that radio waves propagate, and anyone in a large area could see them, but you're right it's very low. Considering the occasional bits of spam that get shuttled through lists about obtaining engorged members and the various methods of employing them, anyone who is using packet radio has likely fallen afoul of this section on multiple occasions. However it's also a fact of professionalism. It's a facet of your standard of professionalism; it may not be a facet that is shared by anyone (or everyone) else. If specific individuals persist in using language that you feel is innapropriate, confer with them privately about it, then killfile them if they persist. I, for one, am far more interested in the message than the way which the message is conveyed. Don Armstrong -- Miracles had become relative common-places since the advent of entheogens; it now took very unusual circumstances to attract public attention to sightings of supernatural entities. The latest miracle had raised the ante on the supernatural: the Virgin Mary had manifested herself to two children, a dog, and a Public Telepresence Point. -- Bruce Sterling, _Holy Fire_ p228 http://www.donarmstrong.com http://rzlab.ucr.edu signature.asc Description: Digital signature
Re: Getting rid of circular dependencies, stage 3
Bill Allombert wrote: Here the lists of packages involved in circular dependencies listed by maintainers. Joey Hess [EMAIL PROTECTED] debconf debconf-english debconf-i18n These are all necessary, and debconf is an essential package which is not subject to the circular dependency postinst ordering problems afaik. (You also never filed any bugs on these.) uqm uqm-content The bug report for these does not give any concrete reasons why a circular dependency is a problem in this particular case. -- see shy jo, if it's not broken .. signature.asc Description: Digital signature
Re: Getting rid of circular dependencies, stage 3
On Tue, Jan 10, 2006 at 11:42:49AM +1100, Hamish Moffatt wrote: On Tue, Jan 10, 2006 at 12:43:19AM +0100, Henning Glawe wrote: On Tue, Jan 10, 2006 at 01:17:38AM +0200, Lars Wirzenius wrote: One things, if I've understood things correctly, is that it is not possible to reliably know how they're going to be removed -- dpkg will break the circle in a random place and this may or may not result in the problems occur when apt processes long lists of packages, and more specifically in the 'configure' stage. dpkg has only partly to do with this; the problem is in APT and the way it controls dpkg: due to a limited command line length, apt can only call dpkg with a certain number of packages on the same time. dpkg can handle circular dependencies fine as long as both 'ends' are fed in at the same time. but, at least the last time I checked the apt source, apt doesn't check for this condition when splitting the to-be-configured list and passing these chunks to dpkg. Shouldn't apt be fixed rather than changing other packages, then? What does fixed mean here? The behavior of circular dependencies is undefined in policy, and must be so, because two packages cannot (in this universe) each be configured before the other. If you can solve this problem, then it makes sense to talk about fixing apt instead of fixing the packages, but not before then. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#347330: ITP: plotdrop -- A minimal GNOME frontend to GNUPlot
Package: wnpp Severity: wishlist Owner: Jordan Mantha [EMAIL PROTECTED] * Package name: plotdrop Version : 0.5 Upstream Author : John Spray [EMAIL PROTECTED] * URL : http://icculus.org/~jcspray/plotdrop/ * License : GPL Description : A minimal GNOME frontend to GNUPlot PlotDrop is designed for quick simple visualisation of 2D data series. It is intended to be used in tandem with an external filesystem browser such as GNOME's nautilus or KDE's konqueror. Files containing data are added by dragging them from the browser to the file list. The homepage for plotdrop is : http://icculus.org/~jcspray/plotdrop/ -- System Information: Debian Release: testing/unstable APT prefers dapper APT policy: (500, 'dapper') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-11-k7 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: APT public key updates?
On Mon, Jan 09, 2006 at 11:43:25AM -0500, Joey Hess wrote: Perhaps expiry isn't exactly what we want -- it's possible we want an archive key that will only verify Release files with a date earlier than a given date; but will continue to do so for an extended period of time. Is possible to implement that using gpg? Not directly afaik. If you say Archive Signing Key (Date = 2006-05-01) apt could parse that from gpgv's output and perform the check itself, or add a The key used to sign these packages expired on 2006-05-01; if you obtained this media after that date, you may have a problem. Continue (y/n): warning. I'm not sure off-hand what gpgv outputs in the case of an expired key; it might be feasible to do the above already. Cheers, aj signature.asc Description: Digital signature
Processed: Fixed in NMU of lrzsz 0.12.21-4.1
Processing commands for [EMAIL PROTECTED]: tag 288084 + fixed Bug#288084: lrzsz: Not prelink-able There were no tags set. Tags added: fixed tag 311459 + fixed Bug#311459: 'man sz' typos: proceding, recption, transmissson, recieve, etc. Tags were: patch Tags added: fixed tag 322762 + fixed Bug#322762: /usr/doc still exists (transition tracking bug) There were no tags set. Tags added: fixed quit Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
