Re: Some observations regardig the progress towards Debian 3.1
On Tue, Nov 18, 2003 at 10:54:00PM +0100, Yann Dirson wrote: > On Tue, Nov 18, 2003 at 07:29:29PM +0100, Adrian Bunk wrote: > > There are some good suggestions in your proposal, e.g. you suggest to > > check whether the build dependencies are fulfilled. The lack of checking > > for build dependencies in the current testing scripts often leads to > > packages in testing you can't build inside testing. > > Sure, and that can probably be added to testing scripts right now, > isn't it ? Although I've never looked at the testing scripts, I doubt it would be a big change. > > But you have to be aware that your proposal only works for the cases > > where the programs actually compile and work with older versions of > > libraries, the big tasks like getting KDE 3, GNOME 2 or a more recent > > Mozilla into testing aren't affected by your suggestion. > > Yes. We could think about having a fast low-cost buildd (ie. i386) > initiating the build that will eventually migrate, and build arch-all > debs. Only if that succeeds will other buildds start their work. If > that initial build fails, then the unstable version has to be flagged > on-hold, and attempted again when one of its builddeps has been promoted. Let me make a more concrete example for the problems I meant with "big tasks": KDE 3 needed a long time until it was hinted into testing. Due to the dependencies, it wasn't possible for KDE 3 to enter testing without replacing the complete KDE 2 (e.g. you can't recompile most programs from KDE 3 with the KDE libs from KDE 2). Your proposal wouldn't have been able to shorten the move of KDE 3 into testing by one single day. > But that would not handle the "and work" part of your statement. For > this we'd need to be able to declare testsuites to be run (this has > been discussed recently, IIRC, although I missed the thread). testsuites must be written, and testsuites for GUI programs are even more work. > But more importantly, if a program deos not "compile and work with > older versions", then it's a case of insufficiently-narrowed > build-dep, and we'll have the same type of breakage that we have today > with insufficiently-narrowed deps. Could anyone using "testing" (how > much people use testing ?) share his feelings about the frequency of > such breakages, and how it evolved since testing exists ? That could > give a hint whether this is a showstopper or not. > > But that last point raises another issue: does anyone really use > testing ? Would anyone use pre-testing after all ? > > And if we can make testing usable enough so that people do use it, > what incentive would there be to use pre-testing ? These are good questions. > > There might be new problems e.g. with inter-library dpendencies for > > libraries without versioned symbols if your proposal would be > > implemented. > > Hm ? I'm not sure I understand what the problem you mention is. An example: unstable: Package: libfoo0 Depends: libbar1 Package: mypackage Depends: libfoo0, libbar1 testing: Package: libbar0 If you recompile libfoo0 for testing with libbar0, the following is allowed through the dependencies: Package: libfoo0 Depends: libbar0 Package: mypackage Depends: libfoo0, libbar1 IOW: The program in mypackage is in this situation linked with two different so-versions of libbar at the same time. Without versioned symbols in libbar, it's not unlikely this situation will show up e.g. via strange crashes in the program. libpng and libssl are examples for libraries where this problem was already observed (not really related to testing, the worst problems were in unstable). > > > There _are_ many things to think about, but it may be worth to > > > investigate it, and see how we could handle the potential problems we > > > can think of. > > >... > > > > There's also a different discussion that should take place: > > > > Is testing actually worth the effort? > > > > Testing has it's benefits, e.g. it catches build errors and dependency > > problems. > > So what about looking for solutions for the problems ? If we drop > testing, what do we do instead ? Go back to evolving-unstable -> > frozen -> stable ? If it turns out that testing isn't worth the effort, this is one possible solution. >... > > testing with its lack of security fixes, aprox. 500 RC bugs and daily > > changing packages is not usable for production systems. > > What's the problem with daily changing packages ? By nature, only > different packages can change each day. That could make it a good > compromise between stable and unst
Re: Some observations regardig the progress towards Debian 3.1
On Wed, Nov 19, 2003 at 10:41:05AM +0100, Yann Dirson wrote:
>...
> That could be done either by a rebuild, or, less costly, by a simple
> unpack/edit-changelog/repack.
Repacking breaks with every
Depends: somepackage (= ${Source-Version})
> In that case, if we had libfoo0_1.0-1 in pre-testing, and
> libfoo0_1.0-2 in unstable, we'd end up with libfoo0_1.0-2.0.1 in
> pre-testing, and libfoo0_1.0-2.0.2 in unstable, whether the latter was
> rebuilt or just repacked.
These version numbers are currently assigned to binary only NMUs, it
would create big confusion if they were also used for a different
purpose.
> Regards,
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Re: Some observations regardig the progress towards Debian 3.1
On Mon, Dec 01, 2003 at 04:10:56PM -0800, Mike Fedyk wrote: >... > > * it isn't consistent in all respects; e.g. although the package > > dependencies might have been fulfilled, it contained for some time a > > strange mixture of GNOME 1 and GNOME 2 > > I'm pretty sure that was because of hinting. Not necessarily. The GNOME 1 and the GNOME 2 libraries can coexist, and testing and unstable contain both. That's required, since some important applications that use that GNOME libraries but arent't part of GNOME aren't ported to GNOME 2. An example for such an application is Gnucash (when counting libglib1.2 as GNOME library, e.g. CUPS (via gs-esp), FVWM and xmms are also affected). An example: Both testing and unstable contain GNOME 1 and GNOME 2 libraries. testing: Package: App1 Version: 1-1 Depends: some GNOME1-libs Package: App2 Version: 1-1 Depends: some GNOME1-libs unstable: Package: App1 Version: 2-1 Depends: some GNOME2-libs Package: App2 Version: 2-1 Depends: some GNOME2-libs The way testing works, it's always possible for version 2-1 of App1 to enter testing while testing still contains version 1-1 of App2, or vice versa. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: mozilla 1.6b
On Thu, Dec 11, 2003 at 12:06:28PM -0700, Thomas E. Vaughan wrote: >... > I downloaded the source code and compiled Mozilla 1.6b > myself. Unfortunately, the configure script required that I > install libgtk1.2-dev, and no anti-aliasing joy whatsoever > was apparent. I have been assuming that mozilla-1.5 in > Debian was using gtk2 for anti-aliased widget text, but now > I'm just confused. > > Any help appreciated. Download the Mozilla 1.5 source package from Debian unstable and look at the configure options used in debian/rules . E.g. Mozilla defaults to Gtk 1.2, you have to give an explicit configure option to compile it with Gtk 2 . > Thomas E. Vaughan <[EMAIL PROTECTED]> cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: Bug#273734: education-common: con't fulfill the Recommends on !i386
On Mon, Oct 04, 2004 at 11:04:05PM -0400, Kevin Mark wrote: > Hi Adrian, > if 'boot-loader' was not a real package (not sure if it requires a new > catagory or if it fits under meta or virtual) and then when you did: > apt-get install boot-loader > it (dpkg or apt -- not sure) checked your ARCH and then install the one that > 'provides: boot-loader' and matches your ARCH > where > Package: lilo > Provides: boot-loader > Architecture: i386 and > Package: silo > Provides: boot-loader > Architecture: sparc > > And would install lilo on i386 and silo on sparc. The idea is that they > both provide similar functionality but are arch dependant. > > Not sure what to do if more than one package can satisfy the 'provides'. The problem in this specific case was, that a binary-all package wanted to have grub installed instead of lilo. Yes, you can solve some problems using virtual packages like boot-loader. No, you can't solve all problems using virtual packages like boot-loader. > Hope this is not too OT but I'm trying to understand under the hood. > -Kev cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Lowering the severity doesn't fix libvorbis0
severity 156227 grave thanks Hi Christopher, please explain why you think that it's not RC that packages depending libvorbis0 no longer run when upgrading libvorbis0 (the problem is similar to the recent libc6 <-> db breakage that will be fixed by a dependency of libc6 on libdb1-compat)? Your lowering of the severity to get your broken package into testing (it's now in testing...) is _not_ a solution. cu Adrian -- You only think this is a free country. Like the US the UK spends a lot of time explaining its a free country because its a police state. Alan Cox
Packages to run kernel 2.4.x on potato (release 27)
I have prepared the packages needed to run kernels up to 2.4.19 on a Debian 2.2r7 (potato) system. Please read [1] for more information. The updated kernel packages contain a fix for a i386 DoS attack that allows every user to crash the computer [2]. If you run older kernels on a computer where you don't fully trust all users it's highly recommended to upgrade the kernel. Changes in this release: + added: kernel-image-2.4.19-i386 Binary packages: o kernel-headers-2.4.19 o kernel-headers-2.4.19-386 o kernel-headers-2.4.19-586tsc o kernel-headers-2.4.19-686 o kernel-headers-2.4.19-686-smp o kernel-headers-2.4.19-k6 o kernel-headers-2.4.19-k7 o kernel-headers-2.4.19-k7-smp o kernel-image-2.4-386 o kernel-image-2.4-586tsc o kernel-image-2.4-686 o kernel-image-2.4-686-smp o kernel-image-2.4-k6 o kernel-image-2.4-k7 o kernel-image-2.4-k7-smp o kernel-image-2.4.19-386 o kernel-image-2.4.19-586tsc o kernel-image-2.4.19-686 o kernel-image-2.4.19-686-smp o kernel-image-2.4.19-k6 o kernel-image-2.4.19-k7 o kernel-image-2.4.19-k7-smp o kernel-pcmcia-modules-2.4.19-386 o kernel-pcmcia-modules-2.4.19-586tsc o kernel-pcmcia-modules-2.4.19-686 o kernel-pcmcia-modules-2.4.19-686-smp o kernel-pcmcia-modules-2.4.19-k6 o kernel-pcmcia-modules-2.4.19-k7 o kernel-pcmcia-modules-2.4.19-k7-smp + added: kernel-source-2.4.19 Binary packages: o kernel-doc-2.4.19 o kernel-source-2.4.19 + updated: initrd-tools (0.1.21 -> 0.1.32woody.2) + included blockdev in util-linux + removed: kernel-image-2.4.18-i386 + removed: kernel-source-2.4.18 cu Adrian [1] http://www.fs.tum.de/~bunk/kernel-24.html [2] http://security-archive.merton.ox.ac.uk/bugtraq-200211/0192.html -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Symlinking /usr/share/doc/ is not allowed
Several packages in Debian depend on another package and symlink their /usr/share/doc/ to the directory of this other package. Section 13.5. of your policy says: <-- snip --> 13.5. Copyright information --- Every package must be accompanied by a verbatim copy of its copyright and distribution license in the file `/usr/share/doc//copyright'. This file must neither be compressed nor be a symbolic link. ... <-- snip --> This seems to imply that making /usr/share/doc/ a symlink is wrong, too. Unless someone can convince me that my interpretation of your policy is wrong I'll start filing bugs against packages that symlink /usr/share/doc/ to the directory of another package. cu Adrian BTW: I'm not subscribed to debian-devel. -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: kernel-{image,headers} package bloat
On Tue, 24 Apr 2001, Aaron Lehmann wrote: > On Tue, Apr 24, 2001 at 07:27:42PM +1000, Herbert Xu wrote: > > In any case, binary modules are a fact of life I'm afraid. > > Bull. We are Debian, not fucking RedHat or Mandrake. We strive to > exist without non-free software and using its existance as an excuse > to make your packages far worse is a complete disgrace to the project. > > Linus doesn't support binary-only modules. He doesn't care about them. > That's why they break. This attitude is good. We should ignore > non-free software, or at least not give it enough attention to let it > hurt the quality of our free software packages. Your "we should ignore non-free software" sounds as if you disagree with the Social Contract? <-- snip --> We acknowledge that some of our users require the use of programs that don't conform to the Debian Free Software Guidelines. ... Thus, although non-free software isn't a part of Debian, we support its use, and we provide infrastructure (such as our bug-tracking system and mailing lists) for non-free software packages. <-- snip --> cu Adrian -- Nicht weil die Dinge schwierig sind wagen wir sie nicht, sondern weil wir sie nicht wagen sind sie schwierig.
Re: libc6 broken?
> * Taral <[EMAIL PROTECTED]> [010426 21:40]: > > On Thu, Apr 26, 2001 at 12:28:51PM +0200, Ulrich Wiederhold wrote: > > > If I try a ./configure or a "make xconfig" with a new Kernel, I get this > > > error-msg: > > > /lib/libc.so.6: undefined reference to [EMAIL PROTECTED]' > > > /lib/libc.so.6: undefined reference to [EMAIL PROTECTED]' > > > > Uh, why do you have libc 2.2.3? We don't have libc 2.2.3 in the archive. We have libc 2.2.3 in both unstableand testing: libc6 >= 2.2.2-2 is a CVS snapshot of 2.2.3 that defines this symbol: <-- snip --> $ objdump -p /lib/libc.so.6 ... Version definitions: 1 0x01 0x0865f4e6 libc.so.6 2 0x00 0x0d696910 GLIBC_2.0 3 0x00 0x0d696911 GLIBC_2.1 GLIBC_2.0 4 0x00 0x09691f71 GLIBC_2.1.1 GLIBC_2.1 5 0x00 0x09691f72 GLIBC_2.1.2 GLIBC_2.1.1 6 0x00 0x09691f73 GLIBC_2.1.3 GLIBC_2.1.2 7 0x00 0x0d696912 GLIBC_2.2 GLIBC_2.1.3 8 0x00 0x09691a71 GLIBC_2.2.1 GLIBC_2.2 9 0x00 0x09691a72 GLIBC_2.2.2 GLIBC_2.2.1 10 0x00 0x09691a73 GLIBC_2.2.3 GLIBC_2.2.2 Version References: required from ld-linux.so.2: 0x09691f71 0x00 15 GLIBC_2.1.1 0x09691a73 0x00 14 GLIBC_2.2.3 0x0d696911 0x00 13 GLIBC_2.1 0x0d696912 0x00 12 GLIBC_2.2 0x0d696910 0x00 11 GLIBC_2.0 $ dpkg --status libc6 Package: libc6 Status: install ok installed Priority: required Section: base Installed-Size: 8412 Maintainer: Ben Collins <[EMAIL PROTECTED]> Source: glibc Version: 2.2.2-4 ... <-- snip --> cu Adrian -- Nicht weil die Dinge schwierig sind wagen wir sie nicht, sondern weil wir sie nicht wagen sind sie schwierig.
Packages to run kernel 2.4.x on potato (release 11)
I have prepared the packages needed to run kernels up to 2.4.4 on a Debian 2.2r3 (potato) system. Please read [1] for more information. The most important change in this release are the new kernel-* packages (as always made by Herbert Xu) that include an important netfilter security fix. Changes since the last release: + added: chrony + added: hotplug + updated: iptables (1.2.1-1 -> 1.2.1a-2) + updated: kernel-image-2.4.3-i386 (2.4.3-1 -> 2.4.3-2) The following packages were removed because they are not really needed (there are other packages that you can use instead): o kernel-headers-2.4.3-pentiumiii o kernel-headers-2.4.3-pentiumiii-smp o kernel-image-2.4.3-pentiumiii o kernel-image-2.4.3-pentiumiii-smp + updated: kernel-source-2.4.3 (2.4.3-3 -> 2.4.3-4) + added a patch to umount in util-linux to prevent users from umounting partitions root has mounted (when the user option is set in /etc/fstab) + removed: usbmgr cu Adrian [1] http://www.fs.tum.de/~bunk/kernel-24.html -- Nicht weil die Dinge schwierig sind wagen wir sie nicht, sondern weil wir sie nicht wagen sind sie schwierig.
Re: Conflict: libgb
On Sun, 29 Apr 2001, Ben Burton wrote: >... > Of course there are no packages in Debian which use Gnome Basic either, > since this is its first packaging. You can compile gnumeric with support for Gnome Basic. > Ben. cu Adrian -- Nicht weil die Dinge schwierig sind wagen wir sie nicht, sondern weil wir sie nicht wagen sind sie schwierig.
Re: Two debconf issues
On Tue, 1 May 2001, David Whedon wrote: >... > In that case it would be that fact that perl-base is 'priority required' that > allows you to avoid a dependancy on perl rather than the fact that you are > using >... It's not the 'priority required' but the "Essential: yes" of perl-base that makes sure that the package is always installed (as an example, mawk is 'priority required' but not essential and I've removed it from my system a long time ago). > David cu Adrian -- Nicht weil die Dinge schwierig sind wagen wir sie nicht, sondern weil wir sie nicht wagen sind sie schwierig.
Re: ITH (Intent To Hijack) pilot-manager
On Wed, 2 May 2001, Chris Waters wrote: > Just wanted to let people know that I'm going to hijack the > pilot-manager package. The current maintainer seems to be completely > MIA; he hasn't uploaded a version in over a year. I emailed him and He seems to be MIA: How often did you try to contact him and how long ago? (always remember that most of us work for Debian in our spare time). > got no response. I use the package, and I did the most recent NMU. > I'm cc'ing him this message -- Darren, you can have it back for the > asking, but for now, it's mine, mine, all mine! Mwuah-ha-ha-ha-ha!! Haeh? This sounds a bit as if you are kidding... > Expect an upload as soon as I sort through the bug list a bit. > > cheers > > p.s. I wonder if we shouldn't add ITH as an official category in > WNPP. It's something that's probably going to come up more and more > as more developers become MIA over time. Martin usually marks packages of MIA maintainers as orphaned. I think it's better if a few persons take care of this instead of many more people sending ITHs. cu Adrian -- Nicht weil die Dinge schwierig sind wagen wir sie nicht, sondern weil wir sie nicht wagen sind sie schwierig.
Packages to run kernel 2.4.x on potato (release 12)
I have prepared the packages needed to run kernels up to 2.4.4 on a Debian 2.2r3 (potato) system. Please read [1] for more information. Changes since the last release: + added: isdnutils Binary packages: o ipppd o isdnactivecards o isdneurofile o isdnlog-data o isdnlog o isdnutils-doc o isdnutils-xtools o isdnutils o isdnvbox o isdnvboxclient o isdnvboxserver o libcapi20 o pppdcapiplugin + added: kernel-image-2.4.4-i386 Binary packages: o kernel-headers-2.4.4 o kernel-headers-2.4.4-386 o kernel-headers-2.4.4-586 o kernel-headers-2.4.4-586tsc o kernel-headers-2.4.4-686 o kernel-headers-2.4.4-686-smp o kernel-headers-2.4.4-k6 o kernel-headers-2.4.4-k7 o kernel-image-2.4.4-386 o kernel-image-2.4.4-586 o kernel-image-2.4.4-586tsc o kernel-image-2.4.4-686 o kernel-image-2.4.4-686-smp o kernel-image-2.4.4-k6 o kernel-image-2.4.4-k7 + added: kernel-source-2.4.4 Binary packages: o kernel-doc-2.4.4 o kernel-source-2.4.4 o mkcramfs + patched util-linux with the international kernel patch + removed: kernel-image-2.4.3-i386 + removed: kernel-source-2.4.3 cu Adrian [1] http://www.fs.tum.de/~bunk/kernel-24.html -- Nicht weil die Dinge schwierig sind wagen wir sie nicht, sondern weil wir sie nicht wagen sind sie schwierig.
About native packages
Hi, it seems to be a trend that maintainers try to change their packages to be Debian native. Policy says about native packages (in the chapter about version numbering): <-- snip --> This part of the version number specifies the version of the Debian package based on the upstream version. It may contain only alphanumerics and the characters `+' and `.' (plus and full stop) and is compared in the same way as the is. It is optional; if it isn't present then the may not contain a hyphen. This format represents the case where a piece of software was written specifically to be turned into a Debian package, and so there is only one `debianization' of it and therefore no revision indication is required. <-- snip --> >From this, it should be clear that it's wrong to make a package like xv where we haven't even the permission to distribute modified binaries Debian native (see #96458). It's different when the Debian maintainer is also upstream. It is argued that then there's only one `debianization'. That's all right but please consider the following cases before making your package Debian native: - Do you want to release a new upstream version to fix a missing build dependency? - When there's during a freeze a new version in unstable and you fix a bug in the version in frozen you have to make a split in your upstream development. One argument for native packages is that you want to include the debian/ directory in your upstream package. You can do this even in non-native packages and when you change nothing the .diff.gz will be empty - but it's possible for you to change only the Debian package without releasing a new upstream version. cu Adrian -- Nicht weil die Dinge schwierig sind wagen wir sie nicht, sondern weil wir sie nicht wagen sind sie schwierig.
Re: build depends on kernel-headers
On Sun, 6 May 2001, Herbert Xu wrote: >... > > the package not building with the changed kernel or not working after > > being installed at x*1000 machines? > > What is better is a sane local header that works with all kernels. I maintain util-linux that is a user space package that needs many kernel headers (and the package in unstable compiles only with 2.4 kernel headers). I do currently use the kernel haeaders libc6-dev ships. Would it be the right solution to copy the 2.4.4 kernel headers into the package and use them? cu Adrian -- Nicht weil die Dinge schwierig sind wagen wir sie nicht, sondern weil wir sie nicht wagen sind sie schwierig.
Re: build depends on kernel-headers
On Sun, 6 May 2001, Herbert Xu wrote: > > I maintain util-linux that is a user space package that needs many kernel > > headers (and the package in unstable compiles only with 2.4 kernel > > headers). I do currently use the kernel haeaders libc6-dev ships. Would > > it be the right solution to copy the 2.4.4 kernel headers into the package > > and use them? > > It needs to be looked at on a case-by-case basis. In general though, > if you need access to something that is not provided by glibc, you'll > have to setup a local header file and maintain it yourself as new > kernel releases come out. What do you suggest in my specific case with util-linux? > I wouldn't expect the Debian maintainer to have to go through this > though, as this is something that must be dealt with in the upstream > util-linux package. You mean every upstream source should ship it's own kernel headers? That's ugly and it reminds me that libtool does the same (every program tht uses libtool ships it's own copy of libtool) - and every time I compile a program that uses libtool under NetBSD/sparc-1.5 I must do a "libtoolize --force" to prevent a miscompilation of the libraries - it would be much more easy when the programs would use a locally installed libtool instead. cu Adrian -- Nicht weil die Dinge schwierig sind wagen wir sie nicht, sondern weil wir sie nicht wagen sind sie schwierig.
Finishing the FHS transition
Hi, I want to suggest to finish the FHS transition. This includes the following steps: - Packages with Standards-Version >= 3.0 must follow the FHS. Policy version 3.0.0.0 was released 30 Jun 1999 and I consider this enough time for every maintainer to switch to at least this Standards-Version. However, there are still 253 packages in unstable (including contrib, non-free and non-US/*) that have an older Standards-Version in the control file. The list (sorted by maintainer) follows below. Some of the maintainers are perhaps MIA, others are definitely not. If noone has a good argument against this I'll send RC bugs in one week to force the upgrade of the Standards-Version. - A change in the policy to remove the obsolete /usr/doc symlinks. List of packages with Standards-Version < 3.0 <-- snip --> Adam Di Carlo ([EMAIL PROTECTED]) onshore-timesheet Adam Klein ([EMAIL PROTECTED]) ncompress Alan Bain ([EMAIL PROTECTED]) nec Alex Romosan ([EMAIL PROTECTED]) f77reorder Alex Romosan ([EMAIL PROTECTED]) nte Alex Romosan ([EMAIL PROTECTED]) vat Alistair Cunningham ([EMAIL PROTECTED])xchain Anders Hammarquist ([EMAIL PROTECTED]) sformat Andreas Franzen ([EMAIL PROTECTED]) pgapack Anthony Fok ([EMAIL PROTECTED])lexmark7000linux Anthony Towns ([EMAIL PROTECTED]) cruft Anthony Towns ([EMAIL PROTECTED]) distributed-net-pproxy Apt Packaging Team ([EMAIL PROTECTED]) gnome-apt Araki Yasuhiro ([EMAIL PROTECTED]) kcc Arpad Magosanyi ([EMAIL PROTECTED])barracuda Avery Pennarun ([EMAIL PROTECTED]) apmd Avery Pennarun ([EMAIL PROTECTED]) netselect Avery Pennarun ([EMAIL PROTECTED]) wvdial Ben Gertzfield ([EMAIL PROTECTED]) gimp Ben Gertzfield ([EMAIL PROTECTED]) wmifs Bernd Schumacher ([EMAIL PROTECTED]) snmptraplogd Björn Brenander ([EMAIL PROTECTED]) tcputils Brad Bosch ([EMAIL PROTECTED])id-utils Brent A. Fulgham ([EMAIL PROTECTED]) bbmail Brent A. Fulgham ([EMAIL PROTECTED]) efuns Brent A. Fulgham ([EMAIL PROTECTED]) openacs Brian Bassett ([EMAIL PROTECTED])sml-nj C. Thomas ([EMAIL PROTECTED]) wmheadlines Carey W. Evans ([EMAIL PROTECTED])x3270 Chad Miller ([EMAIL PROTECTED]) sc Charles Briscoe-Smith ([EMAIL PROTECTED]) bock Charles Briscoe-Smith ([EMAIL PROTECTED]) cup Charles Briscoe-Smith ([EMAIL PROTECTED]) gramofile Charles Briscoe-Smith ([EMAIL PROTECTED]) infocom Charles Briscoe-Smith ([EMAIL PROTECTED]) int-fiction Charles Briscoe-Smith ([EMAIL PROTECTED]) jlex Charles Briscoe-Smith ([EMAIL PROTECTED]) libggidemos Charles Briscoe-Smith ([EMAIL PROTECTED]) propsel Charles Briscoe-Smith ([EMAIL PROTECTED]) recite Charles Briscoe-Smith ([EMAIL PROTECTED]) rocks-n-diamonds Charles Briscoe-Smith ([EMAIL PROTECTED]) saytime Charles Briscoe-Smith ([EMAIL PROTECTED]) strn Charles Briscoe-Smith ([EMAIL PROTECTED]) xggi Chris Leishman ([EMAIL PROTECTED]) cfs Chris Leishman ([EMAIL PROTECTED]) urlredir Christian Hammers ([EMAIL PROTECTED])myodbc2.50.26 Christian Leutloff ([EMAIL PROTECTED]) rxtx Christian Meder ([EMAIL PROTECTED]) afbackup Christian Meder ([EMAIL PROTECTED]) ftape-doc Christian Meder ([EMAIL PROTECTED]) ftape-tools Christoph Lameter ([EMAIL PROTECTED])wmf Christoph Martin ([EMAIL PROTECTED]) pgp5i Christophe Le Bars ([EMAIL PROTECTED]) doc-debian-fr Chu-yeon Park ([EMAIL PROTECTED])rat Clint Adams ([EMAIL PROTECTED]) set6x86 Craig Sanders ([EMAIL PROTECTED]) dlocate Craig Sanders ([EMAIL PROTECTED]) libdevel-symdump-perl Craig Sanders ([EMAIL PROTECTED]) libfile-tail-perl Craig Sanders ([EMAIL PROTECTED]) speedy-cgi-perl Craig Sanders ([EMAIL PROTECTED]) tkinfo Dale E. Martin ([EMAIL PROTECTED])tyvis Dale James Thompson ([EMAIL PROTECTED]) postilion Daniel Martin ([EMAIL PROTECTED])cqcam Daniel Martin ([EMAIL PROTECTED])tkdesk Darren Benham ([EMAIL PROTECTED]) wmcpu Darren Benham ([EMAIL PROTECTED]) wmdate Darren Benham ([EMAIL PROTECTED]) wmgrabimage Darren Benham ([EMAIL PROTECTED]) wmwe
Re: Finishing the FHS transition
On Sun, 6 May 2001, Oliver Elphick wrote: > Adrian Bunk wrote: > ... > >Oliver Elphick ([EMAIL PROTECTED]) libpgsql > > This package is obsolete and should not be included in any release. Please ask the ftp admins to remove the package from unstable (file a bug against ftp.debian.org). cu Adrian -- Nicht weil die Dinge schwierig sind wagen wir sie nicht, sondern weil wir sie nicht wagen sind sie schwierig.
Re: Finishing the FHS transition
On Sun, 6 May 2001, Chris Waters wrote: > > I want to suggest to finish the FHS transition. This includes the > > following steps: > > > - Packages with Standards-Version >= 3.0 must follow the FHS. > > Didn't we already have this discussion? The Standards-Version field > is not a reliable indication of much of anything. I strongly object Policy says: <-- snip --> In the source package's `Standards-Version' control field, you must specify the most recent version number of this policy document with which your package complies. The current version number is 3.5.4.0. This information may be used to file bug reports automatically if your package becomes too much out of date. <-- snip --> > to removing packages because of what amount to cosmetic issues, and an Where did I say that I want to remove the packages??? I said that I want to send bug reports. > incorrect Standards-Version (one that doesn't reflect the version of > policy that the package _actually_ complies with) is really no more > than a cosmetic issue (no software actually uses that field). "you must specify the most recent version number of this policy document with which your package complies": You must upgrade this field when your package complies with a more recent policy - and when your package does already comply with a more recent policy nothing more than an upload with an updated Standards-Version field is needed. > I only have a few of the listed packages installed on my system, but > most of the ones I checked did indeed use /usr/share/doc (and > /usr/share/man, in those cases where man pages were present). I > suspect that this is due to the use of debhelper, but anyway > > Checking for FHS violations should be done by checking for FHS > violations, not by checking an unreliable and all-but-meaningless > field in some configuration file. >... See above: I want to file a RC bug either because a) the package follows a too old policy or b) because it violates the _must_ in the polict that says that the Standard-Version must get updated. a) needs discussion whether we consider packages not following the FHS "too much out of date", b) is a violation of the policy that doesn't need discussion - that means the only question is whether anyone disagrees that we want to have all packages in unstable to follow the FHS. > cheers cu Adrian -- Nicht weil die Dinge schwierig sind wagen wir sie nicht, sondern weil wir sie nicht wagen sind sie schwierig.
Re: libggi2 and testing?
On Sun, 6 May 2001, Anthony Towns wrote: > On Sun, May 06, 2001 at 11:27:13PM +1000, Drew Parsons wrote: > > Is there any reason why libggi2 from unstable is not in testing? All > > architectures have now been compiled, being all present and up-to-date in > > the pool, but update-excuses gives no hints as to why it hasn't been > > accepted in testing. It (update-output) mumbles something incoherent about > > the package on alpha, but it's now been built for alpha. > > Yup, but the version on alpha depends libc6.1 >= 2.2.3-1 or so, and > libc6 2.2.3-1 doesn't build on i386... After two build failures (because of broken gcc and fileutils) it did finally build and I did upload it to incoming. If no new problems arise and Ben doesn't upload a new version it will go into testing in four days. > Cheers, > aj cu Adrian -- Nicht weil die Dinge schwierig sind wagen wir sie nicht, sondern weil wir sie nicht wagen sind sie schwierig.
Re: build depends on kernel-headers
On Mon, 7 May 2001, Herbert Xu wrote: > > What do you suggest in my specific case with util-linux? > > Which specific program in util-linux and what specific headers? >... (I tried my best but I can't garuantee this is 100% complete...) fdisk: linux/unistd.h linux/hdreg.h linux/blkpg.h linux/types.h linux/major.h cfdisk: linux/unistd.h linux/types.h linux/hdreg.h sfdisk: linux/unistd.h linux/hdreg.h mkswap: asm/page.h hwclock: asm/io.h asm/rtc.h asm/cuda.h linux/version.h linux/mc146818rtc.h linux/kd.h setterm: asm/ioctls.h mount + umount: asm/types.h asm/page.h linux/posix_types.h linux/loop.h linux/nfs.h linux/unistd.h linux/nfs_mount.h swapon: linux/unistd.h pivot_root: linux/unistd.h fdformat: linux/fd.h setfdprm: linux/fd.h raw: linux/raw.h linux/major.h fsck.minix: linux/fs.h linux/minix_fs.h mkfs.minix: linux/fs.h linux/minix_fs.h setterm: linux/unistd.h cytune: linux/tty.h linux/tqueue.h linux/cyclades.h linux/version.h dmesg: linux/unistd.h cu Adrian -- Nicht weil die Dinge schwierig sind wagen wir sie nicht, sondern weil wir sie nicht wagen sind sie schwierig.
Re: Finishing the FHS transition
On Sun, 6 May 2001, Chris Waters wrote: > > > Didn't we already have this discussion? The Standards-Version field > > > is not a reliable indication of much of anything. I strongly object > > > Policy says: > > "Policy says" doesn't make the packages comply. And you can file all > the bugs reports you want, but that doesn't magically fix the > packages. And until they're fixed, you can't use them as a reliable > indicator of FHS compatibility. QED. Standards-Version < 3 : a not FHS compliant package is at most a "normal" bug Standards-Version >= 3: a not FHS compliant package is at most a "serious" bug > We have many packages with old Standards-Versions which actually > comply with newer standards and *are* FHS compatible, and we have > packages with newer Standards-Versions that are NOT FHS compatible. Please file RC bug on packages with Standards-Version >= 3 that are not FHS compatible. > I think that if you really want to focus on FHS compatibility, you're > better off ignoring the Standards-Version issues for now. Its just > another can of worms. Picking the minimum Standards-Version for > release is something we normally do at freeze time. I think it's important that our packages follow a not too outdated policy and the "Standards-Version" field is the indicator for this. Freeze time is too late for picking the minimum Standards-Version for release - the right time would be shortly after the last stable was released. An example: It would be nice to have a minimum Standards-Version of 3.1 (that includes build dependencies), but you can't file 1060 RC bugs at the beginning of a freeze. >... > Note that the next paragraph mentions filing bug reports if the > package becomes "too much out of date". If any is too much, why > bother to say "too much"? You mustn't have to upgrade the Standards-Version field when your package doesn't comply with a more recent policy -> a package that doesn't follow FHS will never rech Standards-Version 3.0 . > > > to removing packages because of what amount to cosmetic issues, and an > > > Where did I say that I want to remove the packages??? > > I said that I want to send bug reports. > > RC bugs mean the package must be removed from the next release if it's > not fixed. Unless you can guarantee that the bugs will be fixed > (i.e., you're volunteering to fix them yourself), you _are_ asking for > package to be removed when you file RC bugs. These bugs are relatively easy to fix bugs and many of them will be fixed at a bug squashing party - and yes, I do fix many "easy to fix bugs" at each bug squashing party. But BTW: When a maintainer doesn't even when there's a RC bug starts to work on upgrading the package to comply with a policy that is nearly two years old there's the question of he's MIA. > Anyway, I apologize for a reminder I'm sure you don't need. It's just > a habit of mine, please forgive me. > > Bottom line, I think there remains a lot of work checking the subtle > and not-so-obvious stuff in the FHS before we can confidently claim > FHS compatibility (and even *begin* to work on actual compliance). Reading the last three sentence I'm glad to hear that you volunteer to do all this checks... >... > And I think mass filings of RC bugs would be premature at best. It's perhaps really late because we are relatively close too a freeze but it's definitely not premature. > cheers cu Adrian -- Nicht weil die Dinge schwierig sind wagen wir sie nicht, sondern weil wir sie nicht wagen sind sie schwierig.
Re: Finishing the FHS transition
On Mon, 7 May 2001, Anthony Towns wrote: >... > Standards-Versions aren't release critical. You can put it as > "Standards-Version: 526.7.8.9.13-Foo.6" if you want. And no matter what I will practice your suggestion and upload my packages with "Standards-Version: 526.7.8.9.13-Foo.6". > Standards-Version you have, you still have to follow the FHS, you have > to use /usr/share/doc, and if you specify build-dependencies they have > to be correct. That means you can file RC bugs on all packages that don't follow the FHS, independent from the Standards-Version? > Cheers, > aj cu Adrian -- Nicht weil die Dinge schwierig sind wagen wir sie nicht, sondern weil wir sie nicht wagen sind sie schwierig.
Re: Finishing the FHS transition
On Mon, 7 May 2001, Torsten Landschoff wrote: > On Mon, May 07, 2001 at 12:53:50AM +0100, Martin Michlmayr wrote: > > > Package: gsfonts > > Maintainer: Torsten Landschoff <[EMAIL PROTECTED]> > > 91489 Package gsfonts still has at least one file in /usr/doc > > Package is ready so far and installed locally. But I can't build a > new package since /usr/bin/install suddenly decided to stop working *arg* >... This bug is fixed in fileutils version 4.1-2 that is in the archive since yesterday evening. > cu > Torsten cu Adrian -- Nicht weil die Dinge schwierig sind wagen wir sie nicht, sondern weil wir sie nicht wagen sind sie schwierig.
Re: Woody Freeze Plans - Progress Report II
On Mon, 7 May 2001, Anthony Towns wrote: >... > There are four ports, any of which may want to try for a woody release: > hurd-i386, mips, hppa and ia64. If they do, they need to ensure that >... I did perhaps only miss it: You did post some weeks ago a list how much each architecture is keeping up with unstable (how many % of the packages in unstable are compiled on this architecture). Is there a website with these figures regularly updated for all ten architectures (six in potato plus the four you mention here)? > Cheers, > aj Thanks in advance Adrian -- Nicht weil die Dinge schwierig sind wagen wir sie nicht, sondern weil wir sie nicht wagen sind sie schwierig.
Re: Giram: Request for removal
On Mon, 7 May 2001, Henrique de Moraes Holschuh wrote: >... > Jérôme, could you please file a ITO (intent to orphan) or maybe even a O: >... s/ITO/RFA/ (Request for adoption) cu Adrian -- Nicht weil die Dinge schwierig sind wagen wir sie nicht, sondern weil wir sie nicht wagen sind sie schwierig.
Re: Woody Freeze Plans - Progress Report II
On Mon, 7 May 2001, Roland Bauerschmidt wrote: > Adrian Bunk wrote: > > I did perhaps only miss it: You did post some weeks ago a list how much > > each architecture is keeping up with unstable (how many % of the packages > > in unstable are compiled on this architecture). Is there a website with > > these figures regularly updated for all ten architectures (six in potato > > plus the four you mention here)? > > http://ftp-master.debian.org/testing/testing_outdate.txt (resp. > unstable_outdate.txt) shows which packages are out of date and at the > end there seem to be some statistics... What do entries like mozilla M18-3 libnspr3(i386) M14-2 from M14-2 mozilla M18-3 libnspr3-dev(i386) M14-2 from M14-2 mean? And I'm more interested in statistics about how many packages are out out of date on each architecture in _unstable_ like the figures ajt posted some weeks ago - I want to see which autobuilders have problems and need perhaps help. > Roland cu Adrian -- Nicht weil die Dinge schwierig sind wagen wir sie nicht, sondern weil wir sie nicht wagen sind sie schwierig.
RFA: gv -- A PostScript and PDF viewer for X using 3d Athena Widgets
Package: wnpp Version: N/A; reported 2001-09-09 Severity: normal I offer gv (and if you want xaw3dg, too) for someone who has more knowledge in both gs and C to fix some of the bugs (upstream is dead since four years). I do not intend to give this package to the first one who says "I want to adopt gv" - I will continue to maintain gv until someone wants to adopt it who knows to fix at least some of the outstanding bugs. Please contact me first if you want to adopt gv. cu Adrian -- Get my GPG key: finger [EMAIL PROTECTED] | gpg --import Fingerprint: B29C E71E FE19 6755 5C8A 84D4 99FC EA98 4F12 B400
Re: sox sucks !
On Fri, 14 Sep 2001, Eric Van Buggenhaut wrote: > I'm unable to find out why this command actuall doesn't work : > > mpg123 -s audio/01_Birdland.mp3 | sox -r 44100 -s -w -c2 - \ > audio/01_Birdland.wav > > > The idea is basically to convert a .mp3 to a .wav > > Has anyone a hint ? What does this have to do with the development of Debian? Please don't use debian-devel for questions that don't belong here (you can e.g. ask at a user list of sox or you can ask the Debian maintainer of sox privately). > Thanks. > > Please CC me cu Adrian -- Get my GPG key: finger [EMAIL PROTECTED] | gpg --import Fingerprint: B29C E71E FE19 6755 5C8A 84D4 99FC EA98 4F12 B400
Re: Processed: Fixed in NMU of tkstep8.0 8.0.4p2-4.1
On Fri, 28 Dec 2001, Debian Bug Tracking System wrote: > Processing commands for [EMAIL PROTECTED]: > > > tag 126700 + fixed > Bug#126700: tkstep8.0: never removes alternative > Tags added: fixed Why on earth do you make a NMU for my package less than 24 hours after the original bug report and without asking me before doing so??? It's clear that the bug you fixed needed to be fixed but it's definitely wrong to NMU without contacting me as the maintainer first. Additionally I see that you did other changes to unix/tkstepConfig.sh that aren't even mentioned in the changelog! NEVER DO THIS AGAIN! Adrian
Re: Quake 2 sources GPL'd
On Sat, 22 Dec 2001, Branden Robinson wrote: >... > In fact, I would consider it acceptable in general to move everything in > contrib to main as long as it each package was forced to be priority > extra until it was suitable for general-purpose use as packaged in main > (including any dependencies, of course). >... If I understand it correctly you suggest to move e.g. the package below to main? I always thought that the reason for contrib was to make a place for free software that needs non-free software/data/... to run. If we move these packages to main this would mean to put software to main that is either not installable or that doesn't run without installing additional software/data/... The priority extra doesn't help that e.g. a user who wants to use only software from main will see the fact that some of the packages he tries to choose e.g. in dselect aren't installable. That's something I consider worse for our users than the current state with a contrib section for exactly these packages. <-- snip --> Priority: optional Section: contrib/web Installed-Size: 28 Maintainer: Ryan Murray <[EMAIL PROTECTED]> Architecture: i386 Source: netscape4.base Version: 1:4.77-2 Depends: navigator-smotif-477,netscape-java-477,netscape-base-4 ... Description: Meta package that depends on other packages This package depends on the real netscape packages, so as to make things easier for people to install. meta-package: yes <-- snip --> cu Adrian
Re: Bug#127252: -unstable compiled against the wrong libpng
On Thu, 3 Jan 2002, Henrique de Moraes Holschuh wrote: >... > We actually need a Debian-wide (well, probably a LSB-wide) fix for the > problem. The same kind of breakage is expected to hit us again and again > until we do that. This kind of problem does only occur if we ship several versions of a shared library at the same time (in this case libpng2 and libpng3). As soon as there's only one version of such a library in the archive (IOW: libpng2 is removed from the archive) all the packages depending on this library that still link with the old version of the library become uninstallable which means that they need to be recompiled. This prevents us from all the obvious or silent breakages we do see otherwise. cu Adrian
Some thoughts about problems within Debian
Hi, I had several discussions with people on Debian lists that became very emotional. They thought that they were right in a discussion and I thought that I was right and nothing but anger resulted from these discussions. Several times the "opponents" in these discussions are people that are longer in Debian than I am and that do a damn good work in the area(s) they are working for Debian and I do acknowledge this even when they call me a troll. I try to summarize the most important points below - not because I consider it important that I'm right but because these are IMHO very serious problems in Debian. Please read it, try to understand it and make your own opinion of whether I'm right or wrong. When I see problems somewhere I tell them even in the case when I don't know a solution - IMHO pointing to a problem is something valuable to help improving something. I do often try to see the point of view of the people we are doing our work for - our users. Everything I mention below isn't meant to offend against anyone personally. Debian becomes bigger and bigger. We do currently have over 900 people maintaining over 8000 binary packages [1] and there are currently over 350 RC bugs in packages that are in testing [2] plus many more in packages that were either removed from testing or never made it into testing. Debian is well-known for high-quality releases and I consider it important to preserve the high quality though we have so many different people maintaining so many packages. One important thing are more frequent releases. We don't have to release as often as other distributions but IMHO it's needed to have a new stable release at about once a year. Currently the software in our stable release is two years old and I see several distributors and magazines already ship woody CDs instead of potato CDs although we are still several months away from releasing woody - and if people encounter problems with the packages they find there this does in the long term harm the good reputation of the quality of our packages. There are many reasons why you need packages you can't find in potato. Sometimes it's only that you want to use Gimp 1.2 but often there are important reasons like e.g. support for kernel 2.4 or Euro support in some applications. Using testing isn't an alternative on many production systems because testing reduces the probality of bugs but it could still happen that e.g. your X does no longer start after your latest upgrade to testing. In Debian a package normally belongs to exactly one maintainer. The possiblity to overrule the technical decision a maintainer makes and to force a maintainer to e.g. implement a proposed solution from a bug report is mostly theoretical. This maintainer-centric approach gives very much power to a maintainer and I think that there also an obligation for a maintainer to take care of his packages. Most of us who work for Debian do this in our spare time. But I do personally disagree with the "you can't force a volunteer to do anything" argument I heard in several discussions. These were discussions about things where some work of the maintainer who is responsible for his package would save work for other people who do volunteer work for Debian or to improve the general quality of Debian for our users. Examples are e.g.: - Old RC bugs that are easy to fix. These bugs need someone to do a NMU and I'm often negative surprised in bug squashing parties how many RC bugs that are open for more than one month are easy to fix because there's e.g. only a missing build dependency. This makes it harder to get Debian in a state to release and it takes time at bug squashing parties to fix these bugs - time you could otherwise use to try to fix other bugs. Additionally one buggy package might prevent many other packages from entering testing which is very frustrating for the maintainers of the packages that don't make it into testing because of this. - Make debconf mandatory for all packages that interact with the user while installing/removing a package in woody+1. One positive effect would be for the user that he doesn't has to answer questions several times during the installation of the packages - he can instead go to drink a cup of tea after he answered the debconf questions that come en bloc. Another positive effect is that this makes life easier for everyone working on automatic installations of Debian. Don't misunderstand me: I know that a package maintainer also has "real life" things to do that might have higher priorities for him personally. On the other hand he is responsible for the packages he maintains and IMHO this implies that we can expect from a maintainer that he tries to fix RC bugs in his packages at least once a month and to try to fix the other bugs in his packages from time to time [3]. If it's generally agreed that all packages should comply with with something that is generally considered important I think it's OK to
Re: Bug#127252: -unstable compiled against the wrong libpng
On Thu, 3 Jan 2002, Henrique de Moraes Holschuh wrote: > > This kind of problem does only occur if we ship several versions of a > > shared library at the same time (in this case libpng2 and libpng3). As > > Or if the user needs to have different versions of said library because of > some closed-source (or not easily recompilable) library. However, it is a >... Closed-source programs and libraries are not a problem if the library we are talking about is copyrighted under the terms of the GPL (like libpng). cu Adrian
Re: Bug#127252: -unstable compiled against the wrong libpng
On Thu, 3 Jan 2002, Steve Langasek wrote: > On Thu, Jan 03, 2002 at 11:47:08PM +0100, Adrian Bunk wrote: > > > Closed-source programs and libraries are not a problem if the library we > > are talking about is copyrighted under the terms of the GPL (like libpng). > > My reading of /usr/share/doc/libpng2/copyright is that the *packaging* > has been placed under the GPL, but that the library itself is > distributed under a BSD license. Is this not the case? Ups, yes, you are right. > Steve Langasek cu Adrian
Re: at least 260 packages broken on arm, powerpc and s390 due to wrong assumption on char signedness
On Fri, 4 Jan 2002, Steve Greenland wrote: > > If every system had up-to-date, standards-conforming > > ctype.h support, we wouldn't have to worry much at all. > > But even these days, pretty many systems with buggy macros > > are still in use. > > Then fix those systems. Pull the necessary stuff out of glibc and use > it rather than the system headers/libc. You need to do this in a portable way so that it works on every system... > > FYI, as far as I know, the most portable way to use > > the ctype macros is to define wrapper macros > > (e.g., like those below, from fileutils/src/sys2.h) > > and then use only the wrappers (upper-case names) from your code. > > > What an abomination. I spent way too much of my youth doing crap like > this. I'm tired of it. The standard has been in place for 12 fscking > years. If the vendors aren't going to support it, then those systems > are dead. I've better things to do with my time than make ugly code to > support systems that haven't been upgraded for over a decade. > It's the choice of the author of a program whether he wants to support older systems or not - and if he wants to support older systems (and many older systems are still running) or systems that don't confirm to a standard he won't accept patches that limit the number of systems his program runs on. I remember that e.g. many GNU programs still support pre-ANSI C compilers. > Steve cu Adrian
Re: no space left on device: LVM, Gnus --> dpkg, apt-get ?
On Sun, 6 Jan 2002, Egon Willighagen wrote: >... > That makes me wonder: is it possible that i am imagening things, and that the > upgrade went well, even though my HD was full? Did it actually install files > then, or did it not overwrite, because of the HD being full, and my files are > basically not upgraded, but just the version numbers in the index that dpkg > uses? Do you mean with "my HD was full" that "df" says that it's used 100% ? If yes then your HD isn't physically full, usually 5% of the blocks in a partition are reserved - this means they aren't counted when "df" estimates how many space is free on the device and only root can write to the device if not more than the number of reserved blocks are free. Since you did run dpkg as root you can write additional files to the partition even though the partition is full. > Egon cu Adrian
Re: CHECK BEFORE YOU RETITLE Re: Processed: Retitling...
On Sat, 5 Jan 2002, Adam Majer wrote: > Hey, buddy!! I ITA those packages a while back - I'll be uploading them in > the next day!!! PLEASE CHECK THE O LIST > __BEFORE__ YOU RETITLE A BUG! Hi Adam, it seems you misunderstood what Uwe was doing: He did only add the package descriptions to the WNPP bugs, IOW he changed e.g. ITA: gtml to ITA: gtml -- An HTML pre-processor or O: wmf to O: wmf -- Web Mail Folder These changes are visible e.g. in the wookly work-needing packages report or at the WNPP pages at [1]. Uwe never intended to adopt any of these packages. > - Adam cu Adrian [1] http://www.debian.org/devel/wnpp/
Re: Still no fam in Woody
On Sat, 5 Jan 2002, Petter Reinholdtsen wrote: > The current excuse for 'fam' in > http://ftp-master.debian.org/testing/update_excuses.html.gz> is > > - fam (- to 2.6.6.1-4) > * Maintainer: Joerg Wendland > * 16 days old (needed 10 days) > * fam/hppa unsatisfiable Depends: libstdc++3 (>= > 1:3.0.3-0pre011215) ['gcc-3.0'] > * Valid candidate > * Depends: fam gcc-3.0 > > Why is it still not included in Woody? Several kde and gnome packages > depend on this package, and it would be nice if it make it into Woody > soon. > > I do not understand the unsatisfiable depend error. The program was > successfully compiled on hppa. Is the problem gcc-3.0 >= > 3.0.3-0pre011214 missing in Woody? This seem to be a problem on arm > and m68k, and should not affect hppa, or am I mistaken? short answer: fam won't go into woody as long as the build errors of gcc-3.0 on arm and m68k aren't fixed. long answer: fam was compiled with a recent libstdc++3-dev on hppa so you got a dependency on libstdc++3 (>= 1:3.0.3-0pre011215). This dependency can't be fulfilled inside woody at the moment. The way testing works is that fam won't get into woody until a recent enough libstdc++3 is in testing. It doesn't matter whether the problems that keep the new libstdc++3 from entering testing are build problems on other architectures, RC bugs in any package built from the gcc-3.0 source package or dependency problems that arise when the binary packages from gcc-3.0 enter testing. cu Adrian
Re: Still no fam in Woody
On Sun, 6 Jan 2002, Joerg Wendland wrote: >... > > I do not understand the unsatisfiable depend error. The program was > > successfully compiled on hppa. Is the problem gcc-3.0 >= > > 3.0.3-0pre011214 missing in Woody? This seem to be a problem on arm > > and m68k, and should not affect hppa, or am I mistaken? > > The problem is that FAM does only on hppa depend on libstdc++3 for on > that arch there is no gcc-2.9x. The buildd runs on unstable. The libstdc++3 > version there 3.0.3-1 (would fit) but its version in testing is 3.0.2-4. > And since gcc-3 is out of date on other arches this situation will last > on it seems. A solution were to compile FAM against the testing libstdc++3 > and reupload but I dunno if such is possible. It seems ajt manually forced gcc-3.0 into testing although the packages on m68k and arm were still missing. Because of this, fam is now in testing, too. :-) > Regards, Joerg (maintainer of fam) cu Adrian
Re: why is 'dbf' in non-free?
On Mon, 7 Jan 2002, DvB wrote: > I ran a search for dbf (xbase) packages in debian and came up with the > 'dbf' package which is in non-free. > If it's in non-free because of licensing issues with the Xbase format, >... If you lok at the copyright notice (debian/copyright in the source or /usr/share/doc/dbf/copyright if you have installed the dbf package) it seems that the problem isn't the Xbase (there are other free programs like e.g. Gnumeric that support this format) but the non-free licence of libdbf (but this doesn't affect you when writing your own dbf library): <-- snip --> Copyright: DBF - xbase manipulation package Copyright (c) Brad Eacker, 1991, 1992, 1993, 1994 Permission is granted to distribute and use the source, documentation files and/or compiled binaries associated with dbf for non-commercial use. No charges may be made for such distributions. ... <-- snip --> > TIA cu Adrian
Re: Appropriate? mutt/mailx requires mail-transport-agent
On Mon, 7 Jan 2002, Craig Dickson wrote: > > Perhaps creating a new package, eg. 'mutt-reader' with no MTA dependency, > > could solve this problem. > > Would the only difference between mutt and mutt-reader be that one > dependency? If so, then it would be better, I think, to simply change > "Depends: mail-transport-agent" to "Recommends: mail-transport-agent" > in the existing mutt package, and not create a new mutt-reader package. This might cause problems some all the users that simply "apt-get install mutt". If you have a problem with the mail-transport-agent dependency and you know what you are doing it's pretty easy to use /usr/share/doc/equivs/examples/mail-transport-agent.ctl to build a dummy mta package. > Craig cu Adrian
Packages to run kernel 2.4.x on potato (release 22)
I have prepared the packages needed to run kernels up to 2.4.17 on a Debian 2.2r4 (potato) system. Please read [1] for more information. Changes since the last release: + added: kernel-image-2.4.17-i386 Binary packages: o kernel-headers-2.4.17 o kernel-headers-2.4.17-386 o kernel-headers-2.4.17-586tsc o kernel-headers-2.4.17-686 o kernel-headers-2.4.17-686-smp o kernel-headers-2.4.17-k6 o kernel-headers-2.4.17-k7 o kernel-image-2.4.17-386 o kernel-image-2.4.17-586tsc o kernel-image-2.4.17-686 o kernel-image-2.4.17-686-smp o kernel-image-2.4.17-k6 o kernel-image-2.4.17-k7 + added: kernel-source-2.4.17 Binary packages: o kernel-doc-2.4.17 o kernel-source-2.4.17 o mkcramfs + added: xfsprogs Binary packages: o xfslibs-dev o xfsprogs + updated: e2fsprogs (1.22-1 -> 1.25-1) + updated: isdnutils (1:3.1pre1b-8 -> 1:3.1pre1b-27) + updated: modconf (0.2.32 -> 0.2.39) + updated: pcmcia-cs (3.1.27-2 -> 3.1.29-4) + removed: kernel-image-2.4.14-i386 + removed: kernel-source-2.4.14 cu Adrian [1] http://www.fs.tum.de/~bunk/kernel-24.html
Re: Processed: Fixed in NMU of tkstep8.0 8.0.4p2-4.1
On Thu, 3 Jan 2002, LaMont Jones wrote: > > Additionally I see that you did other changes to unix/tkstepConfig.sh that > > aren't even mentioned in the changelog! > > Here is the complete diff between what I uploaded, and what was in the > archive. Dunno what change you're seeing in tkstepConfig.sh, but it > was there in 4p2-4. I see why I saw the changed file: The file is generated during the buld of the package. My mail was perhaps a bit too fast because I was (and I'm still a bit) very angry that you did NMU less than 24 hours after I got the bug report and without contacting me before - being angry is unfortunately not the best thing for thinking rationale about why something happened... > lamont cu Adrian
RE: Bug#128077: Please mention native source packages in maint-guide
On Sun, 6 Jan 2002, Yves Arrouye wrote: > Thanks for the explanation. Well, ICU is definitely not developed > specifically for Debian, but since I am one of the upstream developers, I > found it convenient to have the debian/ directory in it, not just for me but > for anybody who would want to grab ICU from the CVS and build a .deb for it. This doesn't mean that you can't include the debian/ subdirectory in the upstream sources - if the debian/ subdirectory is complete and the package is non-native the diff.gz is perhaps simply empty. > So I guess that as long as the explanation in maint-guide says that a native > Debian package is a package that builds with no modifications, not just a > package developed specifically for Debian, it will be clear for everybody. I've already discussed several times why this it is bad to package programs as native packages although they aren't written specifically for Debian. Consider e.g. the following examples: - To fix a missing build dependency you have to release a new upstream version of your program. - If your package is in stable and there's already a newer version of it in unstable you have to create a seperate branch of upstream development when you backport a fix to the package in stable (this is perhaps a bit hairsplitting...). Compare these oddities with the fact that there are _no_ problems for you to package your program non-native while including a complete debian/ subdir in the upstream version and I hope you understand why it's better to package your program non-native. > YA cu Adrian
Re: [ccheney@cheney.cx: libqt2 libpng2 resolution]
On 7 Jan 2002, Philippe Troin wrote: > Chris Cheney <[EMAIL PROTECTED]> writes: > > > On Mon, Jan 07, 2002 at 05:06:27AM -0800, Philippe Troin wrote: > > -snip- > > > > > > Sounds good to fix all the current problems... however how are we > > > going to handle the libpng2 -> libpng3 conversion ? Your solution just > > > seems to postpone the problem. > > > > libqt 3.x already uses libpng3 so that looks like a good conversion spot. > > Sounds good to me. > > How do you plan to prevent programs that link with libqt2 to also link > with libpng3 ? Manual check ? Another possiblility is the following (only the new dependencies are listed): Package: libqt2-dev Conflicts: libpng3 Build-Conflicts: libpng3 [note that libpng3 is the library package _not_ the -dev package] This way neither a program that links with libqt2 nor a library libqt2 is linked with can be linked with libpng3. > Phil. cu Adrian
Re: potatoe 2 woody & kernel-sources remarks
On Tue, 8 Jan 2002, François Chenais wrote: > Hello, Hi François, >... > * i've downloaded the kernel-source-2.4.17 but I have an error in > network.o > when linking the kernel. > I don't remember the exact error because I'm not actually using the good > disk on my laptop. The new binutils in woody surfaced a bug in the kernel that is mostly but not completely fixed in kernel 2.4.17. A fix for your problem might be to go to the "Networking options/IP: Netfilter Configuration" submenu and to disable "Basic SNMP-ALG support". BTW: debian-user@lists.debian.org is the right list for this kind of questions. > Hope this help you for the wonderfull work on debian. > > Thanks a lot. > > > François cu Adrian
Re: We still need sponsors!
On Wed, 9 Jan 2002, Tille, Andreas wrote: >... > OK. If I understand this right that would mean that the control file > would state > > Maintainer: Future Maintainer <[EMAIL PROTECTED]> no, the control field states: Maintainer: My Name <[EMAIL PROTECTED]> Where "My Name <[EMAIL PROTECTED]>" is a working email address of the maintainer of the package. When he gets his account he can change the maintainer field to his @debian.org address in the next upload - or he could leave the other email address (if you look at my packages you'll find that I never use my @debian.org address). > and my own address will be in the changelog (like in an NMU). Where > is the place to make clear that: >"The package is called a sponsored package ..." > Are there any fields/conventions? The way I prefer is: The maintainer makes the package as if he was an official developer. The sponsor rebuilds the package, checks it, and if it's OK he signs it with his key (using "debsign -m") and uploads it. Note that the name of the sponsor doesn't appear anywhere except in the gpg signature of the .changes and the .dsc files and there's nothing that makes the upload look like a NMU. If you want to make it clear that the upload is sponsored an entry in the changelog should be the right solution. Before I became a maintainer I added to the changelog entry of every package that was sponsored for me a line * Upload sponsored by Tony Mancill <[EMAIL PROTECTED]>. > Kind regards > > Andreas. >... cu Adrian
Re: [ccheney@cheney.cx: libqt2 libpng2 resolution]
On Wed, 9 Jan 2002, Daniel Stone wrote: > > > How do you plan to prevent programs that link with libqt2 to also link > > > with libpng3 ? Manual check ? > > > > Another possiblility is the following (only the new dependencies are > > listed): > > > > Package: libqt2-dev > > Conflicts: libpng3 > > Build-Conflicts: libpng3 > > > > [note that libpng3 is the library package _not_ the -dev package] > > > > > > This way neither a program that links with libqt2 nor a library libqt2 is > > linked with can be linked with libpng3. > > What? That means that you can't have a libpng3 program on a machine with > libqt2-dev installed ... icky. Yes, but that's the only way I see to ensure that there aren't some ugly problems like e.g. Package: abc Depends: libqt2, libxyz Package: libqt2 Depends: libpng2 Package: libxyz Depends: libpng3 > -d cu Adrian
Re: Musixtex not going into testing?
On Thu, 10 Jan 2002, Tille, Andreas wrote: > Hello, Hi Andreas, >... > have access to a sparc. Is there any description how to proceed > for uploads of the same package for other architectures? The "-B" option of dpkg-buildpackage does what you want to do. If you don't have your GPG key on the sparc machine it works as follows: sparc-machine> dpkg-buildpackage -B -uc -rfakeroot sparc-machine> scp ... your-machine> debsign changes your-machine> dput/dupload changes > Kind regards > > Andreas. cu Adrian
Re: [ccheney@cheney.cx: libqt2 libpng2 resolution]
On Wed, 9 Jan 2002, Adam Heath wrote: > > > What? That means that you can't have a libpng3 program on a machine with > > > libqt2-dev installed ... icky. > > > > Yes, but that's the only way I see to ensure that there aren't some ugly > > problems like e.g. > > No, completely wrong. You want to keep the -dev packages from being installed > at once. It's the -dev package for a library that says what a program gets > linked to. Just having the library on the machine does not mean packages can > be linked to it. > > Get a clue. I didn't get it yet. To put my example for an "ugly problem" in words: A program links with two libraries. One of them has an inter-library dependency on libpng2, the other one has an inter-library dependency on libpng3. AFAIR the -dev packages of these libraries don't necessarily have to depend on libpng*-dev. Is the last sentence wrong or where else am I wrong? TIA Adrian
Re: We still need sponsors!
On 9 Jan 2002, Thomas Bushnell, BSG wrote: >... > Is there an easy web page to point people at, where people could > request sponsorship and sponsors could advertise their availability? That's exactly what [1] is for (BTW: there's a link to this page from the Developers' Corner [2]). cu Adrian [1] http://www.internatif.org/bortzmeyer/debian/sponsor/ [2] http://www.debian.org/devel/
Re: SUGGESTION: Re: Some thoughts about problems within Debian
On Thu, 10 Jan 2002, Ola Lundqvist wrote: > On Thu, Jan 03, 2002 at 11:24:12PM +0100, Adrian Bunk wrote: > > [3] "tries to fix" means that he looks into the bug. I do expect a > > maintainer to be able to fix a "missing build dependency on xyz" bug > > or to forward the bug to upstream. OTOH it's clear that there are > > cases where the maintainer can't do much about a bug (e.g. there's an > > inactive/dead upstream and he can't fix a bug in the source himself). > > Hi Hi Ola, > I have a suggestion to make it easier for others to fix such problems. > > One thing is a additional tag to the bug-database. HELP-NEEDED or > some other similar name. This tag should be added to a package when > the maintainer can not resolve the bug him/her-self. It is similar > to the moreinfo tag but requests for help from other people than the > submitter. the "help" tag already present and exactly for this purpose: help The maintainer is requesting help with dealing with this bug. > Maybe also add NMU-ACCEPTED to the list of tags in the bugs-database. > It will be added for a package that the maintainer accepts NMU:s for > this bug (but probably want a patch too). >... I can't see the big advantage of such a tag: You can keep the information that the maintainer accepts NMUs for a bug in the bug log (and before doing a NMU you have to read the complete log of the bug(s) you intend to fix). > Regards, > > // Ola cu Adrian
Re: We still need sponsors!
On Fri, 11 Jan 2002, Eric Van Buggenhaut wrote: > Since the person who upload the package is not the maintainer, it is actually > a > non-maintainer upload, isn't it ? No, the maintainer of the package is the person who gets sponsored (he's the maintainer of this package although he isn't yet an official developer). It's a bit similar e.g. to the case that you are somewhere at a conference and don't have your GPG key available but you want to fix a bug in one of your packages. You can then prepare your package and another developer who has his laptop with his GPG key available signs your package. cu Adrian
Re: Work-needing packages report for Jan 11, 2002
On Sat, 12 Jan 2002, Daniel Stone wrote: >... > qt-x11 is qt2, qt-x11-free is qt3. Chris has been busy getting Qt2 and > KDE2.2 working fully before he turns his attention to Qt3 and KDE3. His > hard drive just also died, so give him a little breathing room. He should retitle the WNPP bug(s) to RFA to indicate that he intends to adopt. cu Adrian
Re: Work-needing packages report for Jan 11, 2002
On 11 Jan 2002, Tollef Fog Heen wrote: >... > |giram (#96740), offered 247 days ago > | Description: 3D modeller for POV-Ray > > Wasn't this one supposed to be removed from the archive if no one > picked it up? Why? - the version currently in unstable does build - there are no open bugs - upstream is alive cu Adrian [1] http://people.debian.org/~apenwarr/popcon/results.graphics.html
Packages to run kernel 2.4.x on potato (release 23)
I have prepared the packages needed to run kernels up to 2.4.17 on a Debian 2.2r5 (potato) system. Please read [1] for more information. Changes in this release: + fixed the bug that isdnutils erased /etc/services if you were affected by this bug copy the file you can find at [2] to /etc/services Sorry for any inconveniences caused by this bug! + updated: ksymoops (2.4.0-1 -> 2.4.3-1.1) cu Adrian [1] http://www.fs.tum.de/~bunk/kernel-24.html [2] http://people.debian.org/~bunk/services
Re: About sponsoring non-free packages
On 14 Jan 2002, Jérôme Marant wrote: > Hi, Hi Jérôme, > I propose that we do not sponsor people for non-free packages. > People that we want to join us and seeking sponsors for > non-free package are showing that they do not understand > our philosophy and dedication to Free Software. do you also implicitely say that I "do not understand our philosophy and dedication to Free Software" because I do maintain a non-free package (xsnow)? It's clear that free software is better than non-free software but please don't forget that you agreed that "We will support our users who develop and run non-free software on Debian". cu Adrian
Will woody ever become stable?
Hi, I had a longer discussion with our release manager who said in this discussion that there's no progress in the freeze of woody. We won't enter the next stage of the freeze until the base and standard packages are in a releasable state - and the number of RC bugs in these packages is increasing (one reason is e.g. that some of these packages like boot-floppies break when new upstream versions of other packages they depend on are uploaded which may lead to RC bugs like #127405). woody is officially frozen for several months but it's still possible for new upstream versions of every package to enter testing. My personal motivation goes down to zero because I did try to get my own packages in a releasable state when the freeze was announced the first time at about one year ago and I participated in several bug squashing parties and I did go through RC bug lists at other times to help to get woody released only to see that the freeze stalled soon later. It seems noone really cares to get woody released. What am I doing all my work for Debian for when woody will never become stable? cu Adrian
Re: Will woody ever become stable?
On Tue, 15 Jan 2002, Jules Bean wrote: >... > > officially frozen for several months but it's still possible for new > > upstream versions of every package to enter testing. >... > I really don't feel in-touch with how the freeze is going, and I > imagine that I'm not alone in that. For example, I think I thought > that Adrian is incorrect above, that certain packages are frozen. I > thought I'd seen notes suggesting that some packages were frozen, in > fact. Base? >... According to update_excuses [1] "a package is frozen" currently means that the 2/5/10 days delay until a package may enter testing is doubled but new upstream versions are still allowed to enter testing, e.g. (the only reason why the new upstream version of modutils isn't already in testing is a RC bug): <-- snip --> ... * base-config (1.33.7 to 1.33.9) + Maintainer: Joey Hess + Package is in freeze, doubling delay + Too young, only 7 of 20 days old ... * bash (2.05a-3 to 2.05a-4) + Maintainer: Matthias Klose + Package is in freeze, doubling delay + Too young, only 2 of 4 days old ... * modutils (2.4.11-1 to 2.4.12-1) + Maintainer: Wichert Akkerman + Package is in freeze, doubling delay + 11 days old (needed 10 days) ... <-- snip --> > Jules cu Adrian [1] http://ftp-master.debian.org/testing/update_excuses.html.gz
Re: MusixTex for arm and sh architecture
On Tue, 15 Jan 2002, Tille, Andreas wrote: > Hello, Hi Andreas, > second call for help to compile MusixTex on all architectures: > > auric:~> madison musixtex > musixtex | 1:0.98-1 |stable | source, alpha, arm, i386, m68k, > powerpc, sparc > musixtex | 1:0.99-1 | testing | source, arm, ia64, m68k, powerpc, > sparc > musixtex | 1:0.99-1 | unstable | arm, sh > musixtex | 1:0.102-1 | unstable | source, alpha, hppa, i386, ia64, > m68k, powerpc, s390, sparc > > Please could someone compile musixtex on arm and sh. a small comment on this: sh is not needed to get the musixtex into testing. > Kind regards > > Andreas. cu Adrian
Re: pcmcia-modules in woody
On Tue, 15 Jan 2002, Brian Mays wrote: > Lauri Tischler <[EMAIL PROTECTED]> wrote: > > > pcmcia-modules for kernels 2.19 and 2.20 dont exist. > > A set of pcmcia-modules-2.2.20 packages do exist. I uploaded a new set > of these packages yesterday to sid. As for the packages in woody, I > have no control over that. I wish the archive maintainers would replace > the outdated packages in woody, but they never do. If you would like to > help, file bugs against "ftp.debian.org" asking them to move the newer > packages into woody. > > If anyone knows how to get packages into woody, please let me know. > It's a complete mystery to me. It seems there need to happen at least three things until the new pcmcia-* packages can go into woody: 1. the obsolete packages for older images must be removed by the ftp masters from unstable -> you should file a bug against ftp.debian.org asking for the removal of these packages from unstable (unfortunately this must be done by hand by the ftp admins) 2. the packages in unstable must be built at least on all four architectures (alpha, arm, i386, powerpc) they were ever built on - including all binary packages that were ever built from this source package on these architectures (for binary packages that do no longer exist on an architecture see 1.) 3. the two RC bugs (#110719 and #119837) must be fixed You should perhaps start with fixing the RC bugs instead of bugging the ftp admins - without them fixed your package will never go into testing... > The pcmcia-modules packages have not been discontinued. I continue to > build packages to accompany the latest kernel-image packages for the > 2.2 and 2.4 series kernels. This means that I have built six packages > for the 2.2.20 kernels and one for the 2.4.17 kernel using the latest > version of pcmcia-cs. > > I have neither the time nor the resources, however, to build packages > for all of the kernel-image packages out there (last time I counted > there were 27 of these packages). Anyone willing to build these > packages is welcome to do so. I have tried to automate and document the > procedure as much as possible, and I am willing to provide advice and > assistance to anyone willing to try. > > Fortunately, some of the maintainers of the kernel-image packages are > nice enough to also build a new pcmcia-modules package to accompany a > new version of their packages. That certainly helps. BTW: It's _extremely_ ugly to build these binary pacakges in a way that a "dpkg-buildpackage -B" doesn't rebuild them all. > - Brian cu Adrian
Please remove the libfontconfig NMU from the delayed incoming
Hi Michael, as I've already explained, the horrible hack in your NMU would affect all packages using libfontconfig even though without a doubt the actual bug is in your package (xpdf). And as I've already said, abusing the fact that the maintainers seem to be a bit inactive at the moment to force your change into the archive would be highly unfair. And as I've already explained, there are two RC bugs open in libfontconfig that actually seem to be bugs in libfontconfig - and they are not addressed at all in your NMU. Please remove your NMU from the delayed incoming and wait for a maintainer decision on whether or not your ugly hack is acceptable. Thanks in advance Adrian BTW: And the worst part of your NMU hack would be that it removes the pressure to fix the bug in your package - forcing Debian to keep this hack that disables libptread usage in libfontconfig. And if any other library used by xpdf would link with libpthread, the same breakage in xpdf would anyway pop up again. -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- 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/20131122044805.gg7...@bunk.dyndns.info
Re: Bug#735134: perl: rename(1) is ancient
On Sun, Feb 02, 2014 at 03:12:32PM +, Dominic Hargreaves wrote: > > So to summarise: for many years the perl package has provided > /usr/bin/rename, a stanalone utility implemented in perl. The issue is we > don't want to provide the utility from the perl package any more because > it's been added locally inside debian/ and is not being maintained. A > maintained version is available as a separate package, libfile-rename-perl. > > The proposals on the table are: > > 1) Have perl Depend on libfile-rename-perl (and therefore have the >latter become Priority: standard) > 2) Make libfile-rename-perl be Standard, to match perl, without adding >any dependencies. > 3) Have perl Recommend libfile-rename-perl for one release cycle and then >drop it >- optionally with a warning being emitted by the built-in script > 4) 2) + 3) combined. > > Option 1 would imply that the utility is fundamentally a part of > using perl, which since it's a standalone command line program which > happens to be written in perl, seems wrong. > > Option 2 is my preferred option because it seems like the 'least surprise' > option. 4) can be considered a mostly-harmless enhancement to that, > although adding warnings could be irritating or harmful in some > circumstances. > > Any further thoughts or alternative options? The usual solution would be 1) for jessie and then simply drop that dependency after jessie: It removes the risk that someone upgrading from wheezy to jessie will have troubles due to rename being gone. No warnings required, since libfile-rename-perl will simply stay installed in jessie+1 for such users. No Depends/Recommends/Suggests from perl to libfile-rename-perl is required after jessie, since perl doesn't need it and the dependency was only for upgrades. Whether or not /usr/bin/rename should be part of a standard installation in jessie+1 and later is a separate discussion, and nothing that should be implemented through a dependency from perl. > Cheers, > Dominic. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- 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/20140202174209.gp28...@bunk.dyndns.info
Re: init.d script not using !/bin/sh
On Sun, Feb 09, 2014 at 09:14:17PM +0800, Thomas Goirand wrote: > Hi, Hi Thomas, >... > If possible, I'd like to make a survey of what kind of interpreter > packages are using for /etc/init.d scripts. How can I do that? Note that > this would make OpenRC maintainer's life more easy, and avoid ugly hacks. why is that a problem for OpenRC? > Is it too late to fix this as a release goal, so that we get every init > script to use /bin/sh? There is nothing like making it a release goal that would result in it getting magically getting fixed in all packages automatically. Conversion to only using /bin/sh functionality has happened for most init scripts many years ago, and the few scripts that use /bin/bash tend to have a reason for using it. As an example, the only init script using /bin/bash on my system is from tor. The changelog of the tor package says: * Use bin/bash for the init script instead of bin/sh. We are using ulimit -n which is not POSIX (closes: #338797). > Cheers, > > Thomas Goirand (zigo) cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- 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/20140209174823.ga14...@bunk.dyndns.info
Re: Lintian autoreject tag changes
On Sun, Feb 09, 2014 at 10:08:39PM +0100, Joerg Jaspert wrote: >... > license-problem-nvidia-intellectual (1 packages, 1 tags) > > Huh, what a false hit, so not using this. Actually seems to be a real hit, when you scroll to the bottom of http://metadata.ftp-master.debian.org/changelogs/contrib/p/pyopencl/unstable_copyright cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- 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/20140209221330.gj14...@bunk.dyndns.info
Re: Lintian autoreject tag changes
On Mon, Feb 10, 2014 at 12:13:30AM +0200, Adrian Bunk wrote: > On Sun, Feb 09, 2014 at 10:08:39PM +0100, Joerg Jaspert wrote: > >... > > license-problem-nvidia-intellectual (1 packages, 1 tags) > > > > Huh, what a false hit, so not using this. > > Actually seems to be a real hit, when you scroll to the bottom of > > > http://metadata.ftp-master.debian.org/changelogs/contrib/p/pyopencl/unstable_copyright Which is a stale entry in the copyright file, since that was already fixed: http://bugs.debian.org/722014 So lintian was right, and the only remaining problem here is that the copyright file needs updating. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- 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/20140209223254.gk14...@bunk.dyndns.info
FFmpeg vs. libav packaging (was Re: Proposal: SystemD.pushers/forcers, et cetera)
On Thu, Feb 13, 2014 at 10:48:52AM +0100, Fabian Greffrath wrote: > > > After ***forcing*** users to use libav instead of ffmpeg in debian > > therefore making it to stuck with outdated fork istead of rapidly > > developing original it's too late to talk about freedom.. > > Gosh, we are not forcing you to use libav, we just considered it better > at the time a decision had to be made. If you care that much about > ffmpeg, then get your lazy ass up and help getting it packaged instead > of spamming on debian-devel. Hi Fabian, I fully agree with you that it is not helpful to discuss whether a decision that was considered better at the time it was made is also the best in hindsight. Are you as Debian Multimedia Maintainer willing to discuss which option (libav, FFmpeg, some solution of shipping both) will be best for jessie based on the information that is available today? > As long as you don't actively contribute to Debian yourself and try to > introduce changes to your liking, you will have to deal with other > people's preferences. It's like that and that's the way it is... > > - Fabian cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- 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/20140213193747.ga4...@bunk.dyndns.info
Re: FFmpeg vs. libav packaging (was Re: Proposal: SystemD.pushers/forcers, et cetera)
On Thu, Feb 13, 2014 at 09:21:02PM +0100, Jonas Smedegaard wrote: > Quoting Adrian Bunk (2014-02-13 20:37:47) > > Are you as Debian Multimedia Maintainer willing to discuss which > > option (libav, FFmpeg, some solution of shipping both) will be best > > for jessie based on the information that is available today? > > It will certainly be best for Jessie to have a library included which > exist and has had reasonable testing as official Debian package. > > Someone needs to do the work of packaging FFmpeg and get it into Debian > testing - then we can sensibly compare them in the context of an > upcoming stable Debian release. Having both sets of libraries in the archive at the same time is what I called "insane" in the RFP and where I expect additional probems due to: - programs compiled with libav using FFmpeg and - programs ending up using a mix of both libraries, in some cases even both versions of the same library And for a fair comparison in testing, one would e.g. need one package of VLC compiled against libav and one package of VLC compiled against FFmpeg at the same time in testing. Do you have a good idea how to avoid all the problems of mixing both libraries while also creating a sufficient usage of the FFmpeg libraries in a way that both libraries can be in testing at the same time, or are you just setting a hurdle intended to be impossible to pass for FFmpeg? > I am part of the Debian Multimedia team, if that matters to you. > > - Jonas cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- 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/20140213214023.gb4...@bunk.dyndns.info
Re: Re: FFmpeg vs. libav packaging
On Thu, Feb 13, 2014 at 11:14:39PM +0100, Petr Baudis wrote: > Hi! > > > Do you have a good idea how to avoid all the problems of mixing both > > libraries while also creating a sufficient usage of the FFmpeg libraries > > in a way that both libraries can be in testing at the same time, or are > > you just setting a hurdle intended to be impossible to pass for FFmpeg? > > I'm pretty sure Debian already had to deal with multiple situations > like that. I can't think of the examples off the top of my head, but > what about for example the two sets of Kerberos libraries, krb5 vs. > heimdal? I think others could point out other examples. Is the > situation here fundamentally more difficult? Half a dozen libraries. Some have different sonames, some have the same soname. soname changes are frequent (the next libav soname change is already in experimental). Having both libraries in the archive at the same time would be a horrible mess to sort out. And here we have a maintainer requiring to have all that mess of having both in testing at the same time sorted out - just for allowing him to "sensibly compare them" and then pick the one he prefers. > Petr "Pasky" Baudis cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- 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/20140213235409.gd4...@bunk.dyndns.info
Re: FFmpeg vs. libav packaging
On Thu, Feb 13, 2014 at 11:16:55PM -0800, Russ Allbery wrote: > Paul Wise writes: > > On Fri, Feb 14, 2014 at 5:40 AM, Adrian Bunk wrote: > > >> Having both sets of libraries in the archive at the same time is what I > >> called "insane" in the RFP and where I expect additional probems due > >> to: > > > Also, I expect the security team would be unhappy to have to fix > > security issues twice. > > If they're now diverging separate source bases, this isn't really > different than the other cases where upstreams have forked and for various > reasons we've found uses for both implementations. Please correct me if I'm wrong, but my reading of Jonas' suggestion is that he wants someone to go through all the hassle of having both libav and FFmpeg in testing at the same time, so that the Debian Multimedia Maintainers "can sensibly compare them in the context of an upcoming stable Debian release" and can then choose one of them. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- 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/20140214080634.ge4...@bunk.dyndns.info
Re: FFmpeg vs. libav packaging (was Re: Proposal: SystemD.pushers/forcers, et cetera)
On Fri, Feb 14, 2014 at 06:46:37PM +0100, Fabian Greffrath wrote: > Hi Adrian, > > Am Donnerstag, den 13.02.2014, 21:37 +0200 schrieb Adrian Bunk: > > Are you as Debian Multimedia Maintainer willing to discuss which option > > (libav, FFmpeg, some solution of shipping both) will be best for jessie > > based on the information that is available today? > > Honestly, I don't think it is feasable to have both in Debian as long as > the libraries occupy the same name space[*]. But this is something that > has to get sorted out upstream before. And as long as both projects > believe they are "the real thing" I don't see that happen. I agree with you on that, and I was telling people in the RFP who wanted to add the FFmpeg libraries additionally to the libav libraries that this would be insane. And it's also the reason why Jonas' demand that FFmpeg should first have to enter testing alongside libav is so absurd. But how to make the decision whether libav or FFmpeg is better for jessie? My suggestion in the RFP was that the people who want FFmpeg should go to the TC, since the TC is an objective instance not involved in the upstream quarrel. > - Fabian cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- 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/20140214214926.ga...@bunk.dyndns.info
Re: FFmpeg vs. libav packaging
On Fri, Feb 14, 2014 at 12:47:36PM +0100, Jonas Smedegaard wrote: > Quoting Adrian Bunk (2014-02-14 09:06:34) > > On Thu, Feb 13, 2014 at 11:16:55PM -0800, Russ Allbery wrote: > >> Paul Wise writes: > >>> On Fri, Feb 14, 2014 at 5:40 AM, Adrian Bunk wrote: > >> > >>>> Having both sets of libraries in the archive at the same time is > >>>> what I called "insane" in the RFP and where I expect additional > >>>> probems due to: > >> > >>> Also, I expect the security team would be unhappy to have to fix > >>> security issues twice. > >> > >> If they're now diverging separate source bases, this isn't really > >> different than the other cases where upstreams have forked and for > >> various reasons we've found uses for both implementations. > > > > Please correct me if I'm wrong, but my reading of Jonas' suggestion is > > that he wants someone to go through all the hassle of having both > > libav and FFmpeg in testing at the same time, so that the Debian > > Multimedia Maintainers "can sensibly compare them in the context of an > > upcoming stable Debian release" and can then choose one of them. > > Previously you asked about *replacing* a codebase with another. Now you > talk about *co-existence* of codebases. Wrong. I was asking about discussing what options might make sense. Then you demanded co-existence in testing as prerequisite for a discussion. Co-existence is what I called "insane" already in the RFP. > Code do not enter Jessie directly - it goes through unstable. That is a > fact about general packaging procedures, not a suggestion of mine. > > I find it non-sensical to discuss *replacement* of a stable codebase > with one not existing in any of Debians suites, and therefore recommend > to bring the wanted codebase into Debian before we discuss further. > > I find it non-sensical to put the burden on those who find existing > codebase sufficient and preferable to solve how to migrate to a > different codebase or draft a sceme for making them co-exist. Therefore > I recommend that those interested in introducing an alternate codebase - > either as replacement or in co-existence - to do at least the initial > work involved: package the replacement codebase and get it into e.g. > experimental Debian. I agree with that proposal: Having FFmpeg packaged by the people who prefer it over libav and upload the result to experimental sounds like a reasonable way forward. > - Jonas cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- 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/20140215071721.gc...@bunk.dyndns.info
Re: Proposed mass bug filing: Removal of automake1.4, automake1.9, automake1.10 and automake1.11
On Sun, Feb 16, 2014 at 02:14:10AM -0500, Eric Dorland wrote: > All of the bugs have been filed. Just under half have been > fixed. Almost all the rest have tested patches. I'm going to start > uploading 10-day delayed NMUs to try to close these out. > > If you have an issue with this please speak now or forever hold your > peace. >... > > Karl Bartel > >black-box >... I am about to adopt that one, and something seems to be wrong here: It does build-depend on automake1.10, but there does not seem be a bug in the BTS. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- 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/20140217062319.ge...@bunk.dyndns.info
Re: Proposed mass bug filing: Removal of automake1.4, automake1.9, automake1.10 and automake1.11
On Mon, Feb 17, 2014 at 02:02:59AM -0500, Eric Dorland wrote: > * Adrian Bunk (b...@stusta.de) wrote: > > On Sun, Feb 16, 2014 at 02:14:10AM -0500, Eric Dorland wrote: > > > All of the bugs have been filed. Just under half have been > > > fixed. Almost all the rest have tested patches. I'm going to start > > > uploading 10-day delayed NMUs to try to close these out. > > > > > > If you have an issue with this please speak now or forever hold your > > > peace. > > >... > > > > Karl Bartel > > > >black-box > > >... > > > > I am about to adopt that one, and something seems to be wrong here: > > > > It does build-depend on automake1.10, but there does not seem be a bug > > in the BTS. > > http://bugs.debian.org/724353. Perhaps you're not seeing it because > it's filed against src:black-box? Yes sorry, that was a stupid mistake from me. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- 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/20140219064625.gb24...@bunk.dyndns.info
Re: Mass bugfiling potential: bundled implementation of md5
On Thu, Oct 25, 2018 at 02:56:23PM +0800, Yangfl wrote: > Hi, > > Many of packages include bundled Aladdin Enterprises independent > implementation of md5. Full list can be seen at > https://codesearch.debian.net/search?q=typedef+unsigned+char+md5_byte_t&perpkg=1 > (100 packages) > > As discussed in #909116, libmd-dev now provides a compatible interface > for that, so bundled sources should be dropped. >... What exactly are the benefits? Are they worth making not upstreamable changes to 100 packages? I would expect sane upstreams to resist adding a dependency on a library version the is currently not present in the stable release of any Linux distribution. > A potential fix for that might be replace the md5.h header with > > #define LIBMD_MD5_ALADDIN > #include > > remove building for md5.c, and add > > Build-Depends: libmd-dev (>= 1.0.1) How will you verify that this change is correct in all cases? We have so many regressions due to Debian maintainers blindly making changes they don't understand - and that were not tested at all before uploading to the archive. > Thanks, cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: Documenting copyright holders in debian/copyright
On Tue, Oct 30, 2018 at 09:34:59PM -0400, Scott Kitterman wrote: >... > 1. Most licenses require copyright statements to be included.In the > FTP > team's view, unless a license explicitly states that copyright attributions > only apply to source distributions, they apply for source and binary, so must > be documented in debian/copyright for license compliance reasons. >... > GPL requires an "appropriate copyright notice" for both source and binary > forms. My reading of 7(b) of GPLv3 would be that it is not required. Have any lawyers or the FSF been consulted on that? >... > 3. In a few cases, FTP masters have determined that full copyright > attribution is both not feasible and, given the nature of the package, that > an > appropriate copyright notice does not need to list all copyright holders and > allowed packages with an incomplete debian/copyright into the archive. Such a > package still violates policy, although the FTP masters believe it to be a > minor violation. Just because such a determination has been made about one > package, does not mean it should apply to another package. Almost certainly > the answer to requests for additional exceptions will be no. If the ftp team believes that distributing GPL code without copyright attributions in debian/copyright is required for license compliance reasons, noone except the copyright holders can legally grant an exception that allows Debian to distribute that code. If one copyright holder of a package with an existing ftp team exception package would take legal actions against a Debian mirror, what would be the official position of Debian regarding the legality of what our mirror distributes? cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: Documenting copyright holders in debian/copyright
On Wed, Oct 31, 2018 at 04:30:23AM +, Scott Kitterman wrote: > > > On October 31, 2018 3:59:42 AM UTC, Adrian Bunk wrote: > >On Tue, Oct 30, 2018 at 09:34:59PM -0400, Scott Kitterman wrote: > >>... > >> 1. Most licenses require copyright statements to be included. In the > >FTP > >> team's view, unless a license explicitly states that copyright > >attributions > >> only apply to source distributions, they apply for source and binary, > >so must > >> be documented in debian/copyright for license compliance reasons. > >>... > >> GPL requires an "appropriate copyright notice" for both source and > >binary > >> forms. > > > >My reading of 7(b) of GPLv3 would be that it is not required. > ... > > Section 7 is about "material you add to a covered work", it's not about > things someone else has copyright on. See section 4 which is referenced by > Section 5 for source distribution and Section 6 for binary distribution. IANAL, my reading would not be that listing every single copyright holder is required by the term "appropriate copyright notice". But if it is (or is for any other licence), allowing any exception in the archive would IMHO be irresponsible: This would mean distributing something on our mirrors that we consider to be a copyright violation. Any affected copyright holder would basically be invited to take legal actions against a mirror in a jurisdiction of their choice if they want. The effects of some university having to pay the costs associated with signing a cease and desist letter for distributing Debian would not be pretty. Has any lawyer been consulted regarding what our legal requirements are? > Scott K cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: Upcoming Qt switch to OpenGL ES on arm64
On Sat, Nov 24, 2018 at 02:40:37PM +0100, Matthias Klose wrote: > On 24.11.18 11:26, Andy Simpkins wrote: > >> So, again: which of the two flavors is the one that benefits more of our > >> user > >> base? > > > > BOTH are possible so why dictate only one? > > > > I would like to see OpenGLES available on all architectures > > > > I would like to see OpenGL available on all architectures > > > > I think that there is a relatively painless method to achieve this > > > > I believe this would also meet your needs > > so why not keep GL as it is now, and build the GLES packages from a single > source tarball? This way you minimize your uploads while having both > implementations in the archive? Maybe later on, you could even do the same > for > the 32bit ARM architectures if these are still release architectures by that > time. Putting all KDE packages plus all other Qt-using packages into one monster source tarball for building them a second time sounds like a nightmare impossible to maintain. Like how would security updates of gst-plugins-good1.0 in stable work when a second copy of it is in the monster tarball due to gstreamer1.0-qt5? libqt5gui5 has > 1k rdeps, the sanest way forward for providing two different ABI versions of libqt5gui5 at the same time would be two architectures for arm64. And that is not a realistic option. > Matthias cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: Upcoming Qt switch to OpenGL ES on arm64
On Tue, Nov 27, 2018 at 02:06:27PM -0800, Steve Langasek wrote: >... > Hmm, so I'm not sure this reflects the actual state of the art wrt dual Qt > stacks as it existed in Ubuntu at the time Ubuntu Touch was sunsetted. >... Is there some rationale documented somewhere why this wasn't used in Ubuntu for the arm64 port? arm64 in Ubuntu (including the current LTS) does diverge from the arm64 in Debian - but Ubuntu uses ES-only, not the dual stack solution you are referring to. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: Upcoming Qt switch to OpenGL ES on arm64
On Wed, Nov 28, 2018 at 05:03:51PM +0300, Dmitry Shachnev wrote: > On Tue, Nov 27, 2018 at 11:00:52PM -0800, Steve Langasek wrote: > > $ grep-dctrl -n -sSource:Package -FDepends \ > > -e > > 'libqt5(gui|3drenderer|quick|quickparticles|quickwidgets|multimediawidgets)5[[:space:]]*(\(>= > > 5\.[0-9.]*\))(?|$),' \ > > > > /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_xenial_*binary-amd64_Packages > > | sort -u > > maliit-plugins > > ovito > > pyqt5 > > qml-box2d > > qt3d-opensource-src > > qtbase-opensource-src > > qtdeclarative-opensource-src > > qtubuntu-cameraplugin-fake > > stellarium > > wallch > > $ > > > > Every single other binary package that depends on libqt5gui5 (etc) in Ubuntu > > 16.04 has an ORed dependency on libqt5gui5 | libqt5gui5-gles. > > Ah, this is interesting. > > The amount of packages will probably be larger in the current sid, > but it should not be more than 20 packages. > > Plus there are packages which are using QT_OPENGL_ES macro for conditional > compilation (as I mentioned in my previous mail), but there are also not many > of them: > > gammaray > goldendict > gst-plugins-good1.0 > kamoso > krita > leocad > openclonk > phonon-backend-gstreamer > qtav > qt-gstreamer > qtwebkit-opensource-src > qtwayland-opensource-src > qtcharts-opensource-src >... There are also packages like qmmq or kdenlive that use Qt5Gui_OPENGL_IMPLEMENTATION for conditional compilation.[1] ES/non-ES is in so many places part of the Qt API that I doubt this could be sorted out quickly. Qt already supports runtime ES/non-ES in the same library build on Windows [2], something like that might also be doable for Linux if anyone (Linaro? Canonical?) with a real interest in that would work on making it happen. Some of the listed applications already set Qt::AA_UseOpenGLES or Qt::AA_UseDesktopOpenGL for the Windows case, but there would surely be additional application side fixes required after someone added dynamic OpenGL selection also for Linux to Qt. > Dmitry Shachnev cu Adrian [1] https://codesearch.debian.net/search?q=Qt5Gui_OPENGL_IMPLEMENTATION [2] http://doc.qt.io/qt-5/windows-requirements.html#dynamically-loading-graphics-drivers -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: toulbar2: What will happen if testing migration takes longer than removal from testing
On Tue, Feb 19, 2019 at 11:13:29AM +0100, Andreas Tille wrote: > On Tue, Feb 19, 2019 at 09:07:24AM +0100, Ondřej Surý wrote: > > I believe that it was the case before that if the autoremoval was due a > > specific RC bug, any activity on that specific bug would reset the timer > > for autoremoval. > > I've thought the same but despite the activity it is not reset (at least > not according to tracker[1] or the autoremovals query[2]). >... There are a few hours delay until the UDD autoremovals notice bug activity, and the rest is based on this information. Check again in the evening, and you should see the autoremoval of toulbar2 in 15 days. > Kind regards > >Andreas. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: Please drop anacron from task-desktop
On Thu, Mar 07, 2019 at 10:11:41PM +0100, Paride Legovini wrote: > Michael Stone wrote on 07/03/2019: > > On Thu, Mar 07, 2019 at 09:02:23PM +0100, Holger Wansing wrote: > >>> I'm actually wondering if this is a good idea.. > >>> > >>> There are lot of other packages installing cronjobs and people, I would > >>> assume, expect that they will run. > > cronjobs run even without anacron, they just don't run > "anac(h)ronistically". Which means some won't ever run on a 9 to 5 desktop. > >>> I would personally revert his patch as long as all the cronjobs have not > >>> a corresponding systemd .timer > >> > >> Any thoughts on this? > > > > What's the downside to having anacron there if a .timer supersedes the > > cron job? > > Having a useless service running is itself a downside; I second the > removal. Please explain your usage of the word "useless". The output of "ls /etc/cron.daily" is not empty for me. > I'll also mention that anacron has been orphaned almost one > year ago. I'll also mention that "has been orphaned" does not imply anthing about the quality of the package. 4 QA uploads fixing 11 bugs in the BTS. Compared to 1 upload fixing 1 bug in the BTS in the last 3 years when it was non-orphaned. A sad truth about Debian is that QA-maintained orphaned packages are often better maintained than many non-orphaned packages. And anacron is actually a pretty good example for that. > Paride cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: Please drop anacron from task-desktop
On Fri, Mar 08, 2019 at 11:22:36AM +0100, Paride Legovini wrote: > Hello Adrian, Hi Paride, > Adrian Bunk wrote on 08/03/2019: > > On Thu, Mar 07, 2019 at 10:11:41PM +0100, Paride Legovini wrote: >... > >> Having a useless service running is itself a downside; I second the > >> removal. > > > > Please explain your usage of the word "useless". > > > > The output of "ls /etc/cron.daily" is not empty for me. > > But a few (a good part?) of them will just do nothing if you are using > systemd, e.g.: > > if [ -d /run/systemd/system ]; then > # Skip in favour of systemd timer. > exit 0 > fi on my system 3 out of 14 are doing this. And e.g. mlocate updating its database also on a desktop/laptop that is not runnning during the night is not useless and not having this would be a real downside. > This will happen more and more over time and I think it's the practice > to favor: The praxis to favor is to check the impact instead of blindly removing functionality. "happen more and more" means it might never happen 100%, for that you would need policy making it mandatory first. Short-term for buster, installing anacron still looks appropriate. And compared to everything else that is running on our default desktop, anacron does not create any noticable overhead. > having three systems to manage the execution of periodic jobs > (systemd timers, cron, anacron) in the default install is IMHO far ideal. >... Calling anacron a separate system is not correct, it works on the normal cron jobs (ideally this functionality should have been implemented in cron itself). > Paride cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: Please drop anacron from task-desktop
> On Fri, 08 Mar 2019 at 10:24:28 +0200, Adrian Bunk wrote: > > The output of "ls /etc/cron.daily" is not empty for me. > > That doesn't *necessarily* mean you need anacron, or even cron. Many > cron jobs now have a corresponding systemd timer; if you are running > systemd, the cron job starts, detects that it is unnecessary, and exits, > which is an overly-complicated way to do nothing. >... many != all Something will break (like in the mlocate case), and people might only start noticing when they are doing fresh installs of buster after the release. For buster it is too late in the release cycle for sorting this out properly for all existing daily/weekly/monthly cronjobs. > Regards, > smcv cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: Please drop anacron from task-desktop
On Fri, Mar 08, 2019 at 10:22:12AM -0800, Russ Allbery wrote: > Simon McVittie writes: > > > anacron/cron don't have a built-in way to skip particular cron jobs > > other than open-coding it in the cron job itself. > > Maybe we should just fix this? cron is effectively maintained by the > distributions anyway; there hasn't been an official upstream release in > more than twenty years. This seems like a reasonable feature to add. Sounds like over-engineering to me. if [ -d /run/systemd/system ]; then exit 0 fi Any alternative would be at least one line, and it's not like there should be changes to the condition in the forseeable future. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: Please drop anacron from task-desktop
On Fri, Mar 08, 2019 at 02:38:07PM -0500, Michael Stone wrote: > On Fri, Mar 08, 2019 at 08:01:35PM +0100, Christian Kastner wrote: > > I intended to post a transition proposal here soon, but it's not ready > > yet... but long story short: I believe we would be far better off moving > > to cronie than maintaining our old fork. > > One question worth asking is which distributions plan to maintain cron > moving forward--will some of the systemd-focused ones start dropping it in > favor of timers? (No point in migrating to fedora's cronie, for example, if > they stop using it in a year or two.) Upstream systemd lacks crontab support, and 3rd party systemd-based replacements are not 100% compatible with cron/cronie/bcron/... cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: Please drop anacron from task-desktop
On Fri, Mar 08, 2019 at 07:27:19PM -0500, Michael Stone wrote: > On Sat, Mar 09, 2019 at 12:02:05AM +0200, Adrian Bunk wrote: > > On Fri, Mar 08, 2019 at 02:38:07PM -0500, Michael Stone wrote: > > > On Fri, Mar 08, 2019 at 08:01:35PM +0100, Christian Kastner wrote: > > > > I intended to post a transition proposal here soon, but it's not ready > > > > yet... but long story short: I believe we would be far better off moving > > > > to cronie than maintaining our old fork. > > > > > > One question worth asking is which distributions plan to maintain cron > > > moving forward--will some of the systemd-focused ones start dropping it in > > > favor of timers? (No point in migrating to fedora's cronie, for example, > > > if > > > they stop using it in a year or two.) > > > > Upstream systemd lacks crontab support, and 3rd party systemd-based > > replacements are not 100% compatible with cron/cronie/bcron/... > > What does that have to do with whether other distributions stop supporting > crontabs? A general-purpose distribution cannot stop supporting crontabs. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: [Idea] Debian User Repository? (Not simply mimicing AUR)
On Sun, Apr 07, 2019 at 01:26:12PM +, Mo Zhou wrote: >... > (2) Dirty but useful non-free blobs, such as nvidia's cuDNN (CUDA Deep > Neural Network) library, which dominates the field of high performance > neural network training and inference. I really hate reading NVIDIA's > non-free legal texts, and in such repository we can avoid reading the > license and just get the scutwork done and make users happy. > > (3) Data with obscure licensing. In this repository we can feel free to > package pre-trained neural networks or training data without carefully > examing the licensing. The requirements for distributing software in the system you want to setup wouldn't be much different from what is required for non-free. Anything that is legal to distribute can likely go into non-free. >... > (5) Packages that utilizes SIMD instructions heavily. Such package is > very easy to package in such repo. (So this Proposal actually suppresses > and replaces my SIMDebian project). Run-time autodetection is the best solution. We also have packages that build several versions of a program, with a tiny wrapper that selects the best at startup. > 2. Allows us to offload some low-popcon, or QA-questionable packages > from the archive. Debian's archive size is continuously increasing, but > the number of Debian Developers has been staying around 1000 for many > many years. Saturation will definitely happen in the future if we do > nothing to change - or saturation has already happended. An Archlinux > Developer's saturation point may be several thousand (See Felix Yan, an > Arch Dev), but a Debian Developer often saturate at, maybe 30~100? You make it sound as if the number of packages would be what matters most. Which is not true. A low-popcon package that is old and stable and stale and doesn't depend on changing libraries usually just continues working with close to zero effort. Most work is in the volatile areas of the archive, e.g. tensorflow as one package might create more work than whatever you would consider the saturation point for a single developer. > Handing over some workload to the user community is not a bad thing, "user community" sounds like a "somebody" that is in reality "nobody". >... > 3. Allows us to accept potential contributors friendly, and possibly > form a new user community. The high quality standard of Debian may scare > some potential contributors away. >... Package installation runs as root, which means you are granting root access to the package creator of every single package you are installing. Be it malicious intention or just a packaging mistake, trust and quality are not really optional items. > Best, > Mo. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: Bits from /me: Difficulties in Deep Learning Framework Packaging
On Tue, Apr 16, 2019 at 02:29:54PM +0200, Andreas Tille wrote: >... > As far as I understand your summary it would be even > "burning" a student if we would throw theses packaging task on a > student in a GSoC / outreachy project (I'm aware that we are usually > not supporting packaging tasks in these projects but it could be an > exception in case my suspicion would be wrong). >... How many percent of the paid GSoC and Outreachy student workers continue unpaid afterwards and become a DM or DD? My impression is that GSoC does not have a high quota, and Outreachy is a complete failure.[1] Assuming the student would succeed in creating packages, what we would get would be some complex packaging of packages with a very volatile upstream - and the only person who understands the packaging is likely gone. The work Mo spent on the already-outdated tensorflow package in experimental was wasted if there is noone who continues maintaining it. And the same would be true for other new packages if the packager disappears afterwards. What is actually needed are one (or ideally several) people with a long-term commitment to maintain these packages. cu Adrian [1] If anyone has data to prove that I am wrong, please let me to know. -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: Bits from /me: Difficulties in Deep Learning Framework Packaging
On Wed, Apr 17, 2019 at 07:08:53AM -0400, Chris Lamb wrote: > Adrian Bunk wrote: > > > How many percent of the paid GSoC and Outreachy student workers > > continue unpaid afterwards and become a DM or DD? > > > > My impression is that GSoC does not have a high quota, > > and Outreachy is a complete failure. > > Curious that you have that perception. I don't have hard data but I > can immediately think of at least five folks. > > And that's not counting myself. GSoC or Outreachy? And 6 out of how many? Where can I find a list of all past Debian GSoC and Outreachy participants? Based on that it would be easy to get hard data. > Regards, cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: Bits from /me: Difficulties in Deep Learning Framework Packaging
On Wed, Apr 17, 2019 at 01:38:22AM +, Mo Zhou wrote: > Hi Adrian, Hi Mo, > On Tue, Apr 16, 2019 at 11:07:34PM +0300, Adrian Bunk wrote: >... > > The work Mo spent on the already-outdated tensorflow package in > > experimental was wasted if there is noone who continues maintaining it. > > And the same would be true for other new packages if the packager > > disappears afterwards. > > Debian should have already got used to the fact that volunteers are > scarce resource. Are they scarce or scared away? I had some points in [1] regarding the problems of volunteers trying to get contributions in Debian. > > What is actually needed are one (or ideally several) people with > > a long-term commitment to maintain these packages. > > I think most of such long-term + high-workload maintaining works are > actually backed by salary. >From what I am aware, I would say it is pretty much an exception when maintaining packages in unstable is paid work. Especially long-term, apart from Canonical there are not many companies that have an interest in Debian that does not go away after their next round of restructure+layoffs. cu Adrian [1] https://lists.debian.org/debian-vote/2019/03/msg00199.html -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: Bits from /me: Difficulties in Deep Learning Framework Packaging
On Wed, Apr 17, 2019 at 03:04:12PM +0200, Jonathan Carter wrote: > On 2019/04/17 13:08, Chris Lamb wrote: > >> How many percent of the paid GSoC and Outreachy student workers > >> continue unpaid afterwards and become a DM or DD? > >> > >> My impression is that GSoC does not have a high quota, > >> and Outreachy is a complete failure. > > > > Curious that you have that perception. I don't have hard data but I > > can immediately think of at least five folks. > > > > And that's not counting myself. > > Well, the Outreachy site is running, and since they have plans ahead > they clearly seem to be continuing their work. So if Adrian wants to > call it a complete failure then the burden lies on him to justify that > statement, and not on everyone else to invalidate it. I said it was my impression, and was asking if anyone has data to prove me wrong. IMHO anyone spending a 5 digit US Dollar amount of Debian money annually should also have the burden of proof that the money is well-spent. Personally I would also consider it questionable that Debian Outreachy does "expressly invite"[1] every black man born with the privilege of US citizenship to participate, while black heterosexual men in South Africa are excluded and heterosexual men from South America are only invited if living in the US - this conveys a not very subtle message what kind of diversity and inclusivity in Debian is wanted and what kind is not... I am sure this all makes sense for people in the US, but for a global project it is a WTF. It might even happen one day that a female student born into a middle-class German family gets paid 5k from Debian plus mentorship from a DD in South America - who is too shy to ask Debian for 1k travel sponsorship to a Debian event in Europe he cannot afford himself.[2] > -Jonathan cu Adrian [1] https://wiki.debian.org/Outreachy/Round17 [2] See the "we know it could be used for 4 or 5 other developers inside Europe to travel around there" in [3]. [3] https://lists.debian.org/debian-vote/2019/04/msg00011.html -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: debhelper and friends for LTS
On Tue, Apr 23, 2019 at 12:46:54PM +0200, Ondřej Surý wrote: > Hey, > > the jessie-backports removal itself is a logical step and it’s good that it > was done. > > That said, it complicates things a lot when backporting packages to Jessie. > Usually, it’s fine to just pull $random extra library to the extra > repository, but debhelper and friends is a different beast, as it often > requires upgrades in steps, or pulling some extra packages or dropping them, > etc. The packages are still available after the removal: deb [check-valid-until=no] http://archive.debian.org/debian jessie-backports main > This is now especially painful with the differences between debhelper compact > 9/10 and 11/12 as those changes require reverting lots of tiny bits in the > source packages as more and more gets converted to v12. > > I don’t have a good solution for this, but keeping the debhelper and friends > (dpkg-dev, dh_) in an extra suite would be very much helpful for people > like me backporting bigger stacks to Jessie. I provide PHP (5.6, 7.0 and up), > apache2, nginx, ... and it’s very painful from time to time. >... AFAIK debhelper >= 11 was never in jessie-backports-sloppy. And the requirement to backport packages like cmake or meson from buster would make it *very* painful for anyone trying to backport debhelper 12 to jessie. > Cheers, > Ondrej cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: .deb format: let's use 0.939, zstd, drop bzip2
On Wed, May 08, 2019 at 07:38:26PM +0200, Adam Borowski wrote: >... > So let's pick compressors to enable. For compression ratio, xz still wins > (at least among popular compressors). But there's a thing to say about > zstd: firefox.deb zstd -19 takes to unpack: > * 2.644s .xz, stock dpkg > * 2.532s .xz, my tool (libarchive based) > * 0.290s .zst, my tool > * 0.738s .gz, stock dpkg > * 0.729s .gz 0.939, stock dpkg > * 0.729s .gz 0.939, stock dpkg > File sizes being 60628216 gz, 47959544 zstd, 44506304 xz. > > XFCE install total: 723M xz, 773M zstd, 963M gzip. > > Thus, even though we'd want to stick with xz for the official archive, speed > gains from zstd are so massive that it's tempting to add support for it, > at least for non-official uses, possibly also for common Build-Depends. >... Is this single-threaded or parallel? pbzip2 decompression speed scales nicely with the number of CPUs, and in general for anyone interested in massive speed gains the way forward would be towards parallel decompression. > But, the dlopen idea shows a potential victim: bzip2. Let's kill it. > > Stats for Buster's packages: > > .deb format: > 2.0:100% > > control: > gz 11671 > xz 45210 > > data: > gz 966 > xz 55915 > > With not a single package in the archive still using bz2, You were only looking at binary packages, for source packages bz2 is still pretty common. > removing support > would be reasonable. It'd be okay to give a clear error message telling the > user to install libbz2-1.0 (dlopen) or bzip2 (pipe) -- so folks can still > unpack historic .debs if need be. It would be neither reasonable nor okay to create such hassle for users for no benefits at all. And if the tiny 75 kB libbz2 would be considered a problem, the huge 650 kB libzstd would obviously never be an option for packages in the archive. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: Do we want to Require or Recommend DH
On Mon, May 13, 2019 at 08:33:44AM -0400, Sam Hartman wrote: >... > Andreas Tille's explanation (quoted below) is typical of what I've heard > in this area. > > >To come back > >to the question: I'm positively convinced that we should strive to > >unify our packaging as much as possible and in terms of d/rules file dh > >is obviously the default we should pick. I'd go that far that lintian > >should issue some warning at "pedantic" level if there is no comment: > >"I'm not using dh because ... ". In other words: Use dh in debian/rules > >should make it into policy. > > >The rationale is that dh makes it extremely easy to understand other > >d/rules files. Specifically in freeze like now it is easy to touch > >other peoples packages (just done this several times in the last weeks > >and luckily close to all used dh). Its the point of teamwork (and I > >consider all people touching official Debian packages as a team) to make > >things simple for team mates. I consider it a valid request to every > >single maintainer to respect that other people have good reasons to > >change her/his package. >... Based on this rationale, Andreas should stop using d-shlibs. Weird tools on top of dh are not that different from using a weird buildsystem when debugging other peoples packages, and d-shlibs is something I've seen involved in bugs more than once. >... > As we can see on https://trends.debian.net/#build-systems a majority of > packages already use dh. So what would it mean to recommend dh? >... > As part of this discussion I hope we will collect a list of exceptions > where dh is not the right answer today. >... What is actually the problem that needs legislating here? For any newly packaged (and often also adopted) package that can be packaged with the trivial dh 3-liner this is already being done, with exceptions within the margin of error. When you debug for the first time a non-trivial problem in a complex package like src:gcc-8 or in a package in an ecosystem like Haskell you can easily spend hours just for figuring out what is actually going on or how to pass additional flags. Whether or not the build machinery is using dh is not a big difference when you have to understand what is actually going on. >... > And at some level I think we're asking whether it is appropriate to NMU > a package to convert it to dh. >... Common causes of broken packages in the archive include: - dh compat level bumps - conversion of debhelper using packages to the short dh form - conversion from other build systems to dh It is already a real problem when maintainers are bumping dh compat levels without checking very thoroughly before uploading that this didn't cause any regression - a dh compat level bump is a breaking change and should not be done without due diligence. And we do get broken packages packages uploaded where the NMU of a build system change (e.g. cdbs to dh) resulted in an empty package - whoever uploaded such a package clearly didn't even do basic checks. In my experience, keeping existing packages at exotic build systems or ancient dh compat levels causes fewer problems than people trying to change that just for the sake of it. > --Sam cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: Do we want to Require or Recommend DH
On Mon, May 13, 2019 at 11:08:21PM +0200, gregor herrmann wrote: > On Mon, 13 May 2019 22:22:32 +0300, Adrian Bunk wrote: > > > In my experience, keeping existing packages at exotic build systems or > > ancient dh compat levels causes fewer problems than people trying to > > change that just for the sake of it. > > In my experience ancient debian/rules runes are also a cause for > repeated RC bugs and the need for NMUs. > > Real life example: > https://tracker.debian.org/media/packages/libm/libmp3-info-perl/changelog-1.24-1.2 > > Both RC bugs wouldn't have happened with dh(1); and the second NMU > wouldn't have been necessary if I had switched to dh(1) in the first > one. How well are you testing such conversions? Based on work I've seen from you I'd guess your NMU would be better than average. Unfortunately this is not generally true. Based on what enters the archive, "debdiff between old and new package" already seems to be something that many people are not doing - then cleaning up after mass-NMUs would be much work. I have even seen maintainers blindly replacing a complex old debian/rules with the dh 3-liner, and all the bugfixes and workarounds in the old one were bugs again. To show the quantitative side of my argument: The default change to parallel building in dh compat 10 alone has caused a three digit number of RC bugs, popping up at a pace of 1-2 RC bugs per week for several years. The problem is that anything that works for only 99% of all packages results in such a high number of new bugs. Parallel build bugs slipping through an upload can happen, but maintainers not going through the upgrading checklist and running debdiff between old and new packages as well as testing them when doing dh compat bumps is harder to excuse - and in practice this does happen. There is no perfect solution here and I also get your point, what should be taken into consideration is that there is a tradeoff between the benefits and the regressions of breaking changes like dh compat bumps or even conversions to dh. In my experience people are already pushing too much towards "use dh with latest compat" in existing packages, and it would be better to slow that down rather than accelerate it even further. > Cheers, > gregor cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: Do we want to Require or Recommend DH
On Tue, May 14, 2019 at 11:30:11AM +0200, Andreas Tille wrote: > On Mon, May 13, 2019 at 10:22:32PM +0300, Adrian Bunk wrote: > > On Mon, May 13, 2019 at 08:33:44AM -0400, Sam Hartman wrote: > > >... > > > Andreas Tille's explanation (quoted below) is typical of what I've heard > > > in this area. > > > > > > >To come back > > > >to the question: I'm positively convinced that we should strive to > > > >unify our packaging as much as possible and in terms of d/rules file dh > > > >is obviously the default we should pick. I'd go that far that lintian > > > >should issue some warning at "pedantic" level if there is no comment: > > > >"I'm not using dh because ... ". In other words: Use dh in debian/rules > > > >should make it into policy. > > > > > > >The rationale is that dh makes it extremely easy to understand other > > > >d/rules files. Specifically in freeze like now it is easy to touch > > > >other peoples packages (just done this several times in the last weeks > > > >and luckily close to all used dh). Its the point of teamwork (and I > > > >consider all people touching official Debian packages as a team) to make > > > >things simple for team mates. I consider it a valid request to every > > > >single maintainer to respect that other people have good reasons to > > > >change her/his package. > > >... > > > > Based on this rationale, Andreas should stop using d-shlibs. > > > > Weird tools on top of dh are not that different from using a weird > > buildsystem when debugging other peoples packages, and d-shlibs is > > something I've seen involved in bugs more than once. > > Its the first time that I hear criticism about d-shlibs usage It is fine in the current "maintainer can do anything" world. > and I'm > fine with discussing this but I'd prefer not to spoil the current > thread. >... It is actually part of it, due to: >... > As far as I understood the point of the discussion is that we want to > get the whole archive more uniform to reduce the potential causes for > bugs *in* *the* *future*. >... If this is the point, then weird tools on top of dh are part of the problem just as weird buildsystems are. >... > > When you debug for the first time a non-trivial problem in a complex > > package like src:gcc-8 or in a package in an ecosystem like Haskell you > > can easily spend hours just for figuring out what is actually going on > > or how to pass additional flags. Whether or not the build machinery is > > using dh is not a big difference when you have to understand what is > > actually going on. > > I for myself prefer to debug code based on the same tool set. >... This is pretty much impossible. dh is nice when it supports whatever you want to do, but for everything else it is just another layer you have to understand when debugging and fixing problems. Imagine you want to make ghc pass an additional flag to gcc. The layering is as follows: Debian haskell scripts upstream build system ghc gcc You end up at questions: How can I tell ghc to pass a parameter to gcc? How can I tell the upstream build system to pass a parameter to ghc? How can I tell the Debian haskell scripts to pass a parameter to the upstream build system? debian/rules is already a 3-line #!/usr/bin/make -f include /usr/share/cdbs/1/rules/debhelper.mk include /usr/share/cdbs/1/class/hlibrary.mk It wouldn't help you if that would be changed to a 3-line #!/usr/bin/make -f %: dh $@ --with haskell In either case there is a huge Haskell-specific build machinery you have to understand for making some kinds of debugging or changes. > Kind regards > > Andreas. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
