Re: Hardening build flags release goal
Raphael Hertzog wrote: Hi, > No idea, I have only integrated the work others have done in dpkg. I > have not studied how other compilers support the hardening compilation > flags. > > What are the compilers you're thinking of? Here specifically, Clang. More generally, at this point in time, a tool such as dpkg-buildflags cannot ignore the existence of non-gcc compilers. Taking care of that now will save quite some time further down the line. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - Public key available on <http://www.jblache.org> - KeyID: FA1E 5292 GPG Fingerprint : CC1A 2FE4 76FE 444A CD23 A5CD 26E9 8AEA FA1E 5292 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fwkalqvq@sonic.technologeek.org
Re: Hardening build flags release goal
Cyril Brulebois wrote: Hi, > Do we have a proper definition, and sample implementation(s) for “using > dpkg-buildflags properly”? On the top of my hat, it looks like semantics > and recommendations changed a bit over the years, so I kind of lost > count. On top of that, what's the story with regard to non-gcc compilers? JB. -- Julien BLACHE - Debian & GNU/Linux Developer - Public key available on <http://www.jblache.org> - KeyID: FA1E 5292 GPG Fingerprint : CC1A 2FE4 76FE 444A CD23 A5CD 26E9 8AEA FA1E 5292 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k49mls1p@sonic.technologeek.org
Re: glibc: causes segfault in Xorg
"Steve M. Robbins" wrote: Hi, > I'm with Linus on this: let's just revert to the old behaviour. A > tiny amount of clock cycles saved isn't worth the instability. Tiny amount?! The optimized memcpy() variants that break shitty code bring a 4 to 5x speedup on the processors they've been written for! JB. -- Julien BLACHE - Debian & GNU/Linux Developer - Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87d3jyn4gx@sonic.technologeek.org
Re: Disable ZeroConf: how to ?
Tollef Fog Heen wrote: Hi, > Except zeroconf isn't routed so to be able to exploit it you need to be > on the same physical segment? mDNS traffic can actually be relayed, but this requires setting up a relay daemon on the gateway(s). Quite useful when done properly. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87pqq8bgep@sonic.technologeek.org
Re: Disable ZeroConf: how to ?
Bastien ROUCARIES wrote: Hi, > Because I work in a untrusted work place and home network (public > networks, wifi...) I whish to purge zeroconf functionnality. Looks like you want a firewall. Just sayin'. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87pqq9kwd1@sonic.technologeek.org
Re: New libgphoto2 in sid
David Paleino wrote: Hi, > There's a package currently in experimental, and I'm now asking maintainers of > dependant packages (BCCed) to check whether their package compiles and works > fine with it. A dd-list is attached. This would have been most useful with a quick list of what to watch out for. From the changelog of the package currently in experimental, I don't expect any breakage. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87mxlxsfx4@sonic.technologeek.org
Re: Why is help so hard to find?
Mike Bird wrote: Hi, > insserv breaks complex systems. It throws away years of DD work > and substitutes a few inane and inadequate rules. It does so In my experience, insserv makes it a lot easier to handle complex systems with a lot of interdependent daemons and services. Handling the initscripts on those systems with the legacy SysV init scheme was a total pain in the rear. insserv has issues, but it's still an improvement over the previous situation and, unlike the other new init systems, it's actually backward-compatible. What more could you possibly ask for? > And KDE 4 is a well known and very old and very stale joke. Fun > at parties, maybe, but not really appropriate for the workplace. KDE4 is crap, world+dog know that. Use GNOME, XFCE or whatever. If you want KDE3 in Debian, then put your money where your mouth is and come maintain it. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87d3nypjx1@sonic.technologeek.org
Re: For those who care about their packages in Debian
Ben Hutchings wrote: Hi, > Please stop filing ITPs and concentrate on packages that should be > included in squeeze. The sooner squeeze is out, the sooner you can add > stuff to the next release. I'd add: stop uploading new upstream versions to unstable, or actually any revision that isn't needed for Squeeze and won't make it into Squeeze. You're just making everybody else's life harder by doing this. If you can't refrain from uploading, at least upload to experimental until Squeeze is out. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8762yz884y@sonic.technologeek.org
Re: doc-base is hugely unloved; bug mass-filing needed?
Ian Zimmerman wrote: Hi, > How do maintainers feel about that? Right now, frozen, I guess ;) JB. -- Julien BLACHE - Debian & GNU/Linux Developer - Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87iq3m2rp5@sonic.technologeek.org
Re: Problem with gfortran and pkg-config
Alastair McKinstry wrote: Hi, > Which is wrong, gfortran not reading /usr/include by default, or > pkg-config for > removing /usr/include from CFLAGS ? I'll add to the above: - netcdf-dev for installing netcdf.mod in the wrong place? Is there a standard place for .mod files? JB. -- Julien BLACHE - Debian & GNU/Linux Developer - Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ocdqe1xc@sonic.technologeek.org
Re: Moving ACL utilities to /bin?
Bastian Blank wrote: Hi, >> This makes it impossible to use them during the early boot sequence >> before /usr is mounted, so they're unusable in udev rules for instance. > > Care to explain what you try to do? We have groups for access control to > devices and you can't rely on the availability of acl support in /dev. Switching libsane's udev rules to using ACLs for USB devices, so as to finally work around the issue of multi-function devices, which raised its ugly head again after changes in udev's default rules. As for requiring ACL support for /dev, this is already needed by ConsoleKit for a default desktop install. udev uses tmpfs for /dev and tmpfs has ACL support enabled in the distro kernels already. Seeing how it isn't reasonable anymore to run a system without udev, ACL support for /dev is a given in the general case. Moreover, it'd be consistent with having chmod and chown in /bin. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87d3uebik0@sonic.technologeek.org
Moving ACL utilities to /bin?
Hi,
The ACL utilities ({getf,setf,ch}acl) from the acl package currently
reside in /usr/bin.
This makes it impossible to use them during the early boot sequence
before /usr is mounted, so they're unusable in udev rules for instance.
Are there any reasons or objections against moving the ACL utilities to
/bin, alongside their traditional UNIX counterparts? Note that libacl is
already installed in /lib.
If not, I'll file a bug against the acl package asking for the utilities
to be moved to /bin.
Thanks,
JB.
--
Julien BLACHE - Debian & GNU/Linux Developer -
Public key available on <http://www.jblache.org> - KeyID: F5D6 5169
GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87mxtjhkq7@sonic.technologeek.org
Bug#587958: ITP: forked-daapd -- media server with support for RSP, DAAP, DACP and AirTunes
Package: wnpp Severity: wishlist Owner: Julien BLACHE * Package name: forked-daapd Version : 0.11 (git snapshot) Upstream Author : Julien BLACHE * URL : http://git.debian.org/?p=users/jblache/forked-daapd.git * License : GPL + BSD Programming Lang: C Description : media server with support for RSP, DAAP, DACP and AirTunes forked-daapd is an iTunes-compatible media server, originally intended as a rewrite of Firefly Media Server (also known as mt-daapd). It supports a wide range of audio formats, can stream video to iTunes, FrontRow and other compatible clients, has support for Apple's Remote iPhone/iPod application and can stream music to AirTunes devices like the AirPort Express. It also features RSP support for Roku's SoundBridge devices. Built-in, on-the-fly decoding support enables serving popular free music formats like FLAC, Ogg Vorbis or Musepack to those clients that do not otherwise support them. Package has been ready for some time, initial upload will go to experimental and move to unstable once antlr3 is in a position to move to testing. JB. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100703092131.24533.4946.report...@sonic.technologeek.org
Re: Bindv6only once again
Sylvestre Ledru wrote: Hi, > It is not the case. The OpenJDK has some problems with font management, > slower with Swing and a few other problems. > However, I am not aware of software not working with the OpenJDK (ie > requiring the proprietary Java). ISTR OpenJDK and JDBC4 do not exactly work well together (read: not at all). Do you know anything about that? I've run into this myself and am forced to use Sun's JDK in this case. In case you'd like to check it out, this is with OpenBravo POS using PostgreSQL. The database code just doesn't work at all with OpenJDK 6. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87iq5ku7iz@sonic.technologeek.org
Re: lilo removal in squeeze (or, "please test grub2")
Darren Salt wrote: Hi, >>> Working fine here on i386, whether booting a stock kernel (testing with >>> 2.6.33 from experimental) or a custom kernel. I've not checked a stock >>> kernel on amd64 for some time now, but I've seen no problems with my >>> custom kernels (which are all initrd-free). > >> No problems to report on amd64 either, with or without an initrd. Yes indeed. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87wruu4ouq@sonic.technologeek.org
Re: lilo removal in squeeze (or, "please test grub2")
Darren Salt wrote: Hi, > Working fine here on i386, whether booting a stock kernel (testing with > 2.6.33 from experimental) or a custom kernel. I've not checked a stock kernel > on amd64 for some time now, but I've seen no problems with my custom kernels > (which are all initrd-free). No problems to report on amd64 either, with or without an initrd. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/871vd268d2@sonic.technologeek.org
Re: Too much disruptive NMUs
tony mancill wrote: Hi, > I view the "absolute minimal changes" NMU process as designed for (and > more appropriate for) actively maintained packages. That is, the NMU Either it's a QA upload or it's a NMU, but it can't be "a bit of both". If the package is effectively not maintained anymore, it's up to the MIA team to investigate and eventually decide to orphan the package. This kind of NMUs don't help; they just help the unmaintained stuff fly below the MIA radar longer. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87typz4zv9@sonic.technologeek.org
Re: About new source formats for packages without patches
Raphael Hertzog wrote: > I expect this to be of particular interest when we'll have VCS-powered > source formats (say "3.0 (git2quilt)") that generate source packages that > are plain "3.0 (quilt)" based on the git repository information. This is becoming crazy, really. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87eij3754s@sonic.technologeek.org
Re: About new source formats for packages without patches
Ben Finney wrote: Hi, >> The problem is that if debian/source/format is missing for one reason >> or another, your package will be silently built as a 1.0 source >> package. > > There's no need for it to be silent. The idea was raised that, after a > period of silent deprecation, the recognition of source format 1.0 could > cause a warning. It's a well-known fact that every DD out there thoroughly reviews her package's build log before uploading. Oh, wait, no, it isn't, quite the contrary, actually. > The only point I've been trying to understand is, regardless of how > format 1.0 packages are handled once recognised, why the current > undeclared format 1.0 packages can't be recognised as such indefinitely > without any change in those packages. Because there's no way to tell if it's an old 1.0 package or a 3.0 or later package missing debian/source for whatever reason. FWIW I think debian/source/format sucks big time and its content should be moved to debian/control. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87iq8f77pq@sonic.technologeek.org
Re: About new source formats for packages without patches
Ben Finney wrote: Hi, > As far as I can understand, this is entirely compatible with “absence of > ‘debian/source/format’ always means the package is in “1.0” source The problem is that if debian/source/format is missing for one reason or another, your package will be silently built as a 1.0 source package. From there on, in the best case it fails right away but it can also lead to silently building packages without applying patches. Now, let's say there's a security patch in the pile, and this becomes a problem. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zl1spzmf@sonic.technologeek.org
Re: About new source formats for packages without patches
Benjamin Drung wrote: Hi, > Is there a plan for making the installation of dak easier? The issue (if there actually is an issue there, which is debatable) is not so much that dak is hard to install (because it's such a beast and the documentation isn't exactly stellar) but rather that dak is very Debian-specific and using it outside Debian without replicating the Debian infrastructure and workflow requires a lot of work and patching. Put another way, dak may not be the tool you're looking for in the first place. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ocic71uh@sonic.technologeek.org
Re: About new source formats for packages without patches
Benjamin Drung wrote: Hi, > Why is there no dak and wanna-build package? Are there plans to create > such packages? Have you ever tried to install dak? If you have, then the answer should be obvious to you. If you haven't, try it someday, and you'll understand. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87aatw8hkv@sonic.technologeek.org
Re: German Debian
Marc Haber wrote: Hi, > Unfortunately, all of Debian. Translating technical texts from English > to German is controversial at its best, and the Debian translators > have taken my least favorite approach of eliminating all English, > leading to barbarities like "SMTP-Sendezentrale" or > "Sicherheitsgutachten". Debian's German translations feel to me (a > native speaker of German) as babelfished from English. The same goes for the french translations :( They're absolutely not helping newbies and people who know better just revert to english - IME. > I used to take a look at Debian's translations of my own package's > Debconf templates, but nowadays I just treat them as just another > language that I don't speak. This approach saves me a lot of grief. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vdclhax6@sonic.technologeek.org
Re: Bug#573630: ITP: mule -- Java integration and communication platform
Steffen Moeller wrote: Hi, > * Package name: mule >>From their website: Mule ESB is a lightweight integration platform ... > your applications together. Mule ESB provides a robust, secure and ... > the ESB (enterprise service bus) concept, Mule ESB is the most widely Looks like "mule-esb" would be a better name for the package; it would also help avoid confusion with the MULE stuff related to (X)Emacs. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ljdwmx75@sonic.technologeek.org
Re: Proposed mass prototypejs bug filing for multiple security issues
Michael S Gilbert wrote: > - mt-daapd (embed) Not shipped in the resulting binary package. See Depends:. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: dropping support for kernels < 2.6.22
m...@linux.it (Marco d'Itri) wrote: Hi Marco, > libsane maintainer: you can now remove the rules related to > SUBSYSTEM=="usb_device" (old style /dev/bus/usb/). Thanks, will do. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: DeviceKit and /usr
Hendrik Sattler wrote: >> (I'll do you one better, though -- system-config-printer upstream wants to >> install /lib/udev/udev-configure-printer, which pulls in the entire libcups >> stack. Sigh...) > > *sigh* I agree. Has the world gone mad? The desktop world, yes. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Serious problem with geoip - databases could not be build from source
MJ Ray wrote: Hi, > 4) we deduce the build system by looking at the CSVs and how the > library uses the binary dat files, then junk the upstream-built > dat files. I've no idea if this is feasible, but it's another > option. 5) Add support for an all-new database format. If upstream doesn't want to open its database format, that gives me a reason to believe they might very well change that database format once you'll be done with the reverse engineering and you'd have to start over. So don't even bother, add a second database format and use that in Debian (and other distros will be free to pick it up). JB. -- Julien BLACHE - Debian & GNU/Linux Developer - Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Release goal: Getting rid of unneeded *.la / emptying dependency_libs
Andreas Barth wrote: Hi Aba, > send a mail to d-d-a with "how to do it" and a list of affected > packages, and then step-by-step file the appropriate bug reports > (only for packages which can dump their la-file). Please go ahead with that. It's going to be much much easier to remove the .la files if we have a coordinated effort and it'll greatly reduce the potential for breakages. I plan to take a look at what's needed to remove the .la files in my packages RSN, and it looks painful from where I stand right now. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Debian GNU/Linux 6.0 "Squeeze" release goals
Luk Claes wrote: Hi, > There will be a Build-Arch field or some other way to make sure the > arch:all packages can be built reliably. How will this work wrt non-Linux ports? If you declare Build-Arch: i386, and that means the package should be built only from Linux/i386, that makes the kfreebsd (and hurd) port dependent on the Linux port. I think we want our non-Linux ports to be as self-hosting as our Linux port, so that has to be taken into account... Real-life case: I could make refit an arch: all package, binaries are the same wherever it's useful (i386, amd64 and their kfreebsd counterparts) and it can be built from i386, amd64 or kfreebsd-amd64 (not kfreebsd-i386, for it lacks a biarch compiler). JB. -- Julien BLACHE - Debian & GNU/Linux Developer - Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Debian GNU/Linux 6.0 "Squeeze" release goals
Stefano Zacchiroli wrote: > - do we have an estimate of whether architectures for which we often > upload compiled packages (amd64/i386) have enough buildd power to > cope with the load increase? That, and buildd admin resources for log processing/signing. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: The wider implications of stuffing the NEW queue with issues it was not designed for.
Charles Plessy wrote: Hi, > Do we have evidence that maintainers have damaged the project in the past by > willingfully upload packages with overriden lintian errors? We sure have a few people that would blindly add overrides rather than fixing the actual cause of the lintian warning/error. No doubt about that. Heck, we still have people that do not use lintian. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: The wider implications of stuffing the NEW queue with issues it was not designed for.
Charles Plessy wrote: Hi, > Automatic rejection of packages with errors not justified by overrides is of And what do you do with unjustified overrides? Or can I just override every lintian test and upload my totally broken package? JB. -- Julien BLACHE - Debian & GNU/Linux Developer - Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Conflicting assignment of privileged ports on boot, once again
Petter Reinholdtsen wrote: Hi, > https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/306007> and > http://www.novell.com/support/search.do?cmd=displayKC&docType=kc&externalId=7002186&sliceId=1&docTypeID=DT_TID_1_1&dialogID=67050089&stateId=0%200%2067048399> > report of a bug in the parsing of that file, failing with the current > content. > > Is this issue fixed in Debian? Let's ask the glibc folks. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Conflicting assignment of privileged ports on boot, once again
Gernot Salzer wrote: Hi, > - ... or is it up to the administrator to add the ports manually? That's it. The most common offenders are already in the list; if you're seeing the problem routinely with a popular service that's not on the list already, that'd be a wishlist bug against libc6. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Conflicting assignment of priviledged ports on boot, once again
Gernot Salzer wrote: Hi, > What is currently the expert way to avoid/handle such port conflicts > in Debian? /etc/bindresvport.blacklist JB. -- Julien BLACHE - Debian & GNU/Linux Developer - Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: DEP-5: Please clarify the meaning of "same licence and share copyright holders"
Lars Wirzenius wrote: Hi, > That's the killer point we should concentrate on. I know commercial > derivatives of Debian can benefit from machine-readable debian/copyright > files: their customers may need to get a list of licenses used in the > (subset) of packages the derivative provides them, and this would get I'm sorry but that doesn't fly. Serious people will do their own assessment because they can't risk relying on what they get from a bunch of geeks they know nothing about. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: "Debian is switching to EGLIBC"
John Goerzen wrote: Hi, > I, for one, have heard just about enough of "Hey developers, we're doing > $FOO, and it's already been decided, so put up or shut up" from people. > I'd like a little bit more along the lines of "Hey developers, we > really think $FOO is a good idea. Here's why. What do you all think?" How does "hey developers, we're sick and tired of having to put up with Uli, how about you find some new people to maintain glibc in Debian" sound like? Switching to eglibc is a matter of reducing the burden placed on our libc maintainers due to glibc upstream not giving a crap about most of the architectures we support. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Should we still purge GConf schemas from the old directory?
Luk Claes wrote: Hi, > We only support the upgrade from one stable version to the next one, > though it's always appreciated that we don't break the upgrade when > skipping one release when easily possible. For pre-woody stuff, I would > not hesitate and just clean up the code. It's not an upgrade issue, it's a cleanup issue. As it happens, the upgrade did not clean up the old conffiles in /etc/gconf/schemas when they got moved to /usr. Consequence is, I have a bunch of useless files taking up space in /etc/gconf/schemas that will never get removed unless I knowingly rm -rf /etc/gconf/schemas. Not nice. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#524896: general: Home directory pollution
Michael Biebl wrote: Hi, > The package responsible for creating those directories is xdg-users-dirs. I don't have this package installed, yet transmission creates ~/Desktop and ~/Downloads each and every time I start it. And, no, nothing in its configuration refers to any of those directories. So this package may be part of the problem, but it's only one part of the problem. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
Mike Hommey wrote: Hi, > Who cares that file foo.c is licensed under GPL and bar.c under BSD? > People that want to take the source and use it elsewhere. These people > are obviously looking at the sources, and don't really need > debian/copyright information. Let's add that if you are reusing code, you have to do your own assessment anyway. Of course you can decide to trust debian/copyright, but there's no guarantee and you're taking the risk. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: group nvram
m...@linux.it (Marco d'Itri) wrote: Hi, >> Scanner is useful, imagine I work in a company working on a secret >> project. One of the computer has a scanner. Do you wnat to give >> scanning right to the internship student ? > No, I want to give access to the raw scanner device only to its own > driver-daemon. > I do not know if SCSI scanners already work this way or not. Current scheme for scanners is as follows: - user access: device is group scanner - saned access: device is group saned - user AND saned: either put the saned user in the scanner group, or make the device saned:scanner. USB and SCSI scanners are handled the same way. So to reiterate what I wrote already, if you want to get rid of that in the rules shipped with udev, that's fine by me; libsane will take care of it, it'll be in the next upstream release anyway. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: group nvram
Bernd Zeimetz wrote: Hi, >> Yes, SCSI scanners still exist, and they're still used through >> /dev/sgX. Actually, all high-volume, high-speed scanners are >> SCSI. Some have a USB interface too, but it's slower. > > I also know some fancy damn expensive scanners with firewire, but I doubt > they're supported in sane - unfortunately. True. There's not been a lot of interest for the FireWire scanners. Though I do believe those scanners actually do SCSI over FireWire, but never checked that out. That'd be the most sensible thing to do. That can be verified pretty easily, if the scanner uses SCSI commands (or encapsulation) on its USB interface, you can bet the FireWire interface just does SCSI. I wish I had time to try that out when I had access to an A3 Epson scanner with USB & FireWire. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: group nvram
Bastien ROUCARIES wrote: Hi, >> scanner (do SCSI scanners still exist? how are they used?) > > Scanner is useful, imagine I work in a company working on a secret > project. One of the computer has a scanner. Do you wnat to give > scanning right to the internship student ? Marco is specifically referring to the generic SCSI scanners support in the basic udev rules. That can be migrated to libsane. The scanner group is not going away anytime soon. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: group nvram
m...@linux.it (Marco d'Itri) wrote: Hi, > This is the complete list of groups which I'd rather stop using: > scanner (do SCSI scanners still exist? how are they used?) Yes, SCSI scanners still exist, and they're still used through /dev/sgX. Actually, all high-volume, high-speed scanners are SCSI. Some have a USB interface too, but it's slower. You can pull that from udev if you wish, as support for SCSI scanners has been added upstream to the udev rules and I can backport that to unstable. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: the files in /etc/modprobe.d/
m...@linux.it (Marco d'Itri) wrote: Hi, > etc/modprobe.d/libsane libs/libsane Removed in 1.0.19-26. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Transition: krb5 to drop Kerberos IV (libkrb53 restructuring)
Raphael Hertzog wrote: Hi, >> debian/shlibs.local should help for that. > > Except symbols files have priority over shlibs and there's no > symbols.local. I sense a lack of flexibility in this symbols file feature, hmm. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Transition: krb5 to drop Kerberos IV (libkrb53 restructuring)
Sam Hartman wrote: Hi, > It turns out this fails impressively. The problem is that the library > packages depend on each other. So, for example, libk5crypto3 is > needed by libkrb5-3. If I make the shlibs file for libk5crypto3 point > to libkrb53 instead of libk5crypto3, then libkrb5-3 depends on > libkrb53. But libkrb53 depends on libkrb5-3 because that is the point > of libkrb53 in the new layout. > > I probably could hack something that would work: use symbols files > that point at the split library packages internally and just before > the debs are constructed run a sed script on symbols and shlibs. debian/shlibs.local should help for that. JB. -- Julien BLACHE | Debian, because code matters more Debian & GNU/Linux Developer| <http://www.debian.org> Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Transition: krb5 to drop Kerberos IV (libkrb53 restructuring)
Sam Hartman wrote: Hi, > OK, so I think we're all set. > > The plan now is to Looks good! > 1) Build twice, once into build and once into build-krb4. We only > pull libkrb4.so out of build-krb4. 2) Move all the libraries out of > libkrb53 and libkadm55 (sorry, in my previous mails I was simplifying > a bit) except for libkrb4.so.2. I guessed that looking at the various packages :) JB. -- Julien BLACHE | Debian, because code matters more Debian & GNU/Linux Developer| <http://www.debian.org> Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Transition: krb5 to drop Kerberos IV (libkrb53 restructuring)
Sam Hartman wrote: > I really appreciate your help here! Thanks! > I'm sorry, but I don't see how I get stuck in unstable if I start out > with the libkrb5-3 shlibs and symbols files pointing to libkrb5-3 > rather than libkrb53. As I understand it, rdeps can only hold me in > unstable if moving my package into testing would make them > uninstallable in testing. Yes you are right about this. > Now, I might hold my rdeps in unstable if for some reason it takes a > while for the new krb5 to migrate into testing. However that's no And that's what what I had in mind and wrote the other way around :) > more true than if I added some symbols to one of my libraries and > upgraded my versioned dependency. Still that's a reason to leave the > shlibs and symbols files pointing at libkrb53 until I make it into > testing. It's not strictly necessary as you pointed out, but in the end it makes the transition even smoother and protects against anything that could come up in the 10 days you'll spend in unstable with the new version. A bit over-engineered maybe, but I like doing transitions (and not only package transitions in Debian :)) in a way that provides me with a big switch to throw once everything is ready while still having options for pausing or backing out if anything comes up. > The krb4 using packages are all leaf packages, so they will not > complicate things until libkrb53 goes away. That's what I got from your initial mail. > I trimmed the reply text, but you asked why I need two build passes. > The krb5 package includes a bunch of libraries as well as daemons, > utilities etc. Building with krb4 enabled does more than build krb4 > libraries, and I want to get the affects of building with krb4 > disabled for daemons and utilities. Doing two build passes will be Oh, OK. That doesn't necessarily have to be done when introducing libkrb5-3, but that's entirely your call of course. > easy given my package structure and the package does not take > particularly long to build. That's a big help in this case! JB. -- Julien BLACHE | Debian, because code matters more Debian & GNU/Linux Developer| <http://www.debian.org> Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Transition: krb5 to drop Kerberos IV (libkrb53 restructuring)
te in your mail that you were planning to split out the libraries in individual packages. > appreciate your answer to whether the alternatives approach would work > to help sanity check my understanding in this space. Alternatives are supported in the shlibs, but I'd worry about the upgrade path. In particular, you'd also need to version the dependencies, and I can't remember whether that's supported in the alternatives. Otherwise a newer libkrb53 without libkrb5 could satisfy the dependency. JB. -- Julien BLACHE | Debian, because code matters more Debian & GNU/Linux Developer| <http://www.debian.org> Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Transition: krb5 to drop Kerberos IV (libkrb53 restructuring)
Sam Hartman wrote: Hi, > That is, if I made the dependency in libkrb5-3.symbols look like > libkrb5-3|libkrb53 (and similar changes for other symbols files), then > both the packages in unstable and testing would satisfy the > dependencies. It seems like this would significantly reduce the > impact of the transition. Am I missing something or would this change > be a good idea? Have you considered uploading a version of krb5 with: - libkrb5-3 - libkrb4-? - libkrb53 a metapackage depending on both of the above - libkrb5-dev depending on libkrb5-3 alone and containing only the files needed to link with libkrb5-3 Then you can do a smooth transition that won't break anything. Wait until that version makes it to testing and then ask for binNMUs for anything that can be binNMUed and still depends on libkrb53. Once you're all done, get rid of libkrb4-? and libkrb53 (add a conflict on libkrb53 in libkrb5-3 to force the removal?). That should ease things quite a bit, especially given the number of rdeps... JB. -- Julien BLACHE - Debian & GNU/Linux Developer - Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Possible MBF due to DBus security issue
Matthew Johnson wrote: Hi, > Julien BLACHE >pommed Fixed upstream in (soon to be released) 1.25, will go in unstable and I plan to get it into Lenny if the tightened DBus goes in Lenny too. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: mass bug filing for undefined sn?printf use
Adeodato Simó wrote: Hi, > Julien BLACHE >unpaper Patch sent. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Josselin Mouette and Planet Debian
Michael Banck wrote: > Like it or not, messages to d-d-a are frequently forwarded verbatim to > LWN and other major IT-centered news sources. This happen much less Pretty much everything and anything ends up there, so that's hardly a criterion for relevance or whatever. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Josselin Mouette and Planet Debian
Stefano Zacchiroli wrote: Hi, >> Official announcements to the outside world actually appear in >> debian-announce; debian-devel-announce is a developer list. > > You are a bit picky, you know? :-) I don't think so; setting the record straight isn't being picky :) > Yes: I know the difference between d-d-a and debian-announce, I > skimmed over it in my post because I don't think the difference affect > in any way my argument. Feel free to prove me wrong. I'd argue about that "official" thing that people have been using to qualify d-d-a. It's an announce list for developers, by developers. I'm not sure what's official in there. I'd tend to say anything "official" is project communication, that effectively goes to debian-announce. I essentially wanted to set the record straight as various things have been written about d-d-a and its purpose after Joss' post, here and elsewhere, mistaking d-d-a for d-a. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Josselin Mouette and Planet Debian
Stefano Zacchiroli wrote: Hi, > them. Your implicit assumption that Planet Debian conveys an > "official" message to our community is totally unsound IMO. We have > d-d-a for our official message (yes, Joss abused that, and has been Official announcements to the outside world actually appear in debian-announce; debian-devel-announce is a developer list. Check the descriptions for both lists on lists.debian.org. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable -> testing
"Daniel Moerner" wrote: Hi, > Obviously, having more users test unstable is good. However, I agree > that it's not necessarily a big issue. A good deal of RC-bugs are > related to FTBFS, security advisories, package conflicts, and the > like. These bugs can pop up independently of how much testing a > package receives in unstable, so focusing on just increasing the > number of unstable users would produce diminishing returns. Your point is moot, mostly: FTBFS and package relationships issues are probably the easiest RC bugs to fix, they're not the kind of RC bugs we're seeing right now before a release (at that point any RC bugs of these kinds that aren't fixed are either tricky or not being taken care of properly). Also most FTBFS are not reported by users. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable -> testing
Josselin Mouette wrote: Hi, > Maybe that’s because I maintain packages with a large audience, but I > don’t find that effect very important. You're right about the large audience, it does make quite a difference. > Actually I don’t think we should recommend testing at all to desktop > users. Except during freeze times, I find unstable to be much more > usable, and keep testing for (non-production) servers. Agreed. > However it is important to keep a large testing userbase, since > developers don’t (at least, they aren’t supposed to) use it. Some bugs Ditto. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable -> testing
Jan Hauke Rahm wrote: Hi, > Reading this (and following the idea of not introducing new stuff or > archives but releasing faster) it sounds as simple as "testing needs > to be more strict and rigorous in accepting packages to be *indeed* > always in a seriously better shape than unstable so that releases can be > done with shorter freeze times", right? When testing was introduced, people moved from using unstable to using testing to get the latest and greatest. At that time, unstable was sometimes pretty wild, prone to serious breakages way more often that today (be it after a release - which was a horrible time, really - or during heavy development). Also new users have a tendency to go with testing and don't use unstable much these days. The net effect is that there aren't enough people left using unstable to uncover enough problems. Hence bugs silently make it to testing. Being stricter wrt testing migration is hardly going to help. What will help is having more people actually use unstable so bugs are uncovered before they hit testing. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable -> testing
Noah Slater wrote: Hi, > suit. This inevitably causes a chain reaction of rudeness and flames. As a > community, we would do well to be a little more tolerant of others, and that > includes their mistakes. And that includes cutting some slack to people when they vent off, as people occasionally do. BTW, that "community" thing is really overrated and totally overinflated these days. Everybody refers to the "community" all the time for everything. It doesn't mean anything anymore. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable -> testing
Russell Coker wrote: Hi, > I think that we need a way to upload to Lenny without involving unstable. Something like testing-proposed-updates, which already exists today, and also existed for previous releases? > Failing that I will create my own repository for unstable versions of my > packages - which of course won't give as good a result as most users of > Unstable won't get them. You mean, something like experimental? You failed "Basic research 101". And it was as simple as going to <http://release.debian.org> and read the Lenny freeze announcement <http://lists.debian.org/debian-devel-announce/2008/07/msg7.html> that is linked under the "Lenny frozen" title. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Packages still depending on GTK+ 1.2
Josselin Mouette <[EMAIL PROTECTED]> wrote: >> And nope, visualboyadvance doesn't replace gsnes9x, although the latter is >> just >> a front-end. > > Gah, I thought it was able to handle SNES ROMs. The correct answer would > probably be zsnes, although it only works on i386. You missed the word "frontend" in the above. gsnes9x is a simple frontend for snes9x-x. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]> Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NEW processing
Lucas Nussbaum <[EMAIL PROTECTED]> wrote: > Most of our users would probably agree to trade a small amount of > quality with faster packaging of new versions, and more timely releases. No. The people you describe want Ubuntu, or something alike. They're free to go get it, as far as I'm concerned. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]> Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#500386: ITP: libcam -- device-independent image acquisition and processing API
Albert Huang <[EMAIL PROTECTED]> wrote: Hi, > * Package name: libcam kFreeBSD has libcam0 and libcam-dev built from the freebsd-libs source. There's a potential for troubles here, unless your libcam is a linux-only package. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]> Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: EULA as well: xsane
Michael Banck <[EMAIL PROTECTED]> wrote: >> The one click-through that went away in 0.995-3? > > If you are unsure of this and have to ask, you can look it up in the > changelog, maybe. I'm XSane's maintainer, in case you missed that. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]> Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: EULA as well: xsane
Robert Lemmen <[EMAIL PROTECTED]> wrote: Hi, > while the EULA topic is already being discussed: there is at least one > other package in the debian archive which displays a click-through EULA, > namely xsane. The one click-through that went away in 0.995-3? JB. -- Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]> Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: nut package freeze exception request (dependency based boot)
"Anton Martchukov" <[EMAIL PROTECTED]> wrote: > 2) Changhe insserv to not count symlinks at all (do not know about > possible affects about it) Rather make insserv ignore symlinks pointing to a file in the same directory. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]> Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is it a "user error" to use lilo?
William Pitcock <[EMAIL PROTECTED]> wrote: Hi, > If you have both GRUB and LILO installed, there will be problems. That > is infact, a bug. They should Conflict with each other to ensure that > only one can be installed at a time, but it is a minor bug at best, as There's no reason why the LILO and GRUB packages should conflict. I want to use LILO on my machine because GRUB fails miserably, yet I need GRUB to generate a GRUB boot-floppy. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]> Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: how to split architecture dependent data files into separate package
"Kov Chai" <[EMAIL PROTECTED]> wrote:
Hi,
> best approach in my mind is to create two other data packages named
> sunpinyin-le-data and sunpinyin-ge-data, and make the binary packages depend
> on the data package by its endianness accordingly.
>
> Is this solution feasible, or is there any better way to solve this problem?
Yes, that makes sense. At least as long as your data files are
compatible between 32bit and 64bit hosts.
(and make that -data-le and -data-be, IMHO)
> And moreover, I am afraid that sunpinyin-{le,ge}-data are not architecture
> neutral. So is it okay to make these two packages Arch:all?
Yes.
> At last, Is there any way to specify the package dependency by architecture?
Use a substitution variable in debian/control and determine the
correct value in debian/rules before calling dh_gencontrol.
JB.
--
Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]>
Public key available on <http://www.jblache.org> - KeyID: F5D6 5169
GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg triggers, dpkg hijack
Faidon Liambotis <[EMAIL PROTECTED]> wrote: > In your position, I'd probably be afraid of receiving the "Joerg > Schilling award". The "Sven Luther award" may be more appropriate; time will tell. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]> Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Buildd backlog and testing transition.
Petter Reinholdtsen <[EMAIL PROTECTED]> wrote: >> The buildd queues aren't FIFO, this has been explained already a >> dozen times if not more. > > And every time that discussion surfaces, suggestions to include age in > the formula used to calculate the build order are presented. Also > suggestions to include amount of dependencies normally show up. I > wish some of these suggestions would fix some of the starvation issues > with the current autobuild system. The age of a package is not pertinent here. The way the buildd queue works has it sort itself out when a backlog builds due to whatever reason, but that induces starvation at the testing migration level. Trying to build newer packages first is not necessarily a bad tactic; those packages will either build, which is good, or fail to build due to a build-dep being unavailable. In this case, they're set dep-wait and they're no longer in the queue, so packages part of the backlog start to get at the top of the queue. Once they're built, the dep-wait start being resolved, and the queue sorts itself out. I'd say from the buildd perspective, that works great as long as the dep-wait get set (which is a manual action). Of course it wastes /some/ buildd time, but in the meantime, any new package that can be built gets built which is a good thing. There's always the other tactic, indeed, consisting in building in a FIFO order. That's a matter of choice, and I think the current system benefits to packages that matters in terms of build-deps (balanced with the other parameters). But, as said and as we see routinely, this induces starvation in the testing migration. So if you want to add a new parameter in the buildd queue, the amount of packages waiting for testing migration due to the specific package being considered is way more pertinent than the sole age of the package in the buildd queue. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]> Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Buildd backlog and testing transition.
Charles Plessy <[EMAIL PROTECTED]> wrote: >> He doesn't have to use unstable. He can use pinning for this specific >> package. > > Sure, and he can also use dpkg -i. The question is: why should we ask > him to make the effort? He is using testing. We never made any commitment wrt availability in testing. Testing is a *tool* for us, unfortunately too many testing users can't understand this. > Clearly, in the conflict of interest between the ghc6 MIPS users, and > the testing users on other arches, a choice has been made, of which I am > unhappy. No choice has been made. I don't know what you're on, but you'd better put it off. The buildd queues aren't FIFO, this has been explained already a dozen times if not more. buildd problems do happen, have happened in the past and will continue to happen. In the MIPS case, the buildds are impacted by real technical problems that take time and effort to get fixed. It's not like it's a manpower problem in replacing a broken disk or something alike. >> Stop whining. > C'est celui qui le dit qui l'est. What do you expect when posting such > sentence on this mailing list? I reiterate: get a clue, and stop whining. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]> Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Buildd backlog and testing transition.
Charles Plessy <[EMAIL PROTECTED]> wrote: > packages migrate? I just got a message from a user who wants to use one > of the blocked packages (emboss), and I am just so ashamed to answer him > that he has to use unstable just because it is not built on a platform > where nobody is using it. He doesn't have to use unstable. He can use pinning for this specific package. Stop whining. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]> Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: some packges are waiting for i386 build
Hideki Yamane <[EMAIL PROTECTED]> wrote: > Umm, if build daemon is down, it is a problem, I think. > As i386 it is not a serious, but it is just a problem. It is a problem, and it is serious. It's stalling the testing transition already due to missing builds. i386 is no longer a special case among our supported architectures. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]> Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packaging a library that requires cross-compiled code
Vincent Danjean <[EMAIL PROTECTED]> wrote: > Julien BLACHE wrote: >> Shachar Shemesh <[EMAIL PROTECTED]> wrote: >> >>> I think we need a change in policy for handling cases where free >>> software requires free software in order to compile which is, non the >>> less, non buildable on the same platform. >> >> It exists already, it's called the contrib section of the archive. > > No. The contrib section is for free software that requires non-free software. Policy 2.2.2 [...] Examples of packages which would be included in contrib are: * free packages which require contrib, non-free packages or packages which are not in our archive at all for compilation or execution, and [...] > However, all is free software in this thread. The problem does not come > from the license but from the difficulty to setup a correct build environment > (due to cross compilation to another architecture or another platform) Yeah, right, seems to fit. JB. -- Julien BLACHE <[EMAIL PROTECTED]> | Debian, because code matters more Debian & GNU/Linux Developer| <http://www.debian.org> Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packaging a library that requires cross-compiled code
Shachar Shemesh <[EMAIL PROTECTED]> wrote: > I think we need a change in policy for handling cases where free > software requires free software in order to compile which is, non the > less, non buildable on the same platform. It exists already, it's called the contrib section of the archive. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]> Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: virtualbox-ose: package hijack?
Daniel Baumann <[EMAIL PROTECTED]> wrote: >> Are we talking about the same upstream here? > > i did answer to this question to michael in private (nda reasons). Please post this explanation to -private. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]> Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#440082: ITP: arcload -- bootloader for SGI/ARCS machines
Package: wnpp Severity: wishlist Owner: Julien BLACHE <[EMAIL PROTECTED]> * Package name: arcload Version : 0.5 Upstream Author : Stanislaw Skowronek <[EMAIL PROTECTED]> * URL : http://www.linux-mips.org/wiki/ARCLoad * License : GPL Programming Lang: C Description : bootloader for SGI/ARCS machines ARC Load was built to load any Linux kernel on any SGI/ARCS machine. Therefore, it currently supports: o IP22: SGI Indy, SGI Indigo2 o IP27: SGI Origin200 & Origin2000 o IP28: SGI Indigo2 R1 o IP30: SGI Octane o IP32: SGI O2 JB. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: mips (mips64) Kernel: Linux 2.6.18-4-r4k-ip22 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GTK1 Apps
Matthew Johnson <[EMAIL PROTECTED]> wrote: Hi, > I am the gbib maintainer and despite the fact that it is fairly > unmaintained upstream I use it regularly and know of no good > replacement. I would love to port it it to GTK2, and it is a fairly > Are there any guides, howtos, instructions or anything else useful for > porting gtk1 apps to gtk2? I certainly would like to keep this package I > use daily in Debian, as I'm sure would many of my 350*(popcon factor) > users. Looks like gbib is even a GNOME 1 app; if true, that'll probably require a bit more work to port it to GTK2/GNOME2, depending on the widgets it needs... JB. -- Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]> Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for GTK1 removal from Debian
Neil Williams <[EMAIL PROTECTED]> wrote: > wmbubble 437425 > wmcliphist 437433 > wmclockmon 437442 > wmfishtime 437429 > wmmaiload 437444 > wmressel 437430 > wmusic Remote control dockapp for XMMS, will go away with XMMS. I've removed it from the wiki too. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]> Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for GTK1 removal from Debian
Mikhail Gusarov <[EMAIL PROTECTED]> wrote: > JB> And there are still some useful applications in the list... > > Probably some workflow for phasing them out might help. It's possible for some of these applications, but not for all. The best approach is probably to port them over to GTK2, but I suspect it's fairly non-trivial for some (most ?) of them... Any application using a custom GTK widget will take days to port to GTK2. Not mentioning the GNOME1 applications in this list ... > At least I've seen 'gtk-theme-switch' in the list, which provides utility for > both GTK1 and GTK2 and does not block GTK1 from being excluded. I suppose > there > are more such applications. Yep. gtk-theme-switch is moot anyway, even if it was GTK1-only, as it becomes useless once you've got rid of everything else. I'm giving a shot at some of the low hanging fruits, is there a usertag that can be used to track GTK2 patches in the BTS ? JB. -- Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]> Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for GTK1 removal from Debian
Neil Williams <[EMAIL PROTECTED]> wrote: > 274 are neither gtk libraries nor related to xmms. > > 231 of those are not orphaned. That's a lot of packages. > After a little more trimming of libraries, packages that are just > dependencies of other packages in the list, I get 192 unorphaned > packages dependent on gtk1 that are unrelated to xmms: > imms That's an XMMS plugin, it's even in the short description (maybe you've matched on "xmms" ?) > manedit > manedit Appears twice ? > multi-gnome-terminal Already obsolete, IIRC ? > Contrary to my own preconceptions, I'd say that the idea of removing > Gtk1 is dead-in-the-water. > :-( And there are still some useful applications in the list... JB. -- Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]> Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
William Pitcock <[EMAIL PROTECTED]> wrote: > Yes, we are indeed aware of your bug, however, after inquiring with the people > responsible for the ALSA plugin, the conclusion we presently have is that we > are > unable to reproduce it, so it will take some time before we can come up with a > patch for 1.3 in Debian or even perhaps a release which resolves the issue. > But > don't worry, since your bug is indeed valid, it will be fixed in > audacious-plugins-1.3.6; even if I have to do it myself. I think you need at least an Intel HDA card to reproduce that problem, as it's probably the driver that presents something weird to the lib. Might even need a MacBook with the same setup :| I'll see on another machine if the ALSA plugin behaves better. > I presently do not use ALSA, so I cannot help much there at the moment. If you Still using OSS ? :) > are interested in fixing this, please hang around our IRC channel at > irc.atheme.org #audacious, and ask to talk to either Chainsaw or giacomo, who I'll try to take a closer look at the problem if I can find some time to do so. > jointly maintain the plugin. Be sure to identify yourself and note that I > specifically sent you there, because some of our inhabitants who will for the > interest of transparency, remain nameless at this time are capable of being > very > rude and abusive -- and would likely be more pleasant if they knew that > someone > high up in the project directly requested your presence for debugging. Can't be worse than -devel ;) JB. -- Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]> Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
William Pitcock <[EMAIL PROTECTED]> wrote: >> I propose you STFU and go fix your bugs. > > I propose you stop classifying bugs which state "is not XMMS" as bugs in > Audacious, or generally talking about commandeering my project. Thanks! Two bugs: - random crashes while scrolling the playlist - segfault in the ALSA output plugin That's <http://bugs.debian.org/435557> in case you're interested in fixing the pile of crap that is your ALSA output plugin (hey, XMMS' one behaves perfectly...). That bug has been discussed upstream already and I provided the requested information already. I never complained about audacious not being XMMS, there's no special XMMS feature that I miss in audacious. Now if only it'd stop segfaulting in under 2 minutes, that would render it usable. Now, will you please go fix your bugs ? Thanks, JB. -- Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]> Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
William Pitcock <[EMAIL PROTECTED]> wrote: >> As you don't seem to have understood at all, none of the xmms >> alternatives are up to par with xmms, with many of them having >> usability or stability problems. > > Please stop blaming the faults and defects of your packaging process on > upstream > developers. Audacious 1.3 is perfectly capable of replacing XMMS, and has done > so in many other distributions already. > > Moreover, Adam Cecile has tried to get 1.3 into both Etch and now Lenny, and > has > so far been met with trouble doing so. You want your fixes? Guess what -- they > are in 1.3. Perhaps all that is needed is for Audacious in Debian testing to > actually reflect the current offering of upstream. [07-08-12 - 11:52:13] [EMAIL PROTECTED](pts/2 300):~% dpkg -l audacious Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name VersionDescription +++-==-==- ii audacious 1.3.2-4Small and fast audio player which supports l I propose you STFU and go fix your bugs. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]> Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
Josselin Mouette <[EMAIL PROTECTED]> wrote: > As you don't seem to have understood at all, let me repeat it: XMMS is > unmaintained. GTK+ 1.2 is unmaintained. Anyone who wants to see xmms > remain in Debian should take over maintainership for both, including > upstream maintenance and all that it implies. As you don't seem to have understood at all, none of the xmms alternatives are up to par with xmms, with many of them having usability or stability problems. Anyone who wants to see xmms removed from Debian should step up and do whatever is required to get at least one of the alternatives in a somewhat usable shape. See? It works the other way around too :-) I really don't see the problem in keeping xmms around until there's a viable alternative. It's not like it's the last GTK+ 1.2 application in the archive, and it's most certainly not the least useful of the lot. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]> Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
Stanislav Maslovski <[EMAIL PROTECTED]> wrote: >> Random segfaults during playback, random segfaults while scrolling the >> playlist; can't have it running for more than 2 minutes. > > If you are using the version from Etch I would recommend upgrading/backporting > to the version from unstable. It is quite usable. I'm running unstable on all my desktops. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]> Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
"David Lopez Zajara (Er_Maqui)" <[EMAIL PROTECTED]> wrote: Hi, > Personally i'm an xmms user, and now, with this, i have tested other > options. Audacious isn't an option at all. Yes, we have the same I've recently tried to switch to Audacious, and man it's buggy. Way more buggy than xmms. Random segfaults during playback, random segfaults while scrolling the playlist; can't have it running for more than 2 minutes. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]> Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Installation of Recommends by default on October 1st
Loïc Minier <[EMAIL PROTECTED]> wrote: >> Now, from the Debian users I know around me, I can tell you that none >> of them like aptitude, and they especially dislike the "install >> recommends by default" so-called "feature". > > So what you're really battling against is enforcement of Recommends, > not about enforcement of Recommends in a particular frontend, otherwise > you would use aptitude. I'd use aptitude if I wanted Recommends installed by default. I'm using apt-get precisely because it's not doing this kind of stupid things. And I'd really like it if it could stay that way: use aptitude if you want your Recommends installed by default, and leave apt-get alone for the folks who like its current behaviour. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]> Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Installation of Recommends by default on October 1st
Raphael Hertzog <[EMAIL PROTECTED]> wrote: > I've read that but I didn't take it into account because people google for > docs and they will find documentation recommending apt-get (they usually won't > notice if the doc is recent or not). Furthermore, there's also the fact > that on user forums there are people who will still be recommending > apt-get as it's what they are using. > > So you might be right on your first assertion, but I don't agree with your > conclusion "If doc is the only problem, then it's not a problem". When aptitude came out, we've been told that aptitude was the real apt frontend that apt-get was never meant to be to begin with (apt-get being only a debug/devel tool for libapt) and that it was the tool to use from now on for everybody except maybe for advanced users who will probably stick with apt-get. Either this hasn't got enough publicity, or people decided to stick with apt-get because aptitude didn't cut it. The former case is easy enough to fix before October 1st; the latter might not be that easy to fix, depending on the reasons behind the dislike for aptitude. Now, from the Debian users I know around me, I can tell you that none of them like aptitude, and they especially dislike the "install recommends by default" so-called "feature". JB. -- Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]> Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Installation of Recommends by default on October 1st
Raphael Hertzog <[EMAIL PROTECTED]> wrote: >> Most (if not all) of the recent docs I've come to read mentionned >> aptitude rather than apt-get. > > I'm sorry but that's hardly the case. Google finds about 2 or 3 times more > reference to "Debian apt-get" than to "Debian aptitude". Way to not read (or is that not understand ?) what I wrote :) Hint: "recent". JB. -- Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]> Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Installation of Recommends by default on October 1st
Sam Morris <[EMAIL PROTECTED]> wrote: > The problem is that apt-get is *not* an advanced user tool. End users use > it because they see it referenced in all our documentation, all the > documentation they find elsewhere on the web and in our mailing list > archives, all the conversations they have on IRC while trying to find > help, etc... Most (if not all) of the recent docs I've come to read mentionned aptitude rather than apt-get. If documentation is the only problem, then there's no problem. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]> Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Installation of Recommends by default on October 1st
Loïc Minier <[EMAIL PROTECTED]> wrote: >> We have frontends like aptitude to automatically install recommends. > > and it's the single frontend doing this: synaptic + apt-get are very > common and there was no reason to duplicate this logic in all > frontends. Keeping the current apt default of NOT installing recommended packages and having synaptic explicitely enable the automatic installation of recommended packages could be a solution, too. Though, doesn't synaptic pass the list of packages to install to apt ? I guess synaptic can add the recommended packages to the list all by itself, in this case. I'd really like it if we could keep apt-get as an advanced user tool; aptitude can be used in all the other cases. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]> Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#435390: ITP: wmauda -- remote-control dockapp for Audacious
Package: wnpp Severity: wishlist Owner: Julien BLACHE <[EMAIL PROTECTED]> * Package name: wmauda Version : 0.3 Upstream Author : Michael Stewart <[EMAIL PROTECTED]> * URL : http://dockapps.org/file.php/id/330 * License : GPL Programming Lang: C Description : remote-control dockapp for Audacious wmauda is a dockapp for WindowMaker and other window managers that support dockable applets. It acts as a remote control for the Audacious media player. . wmauda is a port of wmxmms to Audacious, itself seen as a replacement for XMMS. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.21 (SMP w/2 CPU cores) Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#420564: ITP: python-asterisk -- Asterisk Manager API interface module for Python
Package: wnpp Severity: wishlist Owner: Julien BLACHE <[EMAIL PROTECTED]> * Package name: python-asterisk Version : 0.1a3+r160 Upstream Author : David M. Wilson <[EMAIL PROTECTED]> * URL : http://py-asterisk.berlios.de/py-asterisk.php * License : MIT Programming Lang: Python Description : Asterisk Manager API interface module for Python This module provides an object oriented interface to the Asterisk Manager API, whilst embracing some applicable Python concepts: o Functionality is split into separate mix-in classes o Asterisk PBX errors cause fairly granular exceptions o Docstrings are provided for all objects o The module may be used asynchronously if required. It should be suitable for inclusion in a single-threaded GUI o Asterisk data is translated into data stored using Python types, so working with it should be trivial. Through the use of XMLRPCServer or similar, it should be trivial to expose this conversion to other languages JB. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.20 (SMP w/2 CPU cores) Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#413022: ITP: oflib -- OpenFirmware device-tree parsing library
Package: wnpp Severity: wishlist Owner: Julien BLACHE <[EMAIL PROTECTED]> * Package name: oflib Version : git snapshot of the day Upstream Author : Alastair Poole <[EMAIL PROTECTED]> * URL : http://git.sipsolutions.net/of-lib.git/ * License : GPL Programming Lang: C Description : OpenFirmware device-tree parsing library oflib is a library designed to make the parsing of POWER and SPARC device-tree's (OpenFirmware) simple and fast. . It is useful for querying the hardware of the current system in applications for Apple, IBM and SUN machines. JB. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.20 Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#412235: ITP: transfermii -- mii transfer program
Romain Beauxis <[EMAIL PROTECTED]> wrote: > Description : mii transfer program > > transfermii allows you to transfer your miis from and to your wiimotes. > I uses cwiid as a backend. Please enhance the short description, making it clear that this package is related to the wiimotes. At first I thought it was network-related. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]> Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Explications needed...
Stephane Bortzmeyer <[EMAIL PROTECTED]> wrote: > It seems common sense! Debian has a serious problem if you have to > write everything down. > > "A buildd maintainer must be able to type Unix commands on a > keyboard." "And the said keyboard must be connected one way or another to the said buildd, which must be powered up and booted" While we're at it ... unfortunately common sense isn't exactly common anymore these days. JB. -- Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]> Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#402280: ITP: mbpeventd -- Apple MacBook Pro hotkeys event handler
Package: wnpp Severity: wishlist Owner: Julien BLACHE <[EMAIL PROTECTED]> * Package name: mbpeventd Version : 0.3 Upstream Author : Julien BLACHE <[EMAIL PROTECTED]> * URL : http://technologeek.org/projects/mbpeventd/ (soon) * License : GPL Programming Lang: C Description : Apple MacBook Pro hotkeys event handler mbpeventd handles the hotkeys found on Apple MacBook Pro laptops and adjusts the LCD backlight, sound volume, keyboard backlight or ejects the CD-ROM drive accordingly. . mbpeventd also monitors the ambient light sensors to automatically light up the keyboard backlight. . Support for the MacBook laptops is planned, patches welcome. JB. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.19 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]
