Re: Perl embedding pain
Quoting Niko Tyni (2015-05-24 12:10:12) On Tue, Aug 26, 2014 at 01:35:50AM -0700, Ben Hutchings wrote: On Mon, 2014-08-25 at 16:20 -0700, Niko Tyni wrote: On Thu, Aug 21, 2014 at 01:07:16PM -0700, Ben Hutchings wrote: As libperl5.* packages currently depend on an exact version of perl-base, coinstallation of multiple library versions is impossible. Transitions are not only a pain for developers, but users must upgrade all Perl extensions and embedding applications at the same time as the perl package. Why don't all the Perl package names include the ABI version, leaving perl as a metapackage? With linux-tools-* packages, this is particularly problematic as the older packages will never be rebuilt for the new Perl version. My inclination is to 'fix' this by removing Perl integration from perf. Please let us know whether it will be possible to fix this properly. For my part, I'm sort of interested in leaving old libperl versions installable after upgrades, but I wouldn't want to be supporting /usr/bin/perl5.18 and /usr/bin/perl5.20 simultaneously or even having separate source packages for different Perl versions in the archive at the same time. Hi, getting back to this old thread (and #495394, which is a similar request): it looks like we'll be reorganizing the package setup for Perl 5.22 so that in the future libperl5.xx and libperl5.yy will stay coinstallable, along with the full standard library. There are still no provisions for keeping old builds of binary (XS) module packages around, but it should be possible to install those modules manually from CPAN if needed. New major Perl releases are made yearly in May or thereabouts, and 5.22 is currently at the release candidate phase upstream. We expect to get it in experimental soon, and in sid this summer. By the time stretch is frozen I suppose we'll be at 5.24. As jessie was released with the old setup, this won't help jessie-stretch upgrades, but at least things are getting better now. Ohh - this is great news! I look forward to being able to do major Debian upgrades in smaller chunks rather than being forced to upgrade all packages related to XS modules in lockstep. Enjoy Spain! - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Bug#785557: perl: FTBFS on i386 and amd64: itimer problems on buildds?
On Sun, May 24, 2015 at 02:55:00PM +0800, Paul Wise wrote: On Sat, 2015-05-23 at 19:10 +0200, Dominic Hargreaves wrote: This is rather strange; any ideas from DSA? The underlying hosts do not have the same issue. All of the guests use the same virtual CPU version/flags. All of the guests use the same Linux kernel version. Thanks for the update. I guess diving into the Linux implementation of times(2) for clues would be the next step for figuring out what the issue is here. I'm taking the kernel maintainers in the loop. The status here is that times(2) seems to be misbehaving on some i386 and amd64 debian.org virtual hosts running jessie (under ganeti/qemu, with jessie on the underlying hosts too). These hosts include at least barriere and x86-grnet-01. The misbehaviour is that user time stays at zero all the time, as seen for example with 'time yes'. This is making perl fail to build from source due to test failures, and I'd expect it to affect other things too. Any help is appreciated. -- Niko Tyni nt...@debian.org -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150524110947.GA1@estella.local.invalid
Re: Perl embedding pain
On Tue, Aug 26, 2014 at 01:35:50AM -0700, Ben Hutchings wrote: On Mon, 2014-08-25 at 16:20 -0700, Niko Tyni wrote: On Thu, Aug 21, 2014 at 01:07:16PM -0700, Ben Hutchings wrote: As libperl5.* packages currently depend on an exact version of perl-base, coinstallation of multiple library versions is impossible. Transitions are not only a pain for developers, but users must upgrade all Perl extensions and embedding applications at the same time as the perl package. Why don't all the Perl package names include the ABI version, leaving perl as a metapackage? With linux-tools-* packages, this is particularly problematic as the older packages will never be rebuilt for the new Perl version. My inclination is to 'fix' this by removing Perl integration from perf. Please let us know whether it will be possible to fix this properly. For my part, I'm sort of interested in leaving old libperl versions installable after upgrades, but I wouldn't want to be supporting /usr/bin/perl5.18 and /usr/bin/perl5.20 simultaneously or even having separate source packages for different Perl versions in the archive at the same time. Hi, getting back to this old thread (and #495394, which is a similar request): it looks like we'll be reorganizing the package setup for Perl 5.22 so that in the future libperl5.xx and libperl5.yy will stay coinstallable, along with the full standard library. There are still no provisions for keeping old builds of binary (XS) module packages around, but it should be possible to install those modules manually from CPAN if needed. New major Perl releases are made yearly in May or thereabouts, and 5.22 is currently at the release candidate phase upstream. We expect to get it in experimental soon, and in sid this summer. By the time stretch is frozen I suppose we'll be at 5.24. As jessie was released with the old setup, this won't help jessie-stretch upgrades, but at least things are getting better now. Greetings from the Debian Perl team sprint in sunny Barcelona, -- Niko Tyni nt...@debian.org -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150524101012.GA20861@estella.local.invalid
Re: Perl embedding pain
On Sun, 2015-05-24 at 13:10 +0300, Niko Tyni wrote: On Tue, Aug 26, 2014 at 01:35:50AM -0700, Ben Hutchings wrote: On Mon, 2014-08-25 at 16:20 -0700, Niko Tyni wrote: On Thu, Aug 21, 2014 at 01:07:16PM -0700, Ben Hutchings wrote: As libperl5.* packages currently depend on an exact version of perl-base, coinstallation of multiple library versions is impossible. Transitions are not only a pain for developers, but users must upgrade all Perl extensions and embedding applications at the same time as the perl package. Why don't all the Perl package names include the ABI version, leaving perl as a metapackage? With linux-tools-* packages, this is particularly problematic as the older packages will never be rebuilt for the new Perl version. My inclination is to 'fix' this by removing Perl integration from perf. Please let us know whether it will be possible to fix this properly. For my part, I'm sort of interested in leaving old libperl versions installable after upgrades, but I wouldn't want to be supporting /usr/bin/perl5.18 and /usr/bin/perl5.20 simultaneously or even having separate source packages for different Perl versions in the archive at the same time. Hi, getting back to this old thread (and #495394, which is a similar request): it looks like we'll be reorganizing the package setup for Perl 5.22 so that in the future libperl5.xx and libperl5.yy will stay coinstallable, along with the full standard library. There are still no provisions for keeping old builds of binary (XS) module packages around, but it should be possible to install those modules manually from CPAN if needed. New major Perl releases are made yearly in May or thereabouts, and 5.22 is currently at the release candidate phase upstream. We expect to get it in experimental soon, and in sid this summer. By the time stretch is frozen I suppose we'll be at 5.24. As jessie was released with the old setup, this won't help jessie-stretch upgrades, but at least things are getting better now. Thanks, it sounds like that will fix the problem we have with linux-tools-*. Ben. Greetings from the Debian Perl team sprint in sunny Barcelona, -- Ben Hutchings Experience is what causes a person to make new mistakes instead of old ones. signature.asc Description: This is a digitally signed message part
Bug#786382: linux-image-4.0.0-1-amd64: Blank screen switching to a VT (Intel Haswell with HD4400)
When I replied I did not realize that what you intended for upstream was freedesktop.org, not kernel.org. I've just filed the bug upstream, as you requested: https://bugs.freedesktop.org/show_bug.cgi?id=90617 Also, in my initial message i did a typo in the notebook model: it's a PU301LA (not LS). Cesare. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CA+h1Z601Wt0fGvO6UZ=cpcvgdv3mx7ohgdoa4sjhinkjwdm...@mail.gmail.com
Re: Bug#785557: perl: FTBFS on i386 and amd64: itimer problems on buildds?
On 16:38 Sun 24 May , Ben Hutchings wrote:
On Sun, 2015-05-24 at 14:09 +0300, Niko Tyni wrote:
On Sun, May 24, 2015 at 02:55:00PM +0800, Paul Wise wrote:
On Sat, 2015-05-23 at 19:10 +0200, Dominic Hargreaves wrote:
This is rather strange; any ideas from DSA?
The underlying hosts do not have the same issue.
All of the guests use the same virtual CPU version/flags.
All of the guests use the same Linux kernel version.
Thanks for the update.
I guess diving into the Linux implementation of times(2) for clues would
be the next step for figuring out what the issue is here.
I'm taking the kernel maintainers in the loop. The status here is that
times(2) seems to be misbehaving on some i386 and amd64 debian.org virtual
hosts running jessie (under ganeti/qemu, with jessie on the underlying
hosts too). These hosts include at least barriere and x86-grnet-01.
The misbehaviour is that user time stays at zero all the time, as seen
for example with 'time yes'. This is making perl fail to build from
source due to test failures, and I'd expect it to affect other things too.
Any help is appreciated.
I can't reproduce this, but wonder if it's related to #784960?
There seems to be something fundamentally broken in
barriere.debian.org's CPU time accounting, not related to times(2) per
se. Just issuing
yes /dev/null
and firing up top -d1 gives the following interesting results:
- `yes' shows up taking 100% CPU time as expected, but
- pressing `1' shows that all CPUs are idle (!)
htop OTOH displays all CPUs as constantly 100% busy, which is
inconsistent with the system's load average (~0.8 at that point).
Also watching the output of `cat /proc/$(pidof yes)/stat | awk '{ print
$14, $15 }'' ($14 is utime, $15 is stime per proc(5)) indeed shows 100%
system time and 0 user time.
If you look at the `top' stats for all CPUs of barriere.debian.org, it
looks as if the only thing that's correctly being accounted for is
iowait time.
Cheers,
Apollon
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150524163819.ga24...@marvin.ws.skroutz.gr
Bug#773400: Cause of USB problem on beablebone black.
On Thu, 2015-05-21 at 16:46 -0400, Lennart Sorensen wrote: The config option CONFIG_USB_MUSB_TUSB6010 breaks the musb driver on anything that is not the tusb 6010, including the beaglebone. Turning off that option in the kernel config should fix it, or including the upstream patches that make it runtime detect what type of device it is on would work too. The upstream patches I believe are: 9d506fc6d2cdafdec5ce605036f5eeec9fd59657 usb: musb: Populate new IO functions for tusb6010 1b40fc57a517878cf4c2e16ce29cc9a066dc1064 usb: musb: Change to use new IO access d026e9c76aac3632af174cf02d5c94defa5e6026 usb: musb: Change end point selection to use new IO access 8a77f05aa39be879535f22a9757e703581fa1392 usb: musb: Pass fifo_mode in platform data If the kernel package in jessie was to include those patches, or just change the config option on arm, it ought to fix the beaglebone's usb problems. Thanks for the analysis. There were a few more related patches, but this got me on the right track. I've applied them for 3.16.7-ckt11-1. Ben. -- Ben Hutchings Experience is what causes a person to make new mistakes instead of old ones. signature.asc Description: This is a digitally signed message part
Processed: bug 786382 is forwarded to https://bugs.freedesktop.org/show_bug.cgi?id=90617
Processing commands for cont...@bugs.debian.org: forwarded 786382 https://bugs.freedesktop.org/show_bug.cgi?id=90617 Bug #786382 [src:linux] linux-image-4.0.0-1-amd64: Blank screen switching to a VT (Intel Haswell with HD4400) Set Bug forwarded-to-address to 'https://bugs.freedesktop.org/show_bug.cgi?id=90617'. thanks Stopping processing here. Please contact me if you need assistance. -- 786382: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786382 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/handler.s.c.143248181511132.transcr...@bugs.debian.org
Re: Bug#785557: perl: FTBFS on i386 and amd64: itimer problems on buildds?
On Sun, 2015-05-24 at 14:09 +0300, Niko Tyni wrote: On Sun, May 24, 2015 at 02:55:00PM +0800, Paul Wise wrote: On Sat, 2015-05-23 at 19:10 +0200, Dominic Hargreaves wrote: This is rather strange; any ideas from DSA? The underlying hosts do not have the same issue. All of the guests use the same virtual CPU version/flags. All of the guests use the same Linux kernel version. Thanks for the update. I guess diving into the Linux implementation of times(2) for clues would be the next step for figuring out what the issue is here. I'm taking the kernel maintainers in the loop. The status here is that times(2) seems to be misbehaving on some i386 and amd64 debian.org virtual hosts running jessie (under ganeti/qemu, with jessie on the underlying hosts too). These hosts include at least barriere and x86-grnet-01. The misbehaviour is that user time stays at zero all the time, as seen for example with 'time yes'. This is making perl fail to build from source due to test failures, and I'd expect it to affect other things too. Any help is appreciated. I can't reproduce this, but wonder if it's related to #784960? Ben. -- Ben Hutchings Experience is what causes a person to make new mistakes instead of old ones. signature.asc Description: This is a digitally signed message part
Upcoming stable point release (8.1)
Hi, The first point release for jessie (8.1) is scheduled for Saturday, June 6th. Stable NEW will be frozen during the preceding weekend. Regards, Adam signature.asc Description: This is a digitally signed message part
linux_3.16.7-ckt11-1_multi.changes ACCEPTED into proposed-updates-stable-new
Mapping jessie to stable. Mapping stable to proposed-updates. Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 24 May 2015 18:46:08 +0100 Source: linux Binary: linux-source-3.16 linux-doc-3.16 linux-manual-3.16 linux-support-3.16.0-4 linux-libc-dev linux-headers-3.16.0-4-all linux-headers-3.16.0-4-all-alpha kernel-image-3.16.0-4-alpha-generic-di nic-modules-3.16.0-4-alpha-generic-di nic-wireless-modules-3.16.0-4-alpha-generic-di nic-shared-modules-3.16.0-4-alpha-generic-di serial-modules-3.16.0-4-alpha-generic-di usb-serial-modules-3.16.0-4-alpha-generic-di ppp-modules-3.16.0-4-alpha-generic-di pata-modules-3.16.0-4-alpha-generic-di cdrom-core-modules-3.16.0-4-alpha-generic-di scsi-core-modules-3.16.0-4-alpha-generic-di scsi-modules-3.16.0-4-alpha-generic-di scsi-common-modules-3.16.0-4-alpha-generic-di scsi-extra-modules-3.16.0-4-alpha-generic-di loop-modules-3.16.0-4-alpha-generic-di btrfs-modules-3.16.0-4-alpha-generic-di ext4-modules-3.16.0-4-alpha-generic-di isofs-modules-3.16.0-4-alpha-generic-di jfs-modules-3.16.0-4-alpha-generic-di xfs-modules-3.16.0-4-alpha-generic-di fat-modules-3.16.0-4-alpha-generic-di md-modules-3.16.0-4-alpha-generic-di multipath-modules-3.16.0-4-alpha-generic-di usb-modules-3.16.0-4-alpha-generic-di usb-storage-modules-3.16.0-4-alpha-generic-di fb-modules-3.16.0-4-alpha-generic-di input-modules-3.16.0-4-alpha-generic-di event-modules-3.16.0-4-alpha-generic-di mouse-modules-3.16.0-4-alpha-generic-di nic-pcmcia-modules-3.16.0-4-alpha-generic-di pcmcia-modules-3.16.0-4-alpha-generic-di nic-usb-modules-3.16.0-4-alpha-generic-di sata-modules-3.16.0-4-alpha-generic-di core-modules-3.16.0-4-alpha-generic-di crc-modules-3.16.0-4-alpha-generic-di crypto-modules-3.16.0-4-alpha-generic-di crypto-dm-modules-3.16.0-4-alpha-generic-di ata-modules-3.16.0-4-alpha-generic-di nbd-modules-3.16.0-4-alpha-generic-di squashfs-modules-3.16.0-4-alpha-generic-di virtio-modules-3.16.0-4-alpha-generic-di zlib-modules-3.16.0-4-alpha-generic-di fuse-modules-3.16.0-4-alpha-generic-di srm-modules-3.16.0-4-alpha-generic-di linux-headers-3.16.0-4-common linux-image-3.16.0-4-alpha-generic linux-headers-3.16.0-4-alpha-generic linux-image-3.16.0-4-alpha-smp linux-headers-3.16.0-4-alpha-smp linux-headers-3.16.0-4-all-amd64 kernel-image-3.16.0-4-amd64-di nic-modules-3.16.0-4-amd64-di nic-wireless-modules-3.16.0-4-amd64-di nic-shared-modules-3.16.0-4-amd64-di serial-modules-3.16.0-4-amd64-di usb-serial-modules-3.16.0-4-amd64-di ppp-modules-3.16.0-4-amd64-di pata-modules-3.16.0-4-amd64-di cdrom-core-modules-3.16.0-4-amd64-di firewire-core-modules-3.16.0-4-amd64-di scsi-core-modules-3.16.0-4-amd64-di scsi-modules-3.16.0-4-amd64-di scsi-common-modules-3.16.0-4-amd64-di scsi-extra-modules-3.16.0-4-amd64-di loop-modules-3.16.0-4-amd64-di btrfs-modules-3.16.0-4-amd64-di ext4-modules-3.16.0-4-amd64-di isofs-modules-3.16.0-4-amd64-di jfs-modules-3.16.0-4-amd64-di ntfs-modules-3.16.0-4-amd64-di xfs-modules-3.16.0-4-amd64-di fat-modules-3.16.0-4-amd64-di md-modules-3.16.0-4-amd64-di multipath-modules-3.16.0-4-amd64-di usb-modules-3.16.0-4-amd64-di usb-storage-modules-3.16.0-4-amd64-di pcmcia-storage-modules-3.16.0-4-amd64-di fb-modules-3.16.0-4-amd64-di input-modules-3.16.0-4-amd64-di event-modules-3.16.0-4-amd64-di mouse-modules-3.16.0-4-amd64-di nic-pcmcia-modules-3.16.0-4-amd64-di pcmcia-modules-3.16.0-4-amd64-di nic-usb-modules-3.16.0-4-amd64-di sata-modules-3.16.0-4-amd64-di core-modules-3.16.0-4-amd64-di acpi-modules-3.16.0-4-amd64-di i2c-modules-3.16.0-4-amd64-di crc-modules-3.16.0-4-amd64-di crypto-modules-3.16.0-4-amd64-di crypto-dm-modules-3.16.0-4-amd64-di efi-modules-3.16.0-4-amd64-di ata-modules-3.16.0-4-amd64-di mmc-core-modules-3.16.0-4-amd64-di mmc-modules-3.16.0-4-amd64-di nbd-modules-3.16.0-4-amd64-di squashfs-modules-3.16.0-4-amd64-di speakup-modules-3.16.0-4-amd64-di virtio-modules-3.16.0-4-amd64-di uinput-modules-3.16.0-4-amd64-di sound-modules-3.16.0-4-amd64-di hyperv-modules-3.16.0-4-amd64-di udf-modules-3.16.0-4-amd64-di fuse-modules-3.16.0-4-amd64-di linux-image-3.16.0-4-amd64 linux-headers-3.16.0-4-amd64 linux-image-3.16.0-4-amd64-dbg xen-linux-system-3.16.0-4-amd64 linux-headers-3.16.0-4-all-arm64 kernel-image-3.16.0-4-arm64-di nic-modules-3.16.0-4-arm64-di nic-wireless-modules-3.16.0-4-arm64-di nic-shared-modules-3.16.0-4-arm64-di ppp-modules-3.16.0-4-arm64-di cdrom-core-modules-3.16.0-4-arm64-di scsi-core-modules-3.16.0-4-arm64-di scsi-modules-3.16.0-4-arm64-di loop-modules-3.16.0-4-arm64-di btrfs-modules-3.16.0-4-arm64-di ext4-modules-3.16.0-4-arm64-di isofs-modules-3.16.0-4-arm64-di jfs-modules-3.16.0-4-arm64-di xfs-modules-3.16.0-4-arm64-di fat-modules-3.16.0-4-arm64-di md-modules-3.16.0-4-arm64-di multipath-modules-3.16.0-4-arm64-di usb-modules-3.16.0-4-arm64-di usb-storage-modules-3.16.0-4-arm64-di input-modules-3.16.0-4-arm64-di event-modules-3.16.0-4-arm64-di
Processing of linux_3.16.7-ckt11-1_multi.changes
linux_3.16.7-ckt11-1_multi.changes uploaded successfully to localhost along with the files: linux_3.16.7-ckt11-1.dsc linux_3.16.7-ckt11.orig.tar.xz linux_3.16.7-ckt11-1.debian.tar.xz linux-support-3.16.0-4_3.16.7-ckt11-1_all.deb linux-doc-3.16_3.16.7-ckt11-1_all.deb linux-manual-3.16_3.16.7-ckt11-1_all.deb linux-source-3.16_3.16.7-ckt11-1_all.deb Greetings, Your Debian queue daemon (running on host franck.debian.org) -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1ywg4j-0005ha...@franck.debian.org
Uploading linux (4.0.4-1)
I intend to upload linux version 4.0.4-1 to unstable on Monday or Tuesday. Ben. -- Ben Hutchings Design a system any fool can use, and only a fool will want to use it. signature.asc Description: This is a digitally signed message part
