Bug#782274: win32-loader: build-dependency not satisfied in jessie
Source: win32-loader Version: 0.7.8 Tags: jessie Severity: serious User: trei...@debian.org Usertags: edos-uninstallable Hello, win32-loader build-depends on nsis (= 2.46-10~). This is not satisfied in jessie, but is satisfied in sid: nsis | 2.46-9| jessie | source, amd64 nsis | 2.46-9+b1 | jessie | arm64, armel, armhf, i386, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, ppc64el nsis | 2.46-9+b2 | jessie | s390x nsis | 2.46-10 | sid | source, amd64, arm64, armel, armhf, hurd-i386, i386, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, ppc64el, s390x, sparc To solve this bug one probably needs to let nsis migrate to jessie. When you reassign this bug accordingly please set an Affects: win32-loader. Sorry for filing this bug so late in the release process, I somehow was under the impression that the issue was known. Cheers -Ralf. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150409192438.gc9...@seneca.home.org
Bug#772657: ttf-cjk-compact: build-depends on ruby1.8
Source: ttf-cjk-compact Version: 1.20 Severity: serious Tags: jessie User: trei...@debian.org Usertags: edos-uninstallable Hi, ttf-cjk-compact build-depends on ruby1.8, which does not exist in jessie. In fact, ruby1.8 was removed from testing on 2014-03-13. -Ralf. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141209172542.ga1...@murdock.inria.org
Bug#772657: ttf-cjk-compact: build-depends on ruby1.8
On Tue, Dec 09, 2014 at 08:51:52PM +0100, Christian Hofstaedtler wrote: * Cyril Brulebois k...@debian.org [141209 18:41]: Ralf Treinen trei...@pps.univ-paris-diderot.fr (2014-12-09): Source: ttf-cjk-compact Version: 1.20 Severity: serious Tags: jessie User: trei...@debian.org Usertags: edos-uninstallable Hi, ttf-cjk-compact build-depends on ruby1.8, which does not exist in jessie. In fact, ruby1.8 was removed from testing on 2014-03-13. It really would be nice not to remove packages that are still build-depended on, especially when no bug reports are being filed. One month into the freeze isn't exactly the right time to attempt a 1.8 to 1.9 (or whatever else is current this week) ruby transition in d-i packages. AFAICT, ttf-cjk-compact 1.20 is not in jessie or sid. ttf-cjk-compact 1.23 from jessie/sid depends on ruby, not ruby1.8. In fact, the jessie Sources file contains both 1.20 and 1.23. Which means there is indeed no bug against ttf-cjk-compact. However, this seems still strange to me. I know that sid may contain temporarily multiple versions of the same package, but I don't think that this is OK for testing. Ralf. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141209201650.gb6...@seneca.home.org
Bug#772657: ttf-cjk-compact: build-depends on ruby1.8
On Tue, Dec 09, 2014 at 08:04:50PM +, Adam D. Barratt wrote: On Tue, 2014-12-09 at 20:51 +0100, Christian Hofstaedtler wrote: * Cyril Brulebois k...@debian.org [141209 18:41]: Ralf Treinen trei...@pps.univ-paris-diderot.fr (2014-12-09): Source: ttf-cjk-compact Version: 1.20 Severity: serious Tags: jessie User: trei...@debian.org Usertags: edos-uninstallable Hi, ttf-cjk-compact build-depends on ruby1.8, which does not exist in jessie. In fact, ruby1.8 was removed from testing on 2014-03-13. It really would be nice not to remove packages that are still build-depended on, especially when no bug reports are being filed. One month into the freeze isn't exactly the right time to attempt a 1.8 to 1.9 (or whatever else is current this week) ruby transition in d-i packages. AFAICT, ttf-cjk-compact 1.20 is not in jessie or sid. ttf-cjk-compact 1.23 from jessie/sid depends on ruby, not ruby1.8. It's still in sid's Sources file, but marked as Extra-Source-Only. AFAICS, that's due to us having bumped stable's debian-installer-netboot-images (which was quite legitimately built against ttf-cjk-compact 1.20 and ruby1.8) in to sid and jessie during the last point release. This is not a bug in the package, nor anything that can be fixed other than by a source upload of d-i-n-i for sid. I'm therefore going to close this report. (In general, it's worth checking such things aren't purely E-S-O: yes.) OK. Julien pointed me already to E-S-O in the context of a different case where I had reported missing build-depends. Sorry for the noise, I'll refine my script. -Ralf. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141209202718.gc6...@seneca.home.org
linux-modules-di-i386-2.6 not buildable in squeeze
Hello, we have linux-modules-di-$(ARCH)-2.6 packages in squeeze, for various values of $(ARCH). However, these are not buildable in squeeze since they build-depend on loop-aes-modules-2.6.30-2-486 which is not in squeeze. Under normal circumstances this would be an RC bug. However, I grant it that installer stuff is somewhat special (though I never understood the technical justification for that). Can someone explain to me whether, and why, this is OK for linux-modules-di-$(ARCH)-2.6? Cheers -Ralf. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101130210552.ga2...@free.fr
Re: edos analysis for debian-installer
Hi Frans (and debian-boot), On Fri, Feb 12, 2010 at 02:28:07AM +0100, Frans Pop wrote: On Friday 12 February 2010, Ralf Treinen wrote: I have just enabled daily (from now on) runs of the edos installability analysis of debian-installer: http://edos.debian.net/edos-debcheck/installer.php For sid it makes some sense, but it's only of very limited value. Some uninstallables are always going to show up, simply because a lot of udebs are arch:all, but may not have their depends met for a specific arch as the installation method they are used in is simply not relevant for that arch. The numbers in parantheses () are for packages that have Architecture != all. Also, a lot of dependencies that do exist are not registered in the control file. Reason for that is that the dependencies are also used to order components in the main menu of the installer (they help determine the order of execution of installation steps). So the picture will always be incomplete to some extend. That is interesting. Do you mean that packages in installer contain more dependencies than in unstable? Is there any documentation where these additional dependencies come from (by hand from the mainatiner, or a tool), and how they are used? As far as I'm concerned it's up to you whether to keep generating and publish the info or not, but I do hope nobody will be filing BRs from it [2]. I'm not sure if I'll ever think of checking back :-P It takes almost zero ressources compared to the complete debian distributions, so we might as well keep it running. [2] Maybe add some kind of disclaimer? Yes, good idea. Did that, and also for the unstable distribution. However, there was in the past never a problem with people reporting bugs based on the edos-debcheck runs. Cheers -Ralf. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100214191903.gc3...@free.fr
edos analysis for debian-installer
Hello, I have just enabled daily (from now on) runs of the edos installability analysis of debian-installer: http://edos.debian.net/edos-debcheck/installer.php This checks, for each of the Packages files that are found in dists/unstable/main/debian-installer/binary-ARCH/Packages.gz, whether all their dependencies and conflicts can be satisfied inside that distribution. Does this make sense? I have to admit that I do not understand the process that leads to that distribution and Packages file, so I just applied what we were already doing for the unstable, testing, and stable standard debian distributions. Would it make sense to do the same analysis for testing/debian-installer and stable/debian-installer? -Ralf. (please cc me in replies as I am not subscribed to debian-boot) -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#479814: debootstrap fails to install a sid chroot on amd64
Package: debootstrap Version: 1.0.9 Severity: normal debootstrap --components=main,contrib,non-free sid sid-root http://ftp.fr.debian.org/debian/ [...] I: Extracting zlib1g... I: Installing core packages... W: Failure trying to run: chroot /home/rt/tmp/sid-root dpkg --force-depends --install var/cache/apt/archives/libc6_2.7-10_amd64.deb chroot-ing into sid-root, and trying to execute the offending dpkg: seneca:/home/rt/tmp# chroot sid-root seneca:/# dpkg --force-depends --install var/cache/apt/archives/libc6_2.7-10_amd64.deb (Reading database ... 674 files and directories currently installed.) Preparing to replace libc6 2.7-10 (using .../libc6_2.7-10_amd64.deb) ... Can't locate Hash/Util.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.10.0 /usr/local/share/perl/5.10.0 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl .) at /usr/share/perl/5.10/fields.pm line 122. Compilation failed in require at /usr/share/perl5/Debconf/Log.pm line 10. Compilation failed in require at /usr/share/perl5/Debconf/Db.pm line 7. BEGIN failed--compilation aborted at /usr/share/perl5/Debconf/Db.pm line 7. Compilation failed in require at /usr/share/debconf/frontend line 6. BEGIN failed--compilation aborted at /usr/share/debconf/frontend line 6. dpkg: error processing var/cache/apt/archives/libc6_2.7-10_amd64.deb (--install): subprocess pre-installation script returned error exit status 2 Errors were encountered while processing: var/cache/apt/archives/libc6_2.7-10_amd64.deb -Ralf. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.utf8) Shell: /bin/sh linked to /bin/bash Versions of packages debootstrap depends on: ii binutils 2.18.1~cvs20080103-4+b1 The GNU assembler, linker and bina ii wget 1.11.2-1retrieves files from the web debootstrap recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: removal of svenl from the project
On Tue, Mar 14, 2006 at 09:01:09PM -0500, Andres Salomon wrote: I am going through the expulsion process to have Sven Luther removed from the project. The process is outlined here: http://lists.debian.org/debian-devel-announce/2005/08/msg5.html, and I have already completed step 1. This is ridiculous. It seems to become a favourite pasttime in debian to ask for exclusion of people with whom someone has a personal quarrel. So, if you are interested in seconding the expulsion request, please let me know. Please do not turn this into a flamewar; I don't care about your reasons why people should not be forcefully removed from the project. Those who feel this way probably have not had to work w/ Sven on a team for the past 2 years. I have been working with Sven on the debian ocaml team for six years. He was the founder of that team, and for a long time among the most active and productive members. Every time I had the occassion to collaborate with him discussions were constructive and fruitful. -Ralf. -- Ralf Treinen Laboratoire Spécification et Vérification CNRS, École Normale Supérieure de Cachan, INRIA Futurs http://www.lsv.ens-cachan.fr/~treinen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
