Bug#1059043: RFP: flashprog -- Identify, read, write, erase, and verify BIOS/ROM/flash chips
Package: wnpp Severity: wishlist * Package name: flashprog Version : 1.0 Upstream Contact: Nico Huber * URL : https://flashprog.org/ * License : GPL Programming Lang: C Description : Identify, read, write, erase, and verify BIOS/ROM/flash chips flashprog is a tool for identifying, reading, writing, verifying and erasing flash chips. It's often used to flash BIOS/EFI/coreboot/firmware/optionROM images in-system using a supported mainboard, but it also supports flashing of network cards (NICs), SATA controller cards, and other external devices which can program flash chips. It supports a wide range of DIP32, PLCC32, DIP8, SO8/SOIC8, TSOP32/40/48, and BGA chips, which use various protocols such as LPC, FWH, parallel flash, or SPI. The tool can be used to flash BIOS/firmware images for example -- be it proprietary BIOS images or coreboot (previously known as LinuxBIOS) images. It can also be used to read the current existing BIOS/firmware from a flash chip. Currently supported programmers include: * internal (for in-system flashing in the mainboard) * dummy (virtual programmer for testing flashprog) * atahpt (for flash ROMs on Highpoint ATA/RAID controllers) * atapromise (for flash ROMs on Promise PDC2026x ATA/RAID controllers) * atavia (for flash ROMs on VIA VT6421A SATA controllers) * buspirate_spi (for SPI flash ROMs attached to a Bus Pirate) * ch341a_spi (for SPI flash ROMs attached to WCH CH341A) * ch347_spi (for SPI flash ROMs attached to WCH CH347) * dediprog (for SPI flash ROMs attached to a Dediprog SF100) * developerbox_spi (for SPI flash ROMs on the 96Boards Developerbox) * digilent_spi (for SPI flash ROMs on iCEblink40 development boards) * dirtyjtag_spi (for SPI flash ROMs attached to DirtyJTAG-compatible devices) * drkaiser (for flash ROMs on Dr. Kaiser PC-Waechter PCI cards) * ft2232_spi (for SPI flash ROMs attached to an FT2232/FT4232H/FT232H family based USB SPI programmer), including the DLP Design DLP-USB1232H, FTDI FT2232H Mini-Module, FTDI FT4232H Mini-Module, openbiosprog-spi, Amontec JTAGkey/JTAGkey-tiny/JTAGkey-2, Dangerous Prototypes Bus Blaster, Olimex ARM-USB-TINY/-H, Olimex ARM-USB-OCD/-H, TIAO/DIYGADGET USB Multi-Protocol Adapter (TUMPA), TUMPA Lite, GOEPEL PicoTAP, Google Servo v1/v2, and FIC OpenMoko Neo1973 Debug board. * gfxnvidia (for flash ROMs on NVIDIA graphics cards) * it8212 (for flash ROMs on ITE IT8212F ATA/RAID controller) * jlink_spi (for SPI flash ROMs attached to SEGGER J-Link and compatible devices) * linux_gpio_spi (for SPI flash ROMs accessible via /dev/gpiochipX on Linux) * linux_mtd (for SPI flash ROMs accessible via /dev/mtdX on Linux) * linux_spi (for SPI flash ROMs accessible via /dev/spidevX.Y on Linux) * mstarddc_spi (for SPI flash ROMs accessible through DDC in MSTAR-equipped displays) * nic3com (for flash ROMs on 3COM network cards) * nicintel (for parallel flash ROMs on Intel 10/100Mbit network cards) * nicintel_eeprom (for SPI EEPROMs on Intel Gigabit network cards) * nicintel_spi (for SPI flash ROMs on Intel Gigabit network cards) * nicnatsemi (for flash ROMs on National Semiconductor DP838* network cards) * nicrealtek (for flash ROMs on Realtek and SMC 1211 network cards) * ogp_spi (for SPI flash ROMs on Open Graphics Project graphics card) * pickit2_spi (for SPI flash ROMs accessible via Microchip PICkit2) * pony_spi (for SPI flash ROMs attached to a SI-Prog serial port bitbanging adapter) * rayer_spi (for SPI flash ROMs attached to a RayeR parport based programmer) * satamv (for flash ROMs on Marvell SATA controllers) * satasii (for flash ROMs on Silicon Image SATA/IDE controllers) * serprog (for flash ROMs attached to a programmer speaking serprog), including AVR flasher by Urja Rannikko, AVR flasher by eightdot, Arduino Mega flasher by fritz, InSystemFlasher by Juhana Helovuo, and atmegaXXu2-flasher by Stefan Tauner. * stlinkv3_spi (for SPI flash ROMs attached to STMicroelectronics STLINK V3 devices) * usbblaster_spi (for SPI flash ROMs attached to an Altera USB-Blaster) -- flashprog is a fork of flashrom and a continuation of flashrom-stable. Hence the copied description (with sorted and updated device list). flashprog, like flashrom-stable before, provides far more regular releases and newer chipset support compared to flashrom, so up-to-date chipset support can hopefully make it into stable distributions in time.
Bug#1031251: Source code
Forgot to mention, there's nothing going on about flashrom-stable on the web page yet. Instructions how to fetch the source code and more can be found in the release announcement: https://mail.coreboot.org/hyperkitty/list/flashrom-sta...@flashrom.org/thread/HSHMBX7ZWPJC6MSAUMRKNHYBDFQLMIDJ/ Nico
Bug#1031251: RFP: flashrom-stable -- Identify, read, write, erase, and verify BIOS/ROM/flash chips
Package: wnpp Severity: wishlist X-Debbugs-Cc: nic...@gmx.de * Package name: flashrom-stable Version : 1.0 Upstream Contact: Nico Huber * URL : https://www.flashrom.org/ * License : GPL Programming Lang: C Description : Identify, read, write, erase, and verify BIOS/ROM/flash chips flashrom is a tool for identifying, reading, writing, verifying and erasing flash chips. It's often used to flash BIOS/EFI/coreboot/firmware/optionROM images in-system using a supported mainboard, but it also supports flashing of network cards (NICs), SATA controller cards, and other external devices which can program flash chips. It supports a wide range of DIP32, PLCC32, DIP8, SO8/SOIC8, TSOP32/40/48, and BGA chips, which use various protocols such as LPC, FWH, parallel flash, or SPI. The tool can be used to flash BIOS/firmware images for example -- be it proprietary BIOS images or coreboot (previously known as LinuxBIOS) images. It can also be used to read the current existing BIOS/firmware from a flash chip. Currently supported programmers include: * internal (for in-system flashing in the mainboard) * dummy (virtual programmer for testing flashrom) * atahpt (for flash ROMs on Highpoint ATA/RAID controllers) * atapromise (for flash ROMs on Promise PDC2026x ATA/RAID controllers) * atavia (for flash ROMs on VIA VT6421A SATA controllers) * buspirate_spi (for SPI flash ROMs attached to a Bus Pirate) * ch341a_spi (for SPI flash ROMs attached to WCH CH341A) * dediprog (for SPI flash ROMs attached to a Dediprog SF100) * developerbox_spi (for SPI flash ROMs on the 96Boards Developerbox) * digilent_spi (for SPI flash ROMs on iCEblink40 development boards) * dirtyjtag_spi (for SPI flash ROMs attached to DirtyJTAG-compatible devices) * drkaiser (for flash ROMs on Dr. Kaiser PC-Waechter PCI cards) * ft2232_spi (for SPI flash ROMs attached to an FT2232/FT4232H/FT232H family based USB SPI programmer), including the DLP Design DLP-USB1232H, FTDI FT2232H Mini-Module, FTDI FT4232H Mini-Module, openbiosprog-spi, Amontec JTAGkey/JTAGkey-tiny/JTAGkey-2, Dangerous Prototypes Bus Blaster, Olimex ARM-USB-TINY/-H, Olimex ARM-USB-OCD/-H, TIAO/DIYGADGET USB Multi-Protocol Adapter (TUMPA), TUMPA Lite, GOEPEL PicoTAP, Google Servo v1/v2, and FIC OpenMoko Neo1973 Debug board. * gfxnvidia (for flash ROMs on NVIDIA graphics cards) * it8212 (for flash ROMs on ITE IT8212F ATA/RAID controller) * jlink_spi (for SPI flash ROMs attached to SEGGER J-Link and compatible devices) * linux_mtd (for SPI flash ROMs accessible via /dev/mtdX on Linux) * linux_spi (for SPI flash ROMs accessible via /dev/spidevX.Y on Linux) * mstarddc_spi (for SPI flash ROMs accessible through DDC in MSTAR-equipped displays) * nic3com (for flash ROMs on 3COM network cards) * nicintel (for parallel flash ROMs on Intel 10/100Mbit network cards) * nicintel_eeprom (for SPI EEPROMs on Intel Gigabit network cards) * nicintel_spi (for SPI flash ROMs on Intel Gigabit network cards) * nicnatsemi (for flash ROMs on National Semiconductor DP838* network cards) * nicrealtek (for flash ROMs on Realtek and SMC 1211 network cards) * ogp_spi (for SPI flash ROMs on Open Graphics Project graphics card) * pickit2_spi (for SPI flash ROMs accessible via Microchip PICkit2) * pony_spi (for SPI flash ROMs attached to a SI-Prog serial port bitbanging adapter) * rayer_spi (for SPI flash ROMs attached to a RayeR parport based programmer) * satamv (for flash ROMs on Marvell SATA controllers) * satasii (for flash ROMs on Silicon Image SATA/IDE controllers) * serprog (for flash ROMs attached to a programmer speaking serprog), including AVR flasher by Urja Rannikko, AVR flasher by eightdot, Arduino Mega flasher by fritz, InSystemFlasher by Juhana Helovuo, and atmegaXXu2-flasher by Stefan Tauner. * stlinkv3_spi (for SPI flash ROMs attached to STMicroelectronics STLINK V3 devices) * usbblaster_spi (for SPI flash ROMs attached to an Altera USB-Blaster) -- flashrom-stable is a fork of flashrom. Hence the copied description (with sorted and updated device list). A flashrom-stable package will naturally conflict the flashrom package. flashrom-stable strives towards a regular release process, so up-to-date chipset support can hopefully make it into stable distributions in time. A note on building: `make` is still the official build process. The J-Link support (requires libjaylink) has to be enabled explicitly: `make CONFIG_JLINK_SPI=yes`. `meson` might work as well (it did for Debian somewhat before), but there is no guarantee that we are beyond all the growing pains that hit the flashrom-1.2 package.
Bug#1029557: debian-edu-config: Session exits on first login on roaming-workstation fails
Package: debian-edu-config Version: 2.11.56+deb11u4 Severity: normal Dear Maintainer, When a user tries to log in at a romaing workstation for the very first time the login prompt disappears, stays on the empty default-background for a few seconds and the returns to lightdm with a brief black-screen. On the second try everything works as expected. I suspect that pam_mklocaluser does not properly initialize the environment because the logs show some errors from pulseaudio as well as lightdm trying to write to the wrong home directory: Jan 24 14:08:38 am-5254007fbccd.intern pulseaudio[5100]: Failed to create secure directory (/skole/tjener/home0/teste s/.config/pulse): Datei oder Verzeichnis nicht gefunden Jan 24 14:08:47 am-5254007fbccd.intern lightdm[5053]: Error writing X authority: Failed to open X authority /skole/tjener/home0/testes/.Xauthority: No such file or directory This occurs on a debian-edu deployment which has been in use for about a year and I could also reproduce this behavior locally on a fresh install with one mainserver VM an one romaing-workstation VM. Regards Nico Winkelsträter -- Mit freundlichen Grüßen Nico Winkelsträter Trainee Administrator initOS GmbH Innungsstraße 7 21244 Buchholz i.d.N. Phone: +49 4105 56156-33 Fax: +49 4105 56156-10 Email: nico.winkelstrae...@initos.com Web: http://www.initos.com Geschäftsführung: Dr.-Ing. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke Sitz der Gesellschaft: Rosengarten – Klecken Amtsgericht Tostedt, HRB 205226 Steuer-Nr: 15/200/53247 USt-IdNr: DE815580155Jan 24 14:08:37 am-5254007fbccd.intern lightdm[5053]: pam_sss(lightdm:auth): authentication success; logname= uid=0 euid=0 tty=:0 ruser= rhost= user=testes Jan 24 14:08:37 am-5254007fbccd.intern lightdm[5053]: gkr-pam: unable to locate daemon control file Jan 24 14:08:37 am-5254007fbccd.intern lightdm[5053]: gkr-pam: stashed password to try later in open session Jan 24 14:08:37 am-5254007fbccd.intern lightdm[5053]: Error getting user list from org.freedesktop.Accounts: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Accounts was not provided by any .service files Jan 24 14:08:37 am-5254007fbccd.intern lightdm[608]: g_dbus_connection_call_sync_internal: assertion 'G_IS_DBUS_CONNECTION (connection)' failed Jan 24 14:08:37 am-5254007fbccd.intern lightdm[608]: g_dbus_connection_call_sync_internal: assertion 'G_IS_DBUS_CONNECTION (connection)' failed Jan 24 14:08:37 am-5254007fbccd.intern systemd[1]: Stopping Session c8 of user lightdm. Jan 24 14:08:37 am-5254007fbccd.intern lightdm[4969]: pam_unix(lightdm-greeter:session): session closed for user lightdm Jan 24 14:08:37 am-5254007fbccd.intern systemd[1]: session-c8.scope: Succeeded. Jan 24 14:08:37 am-5254007fbccd.intern systemd[1]: Stopped Session c8 of user lightdm. Jan 24 14:08:37 am-5254007fbccd.intern systemd-logind[603]: Removed session c8. Jan 24 14:08:37 am-5254007fbccd.intern lightdm[5053]: pam_unix(lightdm:session): session opened for user testes(uid=1007) by (uid=0) Jan 24 14:08:37 am-5254007fbccd.intern systemd[1]: Created slice User Slice of UID 1007. Jan 24 14:08:37 am-5254007fbccd.intern systemd[1]: Starting User Runtime Directory /run/user/1007... Jan 24 14:08:37 am-5254007fbccd.intern pulseaudio[4990]: Unable to set sw params: Keine Berechtigung Jan 24 14:08:37 am-5254007fbccd.intern pulseaudio[4990]: Failed to set software parameters: Keine Berechtigung Jan 24 14:08:37 am-5254007fbccd.intern pulseaudio[4990]: Error opening PCM device front:0: Datei oder Verzeichnis nicht gefunden Jan 24 14:08:37 am-5254007fbccd.intern systemd-logind[603]: New session 40 of user testes. Jan 24 14:08:37 am-5254007fbccd.intern systemd[4973]: pulseaudio.service: Succeeded. Jan 24 14:08:37 am-5254007fbccd.intern systemd[1]: Finished User Runtime Directory /run/user/1007. Jan 24 14:08:37 am-5254007fbccd.intern systemd[1]: Starting User Manager for UID 1007... Jan 24 14:08:37 am-5254007fbccd.intern systemd[5060]: pam_unix(systemd-user:session): session opened for user testes(uid=1007) by (uid=0) Jan 24 14:08:37 am-5254007fbccd.intern systemd[5060]: Queued start job for default target Main User Target. Jan 24 14:08:37 am-5254007fbccd.intern systemd[5060]: Created slice User Application Slice. Jan 24 14:08:37 am-5254007fbccd.intern systemd[5060]: Reached target Paths. Jan 24 14:08:37 am-5254007fbccd.intern systemd[5060]: Reached target Timers. Jan 24 14:08:37 am-5254007fbccd.intern systemd[5060]: Starting D-Bus User Message Bus Socket. Jan 24 14:08:37 am-5254007fbccd.intern systemd[5060]: Listening on GnuPG network certificate management daemon. Jan 24 14:08:37 am-5254007fbccd.intern systemd[5060]: Listening on GnuPG cryptographic agent and passphrase cache (access for web browsers). Jan 24 14:08:37 am-5254007fbccd.intern systemd[5060]: Listening on GnuPG cryptographic agent and passphrase cache (restricted). Jan 24 14:08:37 am-5254007fbccd.intern systemd[5060]: Listening on G
Bug#1028447: cdist: unusable with python 3.11
Good evening everyone, Axel Beckert writes: > Hi, > > Steve Langasek wrote: >> On Sun, Jan 15, 2023 at 10:10:54AM +0100, s3v wrote: >> > > Anyway, this package has no maintainer and upstream has not fixed this, >> > > and >> > > there are no reverse-dependencies, so I would suggest the package should >> > > just be removed. > > That's IMHO way too harsh given that the package is uptodate with the > current upstream release despite being orphaned and the issue is > easily fixable. I agree and it has been fixed some weeks ago. >> > Unless I missed something, upstream fixed this issue in [1] >> > After applying this commit, I was able to build cdist in a sid >> > chroot environment. >> >> > [1] https://code.ungleich.ch/ungleich-public/cdist/commit/b974969f28f4 >> >> Well, that's not the upstream repo listed in debian/copyright, so if someone >> wants to fix this bug perhaps they also want to fix the upstream pointer. > > Ack, https://github.com/telmich/cdist redirects to > https://github.com/ungleich/cdist, but last commit there is from > November 2021 and there's no note that it's no more updated. So, that's a funky problem, I know. We moved away from github, long, long time ago (probably 2021, that's why you see the last commit there). However some in the cdist community wanted to keep the git repo on github alive to allow easier contributions. As this did not really materialise, we might actually delete and/or redirect that repo to code.ungleich.ch, too. > Funnily https://code.ungleich.ch/ungleich-public/cdist/#contributing > refers to https://github.com/ungleich/cdist/pulls Yes, it says "both" for contributing, but it does not say "we keep the github repo updated". But yes, I can see how this might be confusing. Again, the proper upstream URL is https://code.ungleich.ch/ungleich-public/cdist/ and actually we also have a shiny website on... https://www.cdi.st/ which references only the upstream repo. > I'll take upstream into Cc so they're aware of these upstream > infrastructure issues misleading users into thinking that upstream's > development has stalled. Much appreciated. I added to my todo list to replace the master branch on github with a pointer to code.ungleich.ch, referencing this thread. > I might also do a QA upload fixing these issues. No promises though, > as I'm a bit out of time these days. Thanks a lot Axel, much appreciated. Best regards from Paris, Nico -- Sustainable and modern Infrastructures by ungleich.ch
Bug#995940: Reproduced on Fujitsu Lifebook E558
just for the record: I tried to install debian with a recent usb image to a Fujitsu Lifebook E558 and also this error. N.
Bug#1012555: rng haveged speed up lighttpd start?
Dear Maintainer, thanks a lot for your fast and great answer. I try php7.4-fpm on debian 11 and the startup time was acceptable. After that i try the php7.3-fpm at debian 10 and got the same issues (timeout). The service did not start after boot, sometimes. I try some more research and found the behaviour, the solution at the thread was to install an random generator. After installing rng at debian, was the php-fpm startup fast. I try the old configuration with php-cgi, the result was an fast lighttpd startup. I have no idea why the rng service boost my start. i although try haveged, with the same result an fast lighttpd start. Can you explain the behavior? (only if you have time) thanks again
Bug#1012555: some more logs
hello, i ve some more log entries: 2022-06-09 07:28:12: server.c.1513) server started (lighttpd/1.4.59) 2022-06-09 07:28:16: gw_backend.c.944) gw - found a host 0 2022-06-09 07:28:16: gw_backend.c.944) gw - found a host 0 2022-06-09 07:28:16: gw_backend.c.228) got proc: pid: 171 socket: unix:/run/lighttpd/php.socket-0 load: 1 2022-06-09 07:28:16: gw_backend.c.944) gw - found a host 0 2022-06-09 07:28:16: gw_backend.c.944) gw - found a host 0 2022-06-09 07:28:16: gw_backend.c.228) got proc: pid: 171 socket: unix:/run/lighttpd/php.socket-0 load: 2 2022-06-09 07:28:16: gw_backend.c.944) gw - found a host 0 2022-06-09 07:28:16: gw_backend.c.944) gw - found a host 0 2022-06-09 07:28:16: gw_backend.c.228) got proc: pid: 171 socket: unix:/run/lighttpd/php.socket-0 load: 3 2022-06-09 07:28:15: gw_backend.c.944) gw - found a host 0 2022-06-09 07:28:15: gw_backend.c.944) gw - found a host 0 2022-06-09 07:28:15: gw_backend.c.228) got proc: pid: 171 socket: unix:/run/lighttpd/php.socket-0 load: 4 2022-06-09 07:28:15: gw_backend.c.944) gw - found a host 0 2022-06-09 07:28:15: gw_backend.c.944) gw - found a host 0 2022-06-09 07:28:15: gw_backend.c.228) got proc: pid: 171 socket: unix:/run/lighttpd/php.socket-0 load: 5 2022-06-09 07:28:16: gw_backend.c.944) gw - found a host 0 2022-06-09 07:28:16: gw_backend.c.944) gw - found a host 0 2022-06-09 07:28:16: gw_backend.c.228) got proc: pid: 171 socket: unix:/run/lighttpd/php.socket-0 load: 6 2022-06-09 07:28:16: gw_backend.c.944) gw - found a host 0 2022-06-09 07:28:16: gw_backend.c.944) gw - found a host 0 2022-06-09 07:28:16: gw_backend.c.228) got proc: pid: 171 socket: unix:/run/lighttpd/php.socket-0 load: 7 2022-06-09 07:28:17: gw_backend.c.944) gw - found a host 0 2022-06-09 07:28:17: gw_backend.c.944) gw - found a host 0 2022-06-09 07:28:17: gw_backend.c.228) got proc: pid: 171 socket: unix:/run/lighttpd/php.socket-0 load: 8 2022-06-09 07:28:17: gw_backend.c.944) gw - found a host 0 2022-06-09 07:28:17: gw_backend.c.944) gw - found a host 0 2022-06-09 07:28:17: gw_backend.c.228) got proc: pid: 171 socket: unix:/run/lighttpd/php.socket-0 load: 9 2022-06-09 07:28:18: gw_backend.c.944) gw - found a host 0 2022-06-09 07:28:18: gw_backend.c.228) got proc: pid: 171 socket: unix:/run/lighttpd/php.socket-0 load: 10 2022-06-09 07:28:18: gw_backend.c.944) gw - found a host 0 2022-06-09 07:28:18: gw_backend.c.944) gw - found a host 0 2022-06-09 07:28:18: gw_backend.c.228) got proc: pid: 171 socket: unix:/run/lighttpd/php.socket-0 load: 11 2022-06-09 07:28:18: gw_backend.c.944) gw - found a host 0 2022-06-09 07:28:18: gw_backend.c.944) gw - found a host 0 2022-06-09 07:28:18: gw_backend.c.228) got proc: pid: 171 socket: unix:/run/lighttpd/php.socket-0 load: 12 2022-06-09 07:28:19: gw_backend.c.944) gw - found a host 0 2022-06-09 07:28:19: gw_backend.c.944) gw - found a host 0 2022-06-09 07:28:19: gw_backend.c.228) got proc: pid: 171 socket: unix:/run/lighttpd/php.socket-0 load: 13 2022-06-09 07:28:19: gw_backend.c.944) gw - found a host 0 2022-06-09 07:28:19: gw_backend.c.944) gw - found a host 0 2022-06-09 07:28:19: gw_backend.c.228) got proc: pid: 171 socket: unix:/run/lighttpd/php.socket-0 load: 14 2022-06-09 07:28:20: gw_backend.c.944) gw - found a host 0 2022-06-09 07:28:20: gw_backend.c.944) gw - found a host 0 2022-06-09 07:28:20: gw_backend.c.228) got proc: pid: 171 socket: unix:/run/lighttpd/php.socket-0 load: 15 2022-06-09 07:28:20: gw_backend.c.944) gw - found a host 0 2022-06-09 07:28:20: gw_backend.c.944) gw - found a host 0 2022-06-09 07:28:20: gw_backend.c.228) got proc: pid: 171 socket: unix:/run/lighttpd/php.socket-0 load: 16 2022-06-09 07:28:21: gw_backend.c.944) gw - found a host 0 2022-06-09 07:28:21: gw_backend.c.944) gw - found a host 0 2022-06-09 07:28:21: gw_backend.c.228) got proc: pid: 171 socket: unix:/run/lighttpd/php.socket-0 load: 17 2022-06-09 07:28:21: gw_backend.c.944) gw - found a host 0 2022-06-09 07:28:21: gw_backend.c.944) gw - found a host 0 2022-06-09 07:28:21: gw_backend.c.228) got proc: pid: 171 socket: unix:/run/lighttpd/php.socket-0 load: 18 2022-06-09 07:28:23: gw_backend.c.944) gw - found a host 0 2022-06-09 07:28:23: gw_backend.c.944) gw - found a host 0 2022-06-09 07:28:23: gw_backend.c.228) got proc: pid: 171 socket: unix:/run/lighttpd/php.socket-0 load: 19 2022-06-09 07:28:23: gw_backend.c.944) gw - found a host 0 2022-06-09 07:28:23: gw_backend.c.944) gw - found a host 0 2022-06-09 07:28:23: gw_backend.c.228) got proc: pid: 171 socket: unix:/run/lighttpd/php.socket-0 load: 20 2022-06-09 07:28:24: gw_backend.c.944) gw - found a host 0 2022-06-09 07:28:24: gw_backend.c.944) gw - found a host 0 2022-06-09 07:28:24: gw_backend.c.228) got proc: pid: 171 socket: unix:/run/lighttpd/php.socket-0 load: 21 2022-06-09 07:28:24: gw_backend.c.944) gw - found a host 0 2022-06-09 07:28:24: gw_backend.c.944) gw - found a host 0 2022-06-09 07:28:24:
Bug#1012555: lighttpd: starte takes over an minute (php.socket-0 load: 1)
Package: lighttpd
Version: 1.4.59-1+deb11u1
Severity: normal
Dear Maintainer,
we use an faster sd-card in our embedded system, nothing else.
Now the start from the lighttpd server takes often over an minute.
we use debian 10, for the bug submit i upgrade to bullseye, but the behaviour
is the same.
Without fastcgi/php lighttpd start fast, only some second.
I can send some error.log from the debian 10 system, if needed, but it seems to
identical
Sometimes we got the following error:
2022-06-09 06:26:17: gw_backend.c.238) establishing connection failed: socket:
unix:/run/lighttpd/php.socket-0: Resource temporarily unavailable
2022-06-09 06:26:17: gw_backend.c.255) backend error; we'll disable for 1secs
and send the request to another backend instead:load: 130
2022-06-09 06:26:17: gw_backend.c.262) If this happened on Linux: You have run
out of local ports. Check the manual, section Performance how to handle this.
-- System Information:
Debian Release: 11.3
APT prefers stable
APT policy: (500, 'stable')
Architecture: armhf (armv7l)
Kernel: Linux 4.14.126-rt62-ltsi (SMP w/2 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages lighttpd depends on:
ii init-system-helpers 1.60
ii libc62.31-13+deb11u3
ii libcrypt11:4.4.18-4
ii libnettle8 3.7.3-1
ii libpcre3 2:8.39-13
ii libxxhash0 0.8.0-2
ii lsb-base 11.1.0
ii mime-support 3.66
Versions of packages lighttpd recommends:
ii lighttpd-mod-deflate 1.4.59-1+deb11u1
ii lighttpd-mod-openssl 1.4.59-1+deb11u1
ii perl 5.32.1-4+deb11u2
ii spawn-fcgi1.6.4-2
Versions of packages lighttpd suggests:
pn apache2-utils
pn lighttpd-doc
pn lighttpd-mod-authn-gssapi
pn lighttpd-mod-authn-pam
pn lighttpd-mod-authn-sasl
pn lighttpd-mod-geoip
pn lighttpd-mod-maxminddb
pn lighttpd-mod-trigger-b4-dl
pn lighttpd-mod-vhostdb-pgsql
pn lighttpd-mod-webdav
pn lighttpd-modules-dbi
ii lighttpd-modules-ldap 1.4.59-1+deb11u1
pn lighttpd-modules-lua
ii lighttpd-modules-mysql 1.4.59-1+deb11u1
ii openssl 1.1.1n-0+deb11u1
ii php-cgi 2:7.4+76
pn php-fpm
ii php7.4-cgi [php-cgi]7.4.28-1+deb11u1
pn rrdtool
-- Configuration Files:
/etc/lighttpd/conf-available/10-ssl.conf changed:
server.modules += ( "mod_openssl" )
ssl.pemfile = "/etc/lighttpd/server.pem"
ssl.cipher-list = "HIGH"
$SERVER["socket"] == "0.0.0.0:443" {
ssl.engine = "enable"
}
include_shell "/usr/share/lighttpd/use-ipv6.pl 443"
/etc/lighttpd/lighttpd.conf changed:
server.modules = (
"mod_indexfile",
"mod_access",
"mod_alias",
"mod_redirect",
)
server.document-root= "/var/www/html"
server.upload-dirs = ( "/var/cache/lighttpd/uploads" )
server.errorlog = "/var/log/lighttpd/error.log"
server.pid-file = "/run/lighttpd.pid"
server.username = "www-data"
server.groupname= "www-data"
server.port = 80
fastcgi.debug = 1
server.feature-flags += ("server.h2proto" => "enable")
server.feature-flags += ("server.h2c" => "enable")
server.feature-flags += ("server.graceful-shutdown-timeout" => 5)
server.http-parseopts = (
"header-strict" => "enable",# default
"host-strict" => "enable",# default
"host-normalize" => "enable",# default
"url-normalize-unreserved"=> "enable",# recommended highly
"url-normalize-required" => "enable",# recommended
"url-ctrls-reject"=> "enable",# recommended
"url-path-2f-decode" => "enable",# recommended highly (unless breaks app)
#"url-path-2f-reject" => "enable",
"url-path-dotseg-remove" => "enable",# recommended highly (unless breaks app)
#"url-path-dotseg-reject" => "enable",
#"url-query-20-plus" => "enable",# consistency in query string
)
index-file.names= ( "index.php", "index.html" )
url.access-deny = ( "~", ".inc" )
static-file.exclude-extensions = ( ".php", ".pl", ".fcgi" )
include_shell "/usr/share/lighttpd/use-ipv6.pl " + server.port
include_shell "/usr/share/lighttpd/create-mime.conf.pl"
include "/etc/lighttpd/conf-enabled/*.conf"
server.modules += (
"mod_dirlisting",
"mod_staticfile",
)
-- no debconf information
Bug#996507: trilinos-all-dev: No rule to make target '/usr/lib/x86_64-linux-gnu/libdl.so'
Package: trilinos-all-dev Version: 12.18.1-2 Severity: normal X-Debbugs-Cc: nico.schloe...@gmail.com Dear Maintainer, First of all, I need to say because I'm partly responsible for making this a "monster" package of packages. It really should have been a libtrilinos-dev with no subpackaging, this would have made maintaining the thing a lot easier. Anyway. I've just tried to build my old Trilinos package [1] for old times' sake, and it fails with ``` Scanning dependencies of target mikado [ 8%] Building CXX object src/CMakeFiles/mikado.dir/helpers.cpp.o [ 16%] Building CXX object src/CMakeFiles/mikado.dir/nonlinear_solver.cpp.o make[2]: *** No rule to make target '/usr/lib/x86_64-linux-gnu/libdl.so', neede ``` Not sure what's going wrong, but looks like an outdated build on Debian's side. Any hints? Cheers, Nico [1] https://github.com/nschloe/mikado -- System Information: Debian Release: 11.0 APT prefers impish APT policy: (500, 'impish') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.13.0-16-generic (SMP w/8 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages trilinos-all-dev depends on: ii libtrilinos-amesos-dev 12.18.1-2 ii libtrilinos-amesos2-dev12.18.1-2 ii libtrilinos-anasazi-dev12.18.1-2 ii libtrilinos-aztecoo-dev12.18.1-2 ii libtrilinos-belos-dev 12.18.1-2 ii libtrilinos-epetra-dev 12.18.1-2 ii libtrilinos-epetraext-dev 12.18.1-2 ii libtrilinos-galeri-dev 12.18.1-2 ii libtrilinos-globipack-dev 12.18.1-2 ii libtrilinos-ifpack-dev 12.18.1-2 ii libtrilinos-ifpack2-dev12.18.1-2 ii libtrilinos-intrepid-dev 12.18.1-2 ii libtrilinos-intrepid2-dev 12.18.1-2 ii libtrilinos-isorropia-dev 12.18.1-2 ii libtrilinos-kokkos-dev 12.18.1-2 ii libtrilinos-kokkos-kernels-dev 12.18.1-2 ii libtrilinos-komplex-dev12.18.1-2 ii libtrilinos-ml-dev 12.18.1-2 ii libtrilinos-moertel-dev12.18.1-2 ii libtrilinos-muelu-dev 12.18.1-2 ii libtrilinos-nox-dev12.18.1-2 ii libtrilinos-optipack-dev 12.18.1-2 ii libtrilinos-pamgen-dev 12.18.1-2 ii libtrilinos-phalanx-dev12.18.1-2 ii libtrilinos-pike-dev 12.18.1-2 ii libtrilinos-piro-dev 12.18.1-2 ii libtrilinos-pliris-dev 12.18.1-2 ii libtrilinos-rol-dev12.18.1-2 ii libtrilinos-rtop-dev 12.18.1-2 ii libtrilinos-rythmos-dev12.18.1-2 ii libtrilinos-sacado-dev 12.18.1-2 ii libtrilinos-shards-dev 12.18.1-2 ii libtrilinos-shylu-dev 12.18.1-2 ii libtrilinos-stokhos-dev12.18.1-2 ii libtrilinos-stratimikos-dev12.18.1-2 ii libtrilinos-teko-dev 12.18.1-2 ii libtrilinos-teuchos-dev12.18.1-2 ii libtrilinos-thyra-dev 12.18.1-2 ii libtrilinos-tpetra-dev 12.18.1-2 ii libtrilinos-trilinoscouplings-dev 12.18.1-2 ii libtrilinos-triutils-dev 12.18.1-2 ii libtrilinos-xpetra-dev 12.18.1-2 ii libtrilinos-zoltan-dev 12.18.1-2 ii libtrilinos-zoltan2-dev12.18.1-2 trilinos-all-dev recommends no packages. Versions of packages trilinos-all-dev suggests: pn trilinos-doc
Bug#996336: pygalmesh: autopkgtest regression on i386
Yeah, that's a little weird. And it only occurs on i386? Sounds like a CGAL bug then. On Wed, Oct 13, 2021 at 3:24 PM Drew Parsons wrote: > > On 2021-10-13 13:42, Nico Schlömer wrote: > > Or PR upstream. I can merge and release any time. > > Thanks Nico. I'll check which tolerances it needs and file a PR. > > The error in test_rectangle might need your attention, > "At index 0 diff: 279 != 276". I guess it's not just tolerances. > > Drew
Bug#996336: pygalmesh: autopkgtest regression on i386
Or PR upstream. I can merge and release any time. Cheers, Nico On Wed, Oct 13, 2021 at 1:39 PM Drew Parsons wrote: > > Not entirely unexpected. Upstream reorganized tests and tolerances, so > I wanted to check if we had a full pass or not. > Looks like we'll have to reinstate test_relax_tolerance.patch > > > On 2021-10-13 12:03, Adrian Bunk wrote: > > Source: pygalmesh > > Version: 0.10.5-1 > > Severity: serious > > > > https://ci.debian.net/data/autopkgtest/testing/i386/p/pygalmesh/15928897/log.gz > > > > ... > > <https://github.com/nschloe/pygalmesh/pull/47> > > assert abs(max(mesh.points[:, 2]) - 1.0) < 1.1e-3 > >> assert abs(min(mesh.points[:, 2]) + 0.0) < tol > > E assert 0.0010112326126545668 < 0.001 > > E+ where 0.0010112326126545668 = abs((-0.0010112326 + 0.0)) > > E+where -0.0010112326 = min(array([ 0.e+00, > > 1.e+00, 0.e+00, 1.e+00,\n > > 0.e+00, 1.e+00, 0...-01,\n4.62765425e-01, > > 8.98388922e-02, 3.73478711e-01, 4.52255577e-01,\n > > 9.99695361e-01], dtype=float32)) > > >
Bug#971525: ITP: python3-briar-wrapper -- Wrapper around the Briar Headless REST API
I posted some updates to the packaging of briar-headless in [0] which is currently blocking this ITP. tl;dr: Plans to get into next Debian stable release were given up and The Briar Project will now focus on setting up their own APT repository [1]. [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971526#10 [1] https://code.briarproject.org/briar/briar-debian/-/issues/3
Bug#971524: ITP: briar-gtk -- Desktop and mobile client for Briar p2p messaging
I posted some updates to the packaging of briar-headless in [0] which is currently blocking this ITP. tl;dr: Plans to get into next Debian stable release were given up and The Briar Project will now focus on setting up their own APT repository [1]. [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971526#10 [1] https://code.briarproject.org/briar/briar-debian/-/issues/3
Bug#971526: ITP: briar-headless -- Core library exposing REST API
Some updates on this: * The Briar Project now offers official briar-headless.jar files at e.g. [0] * briar-headless in Debian main is not only blocked by Kotlin, but also by Gradle; both need to be packaged with recent versions before packaging briar-headless can start * Additionally, each (Gradle) dependency of briar-headless needs to be packaged separately for Debian main * Plans to get into next Debian stable release with a Debian contrib binary were given up * Efforts will now be focused on providing an official APT repository of The Briar Project [1] * A mail to debian-java confirmed all of the above [2] Updates to this ITP will also be published at [3]. [0] https://briarproject.org/jar/briar-headless-1.2.12.jar [1] https://code.briarproject.org/briar/briar-debian/-/issues/3 [2] https://lists.debian.org/debian-java/2020/10/msg00010.html [3] https://code.briarproject.org/briar/briar-debian/-/issues/1
Bug#971526: ITP: briar-headless -- Core library exposing REST API
Package: wnpp Severity: wishlist Owner: Nico Alt -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: briar-headless Version : 1.2.9 Upstream Author : The Briar Project * URL : https://briarproject.org/ * License : GPLv3 Programming Lang: Java, Kotlin Description : Core library exposing REST API Briar is a messaging app designed for activists, journalists, and anyone else who needs a safe, easy and robust way to communicate. Unlike traditional messaging apps, Briar doesn't rely on a central server - messages are synchronized directly between the users' devices. If the internet's down, Briar can sync via Bluetooth or Wi-Fi, keeping the information flowing in a crisis. If the internet's up, Briar can sync via the Tor network, protecting users and their relationships from surveillance. This package contains the Briar Headless Java/Kotlin core library that's exposing a REST API used by python3-briar-wrapper. Packaging briar-headless in compliance with DFSG currently isn't possible because parts of it are written in Kotlin that isn't packaged yet in Debian. Until it's possible to package briar-headless in compliance with DFSG, my idea was to use official (reproducible) jars provided by the core developers of the Briar Project and publish them as packages in Debian contrib: https://code.briarproject.org/briar/briar-debian Another potential problem that might occur in future is that Briar needs full access to the Tor process and therefore ships its own Tor binary, i.e. it's copying code. You can find more information on why it does this and how it could be changed in future here: https://code.briarproject.org/briar/python-briar-wrapper/-/issues/15 I use Briar Headless myself, but it was developed by other core developers of the Briar Project. I plan to maintain this project and its dependencies in Debian, but I'm always open to and appreciating any help by potential co-maintainers. Additionally, I'm looking for a sponsor. -BEGIN PGP SIGNATURE- iQJHBAEBCAAxFiEEVYvpBxymykTb9VdrlaDa99vHtUgFAl91mDETHG5pY29hbHRA cG9zdGVvLm9yZwAKCRCVoNr328e1SDX8D/99WhjE7Ghs5LX6u4jIiV5mLHJo+mWE bCrf0kPYlDf1IbizDHVNXUX5VERBues47Cw+l+ufT9ErnnNn/rgeZ0rYqfuHyOCW EBG+WgmxSeQjWhfBY5YXtoOHpFSTMC5LjXVbslQC3r/ozg6iyve1VmqGWRPRvg3S RVrVwU8mJyGBl5r7Q7r1oBN3C9REmUzEHIcc75/qsJxXnElVYU1y1/S2fxzsdRlY gN0F2duJGQ/4Admxe/XPdtGZFHox4CJogoceWElpJgINBPrHesSrN0kBP5OTT+bw WjqIYwAqupWF+sLLAPWyZgcXqzFVQUD96Svi4HpQevVkf/jQS1ykcuLPNiflGS/h pMD1eWpviTIFJqrJ6DqL7DwRgd2Yic0X99F6QPtxy00hGWrc+9oq+bgOgchMg+l/ fL8CCisu0W1vulR0RNOcmHrcWi9+T9DFYikzqajB4eRqsNnRfCEO/2JRd8aow9yw hTsoQ9JFtMex8BvhbLiiszf3dV88RfcTx8cTgWijik/xDknVcxahZ1kpO++GengA 06wa9WI7ubRwG+rxV5Yn3FD8hSXZ+eCIIE2dbFBxCsERuyTkCUfkfEcAyjd/rj67 hKlIeo/6G2I/2WSEns6xuwea3lmDh3tEGYm6mnuI31iHRCEu+JanYwwCH8h7piDc 6vb6bYTbkYhOsw== =66H/ -END PGP SIGNATURE-
Bug#971525: ITP: python3-briar-wrapper -- Wrapper around the Briar Headless REST API
Package: wnpp Severity: wishlist Owner: Nico Alt -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: python3-briar-wrapper Version : 0.0.4 Upstream Author : Nico Alt * URL : https://code.briarproject.org/briar/python-briar-wrapper * License : AGPLv3 Programming Lang: Python Description : Wrapper around the Briar Headless REST API Briar is a messaging app designed for activists, journalists, and anyone else who needs a safe, easy and robust way to communicate. Unlike traditional messaging apps, Briar doesn't rely on a central server - messages are synchronized directly between the users' devices. If the internet's down, Briar can sync via Bluetooth or Wi-Fi, keeping the information flowing in a crisis. If the internet's up, Briar can sync via the Tor network, protecting users and their relationships from surveillance. This package contains the Python wrapper around the REST API exposed by briar-headless. It is used by briar-gtk and in future might also be used in briar_repl [0], a commandline client for Briar. Briar GTK is already packaged according to DFSG, but it depends on briar-headless which can't be build with Debian packages due to Kotlin: https://code.briarproject.org/briar/python-briar-wrapper/-/tree/main/debian I develop and use briar_wrapper myself with support by other core developers of the Briar Project. I plan to maintain this project and its dependencies in Debian, but I'm always open to and appreciating any help by potential co-maintainers. Additionally, I'm looking for a sponsor. [0]: https://code.briarproject.org/fphemeral/briar_repl -BEGIN PGP SIGNATURE- iQJHBAEBCAAxFiEEVYvpBxymykTb9VdrlaDa99vHtUgFAl91l38THG5pY29hbHRA cG9zdGVvLm9yZwAKCRCVoNr328e1SJC3D/wOAh1Rx5UqMMtXBOld3g++/BU+Twh5 +j0KUPPgzyrNdguVLyH95g/iaa2ddmXE6bQZLnWcEyc7ui4Fm9wiHoYd9mccCBrF dKxXcBejg1D4reYpuKtpkM/2vQrEn5pn47pcH2H6g6mhztbzRABbztbKV6PWhZHN OujpfFGNelGhIu/OQEyrTo2aG+L6Tw72ymS73rF/+RoHYN6VdmRLpBOxqaub3tEF 8xZMSD3UKci/PqSDjtFyS8Jg3EFnvtiGGXsWwxUhKtiCoE6GOvia7VXPXqtXeXu3 Y1ByqQ0Qi2ORKN0qz0Bqe2nlihJftt2+LuSSW0IrRjqvDMdQLMMXsjpIHozKCUPJ 7HGWMXunFnAIJPHe9ggTjTw+CFV0AbEdBbR5nGK4MzgaykrdHBXkg0lNyyzHyr6r sq38WEXPC6cql8eoob4twefTHD9h6eYMMe/gQY+L5UCo8rC/LJMxn9ng2yq68dek H/JOob61p1Frf4iNHJ7hE4N8q+fyUlAMlJmKPM5UZuFyzxZT8/SCx+kT4//vdJ2v /lFZhXe+Knnp5fqIZGMo3czhnefPdeFouwMXecDOnZeYaBnmMBAn8G9lREtqDYep q2BWM4V+PxFO1zeVGEvjk/D3Hw54NYWW4GlJ7KgV8gCgIjGRfCDUOCv5MbU7zF5e SfpJCM9wMMamgg== =H5Qq -END PGP SIGNATURE-
Bug#971524: ITP: briar-gtk -- Desktop and mobile client for Briar p2p messaging
Package: wnpp Severity: wishlist Owner: Nico Alt -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: briar-gtk Version : 0.1.0 Upstream Author : Nico Alt * URL : https://code.briarproject.org/briar/briar-gtk * License : AGPLv3 Programming Lang: Python Description : Desktop and mobile client for Briar p2p messaging Briar is a messaging app designed for activists, journalists, and anyone else who needs a safe, easy and robust way to communicate. Unlike traditional messaging apps, Briar doesn't rely on a central server - messages are synchronized directly between the users' devices. If the internet's down, Briar can sync via Bluetooth or Wi-Fi, keeping the information flowing in a crisis. If the internet's up, Briar can sync via the Tor network, protecting users and their relationships from surveillance. This package contains the GTK client that uses python3-briar-wrapper to access the REST API exposed by briar-headless. Briar GTK is already packaged according to DFSG, but it depends on briar-headless which can't be build with Debian packages due to Kotlin: https://code.briarproject.org/briar/briar-gtk/-/tree/main/debian I develop and use Briar GTK myself with support by other core developers of the Briar Project. I plan to maintain this project and its dependencies in Debian, but I'm always open to and appreciating any help by potential co-maintainers. Additionally, I'm looking for a sponsor. -BEGIN PGP SIGNATURE- iQJHBAEBCAAxFiEEVYvpBxymykTb9VdrlaDa99vHtUgFAl91lr8THG5pY29hbHRA cG9zdGVvLm9yZwAKCRCVoNr328e1SFEyEACKEFMbyopeGRqYq2EpFlDFbLqCOAXb 1GLHCBAz+mLt1ZiYCVdmyI/0lOr2f0wC+U+epd6hR6PNuUnNpQAZXfCxYcy7OhUt fJW3jdx5djhGS9l3ouWB4zaSD2oIJ1siZ040vl2HI166qA9UF1x4YT89xhknpOXY 3mHUZBCgpZx4iF8ysOQGmXyDFMGiUCTZ0UJOaOiR0iklduk4uvd0AceXbq9/UtXu wVFIIWd1fRqKE8kQlGt7Y0zSv2LmNnE17vEd3ez2BNNMlPtiPrXbaiEhjFpTo42u 9i2BRsAqJKPcubD2hKzV57fp25BCYcddywUmPIZv7KkV7cbRUe/fjDDJApWFQRnk i+uLVGKfPzuX4Z3LREPQuG7heYrHE+FM6vqgmPmJ28xtWW5he2fa5pnItD2kU4fh rOAO6OM9I7RcLN4tek9p2ERW+kDrO5FDO81S1h+7LdkhDlnLlY4A3vh7tYy69PRM CC8pae8beQY/LZMUKkjCjwHAakON/fqgl8gwfnEQJN2oURsMqm4DVDk2AvWtAVLA VwVurZddzVp5NEkg0HMX25rvtJPdqogHY5DEB1cYnOUEpc+NyZgDscOwsqXJ25M4 U1fUlaMMgDl9GtF1Gx85Kq8+d9Rbqx0dF63kxP6qDdJ5svlsZ8GNOMBEW6+AsdNz uc4dnZtR4SR08Q== =SUw6 -END PGP SIGNATURE-
Bug#968685: DNS Problem using Debian in IPv6 only networks
Package: mirrors Severity: important Tags: ipv6 Good evening, we were just trying to install & update a cluster of Debian VMs, when we were hit by the same bug that was reported by Jens Link in bug #961296 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961296). I am a bit puzzled on what to do here, as the machines are in an IPv6 only environment that does not have any access to the IPv4 world. We are encountering more and more IPv6 only networks as it is not feasible to use dual stack in these islands anymore, because they are routing wise far from any IPv4 networks. Is it possible for us to sponsor/help/provide IPv6 DNS servers (and/or maintenance of them) for the Debian project to fix this problem? We could probably setup a DNS mirror that does AXFR/IXFR from the Debian.org DNS servers and thus easily enable anyone else in IPv6 only servers. What do you think, is that a possibility to move forward? I think it would be almost zero effort from the Debian team, as it means only setting up an record for the DNS servers. I assume that Jens would also be in for maintenance, if you would like to have more than one party maintaining the DNS mirrors, as it scratches his itch, too. Best regards, Nico -- Modern, affordable, Swiss Virtual Machines. Visit www.datacenterlight.ch
Bug#961414:
FYI, I've added an Ubuntu PPA for it. Cheers, Nico [1] https://launchpad.net/~nschloe/+archive/ubuntu/waybar
Bug#964078: Error during setup, bad file location
Upstream dev here. The location is ``` share/paraview-5.8/plugins ``` now, that's already for 4.0.16. Cheers, Nico On Mon, Jul 20, 2020 at 9:03 AM Drew Parsons wrote: > > Package: meshio-tools > Followup-For: Bug #964078 > > Thanks for your report. Looks like the symlink might not be created > in time for the installation scripts, will have to look into it. > > It is a funny location. Upstream was using it so. We're working with > them to change it to a more appropriate location in /usr/lib or > /usr/share. > > Drew >
Bug#964370: dino-im-common: dino-im_0.1.0-5~bpo10+1 removes dino-im on upgrade
Thanks a lot for your quick reaction, Martin! I can confirm this bug to be fixed by now, as I just updated apt and were able to install dino-im from buster-backports. Thankfully, no chat history got lost.
Bug#964413: dino-im: Failing installation with buster-backports
Package: dino-im Version: 0.1.0-5~bpo10+1 Severity: important Dear Maintainer, while doing an full-upgrade with apt yesterday, my system uninstalled dino-im while keeping dino-im-common. Afer noting this, I tried to reinstall dino-im from buster-backports, but the installation is currently blocked because dino-im and dino-im-common depend on versions of each other that don't match. Here's the output on my machine: ``` $ sudo apt install -t buster-backports dino-im Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: dino-im : Depends: dino-im-common (= 0.1.0-5~bpo10+1) but it is not going to be installed E: Unable to correct problems, you have held broken packages. ``` Trying to install dino-im-common, too, gives me this error: ``` $ sudo apt install -t buster-backports dino-im dino-im-common Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: dino-im : Breaks: dino-im-common (< 0.1.0-5) but 0.1.0-5~bpo10+1 is to be installed dino-im-common : Breaks: dino-im (< 0.1.0-5) but 0.1.0-5~bpo10+1 is to be installed E: Unable to correct problems, you have held broken packages. ``` Upon looking into salsa.debian.org, I think it's related to this commit authored a week ago: https://salsa.debian.org/xmpp-team/dino-im/-/commit/fa14c00a84ab59912d8d8ce318a9380150f504b3 I marked this ticket as important, as I'm currently left without any dino-im client. Regards Nico -- System Information: Debian Release: 10.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-9-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#961201: ceph-common does not include /usr/bin/ceph-crush-location (but it should)
Package: ceph-common Version: 14.2.9-1~bpo10+1 Severity: grave Justification: renders package unusable Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Installing ceph * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? Starting ceph's osd via /etc/init.d/ceph fails, because the init script refers to ceph-crush-location, does not find it and exits 2. Note: the manpage for this binary is included, the binary itself is missing. This is tested on Devuan Beowulf, but any ceph operation also on systemd based distros that require ceph-crush-location will fail. *** End of the template - remove these template lines *** -- System Information: Distributor ID: Debian Description:Devuan GNU/Linux 3 (beowulf) Release:3 Codename: beowulf Architecture: x86_64 Kernel: Linux 4.9.0-4-amd64 (SMP w/16 CPU cores) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages ceph-common depends on: ii libaio1 0.3.112-3 ii libbabeltrace1 1.5.6-2+deb10u1 ii libblkid1 2.33.1-0.1+devuan1~beowulf2 ii libboost-coroutine1.67.01.67.0-13+deb10u1 ii libboost-program-options1.67.0 1.67.0-13+deb10u1 ii libboost-system1.67.0 1.67.0-13+deb10u1 ii libboost-thread1.67.0 1.67.0-13+deb10u1 ii libc6 2.28-10 ii libcap-ng0 0.7.9-2 ii libcephfs2 14.2.9-1~bpo10+1 ii libcurl3-gnutls 7.64.0-4+deb10u1 ii libeudev1 [libudev1]3.2.7-6 ii libexpat1 2.2.6-2+deb10u1 ii libgcc1 1:8.3.0-6 ii libgoogle-perftools42.7-1 ii libkeyutils11.6-6 ii libldap-2.4-2 2.4.47+dfsg-3+deb10u2 ii libleveldb1d1.20-2.1 ii liblz4-11.8.3-1 ii libncurses6 6.1+20181013-2+deb10u2 ii libnspr42:4.20-1 ii libnss3 2:3.42.1-1+deb10u2 ii liboath02.6.1-1.3 ii librabbitmq40.9.0-0.2 ii librados2 14.2.9-1~bpo10+1 ii libradosstriper114.2.9-1~bpo10+1 ii librbd1 14.2.9-1~bpo10+1 ii libsnappy1v51.1.7-1 ii libssl1.1 1.1.1d-0+deb10u3 ii libstdc++6 8.3.0-6 ii libtinfo6 6.1+20181013-2+deb10u2 ii libudev11:3.2.7+devuan1.1 ii python3 3.7.3-1 ii python3-cephfs 14.2.9-1~bpo10+1 ii python3-prettytable 0.7.2-4 ii python3-rados 14.2.9-1~bpo10+1 ii python3-rbd 14.2.9-1~bpo10+1 ii python3-requests2.21.0-1 ii zlib1g 1:1.2.11.dfsg-1 ceph-common recommends no packages. Versions of packages ceph-common suggests: ii ceph 14.2.9-1~bpo10+1 pn ceph-mds -- no debconf information -- Modern, affordable, Swiss Virtual Machines. Visit www.datacenterlight.ch
Bug#951864: pygalmesh fails it's own autopkg tests
The test tolerance has already been relaxed for Debian in the latest release. On Sat, Feb 22, 2020 at 2:48 PM Matthias Klose wrote: > > Package: src:pygalmesh > Version: 0.5.0-4 > Severity: serious > Tags: sid bullseye > > pygalmesh fails it's own autopkg tests: > > [...] > autopkgtest [18:10:53]: test command1: pytest-3 > autopkgtest [18:10:53]: test command1: [--- > = test session starts > == > platform linux -- Python 3.7.6, pytest-4.6.9, py-1.8.1, pluggy-0.13.0 > rootdir: /tmp/autopkgtest-lxc.c4_o_0a3/downtmp/build.k44/src > collected 26 items > > test/test_inr.py F [ > 3%] > test/test_periodic.py . [ > 7%] > test/test_surface_mesh.py . [ > 11%] > test/test_volume_from_surface.py . [ > 15%] > test/test_volume_mesh.py .. > [100%] > > === FAILURES > === > ___ test_inr > ___ > > def test_inr(): > this_dir = os.path.dirname(os.path.abspath(__file__)) > mesh = pygalmesh.generate_from_inr( > os.path.join(this_dir, "meshes", "skull_2.9.inr"), cell_size=5.0, > verbose=False > ) > > tol = 2.0e-3 > ref = [2.031053e02, 3.739508e01, 2.425594e02, 2.558910e01, > 2.300883e02, > 1.775010e00] > assert abs(max(mesh.points[:, 0]) - ref[0]) < tol * ref[0] > assert abs(min(mesh.points[:, 0]) - ref[1]) < tol * ref[1] > assert abs(max(mesh.points[:, 1]) - ref[2]) < tol * ref[2] > assert abs(min(mesh.points[:, 1]) - ref[3]) < tol * ref[3] > assert abs(max(mesh.points[:, 2]) - ref[4]) < tol * ref[4] > > assert abs(min(mesh.points[:, 2]) - ref[5]) < tol * ref[5] > E assert 0.0294994218444824 < (0.002 * 1.77501) > E+ where 0.0294994218444824 = abs((1.7455106 - 1.77501)) > E+where 1.7455106 = min(array([115.045494, 116.24661 , 122.3319 , > ..., 63.492596, 101.66734 ,\n 169.07079 ], dtype=float32)) > > test/test_inr.py:20: AssertionError > = 1 failed, 25 passed in 28.42 seconds > = >
Bug#950551: libgcc1: after libgcc1 upgrade, can't unlock luks partition at boot
I can confirm this bug. After doing an apt full-upgrade, I faced the same issue as OP. However, I was not able to fix it by downgrading packages, but instead used a similar approach to the way described in the btrfs bug #950556 [1]. After chrooting into the system, I changed the following file: $ diff /usr/share/initramfs-tools/hooks/cryptroot.backup /usr/share/initramfs-tools/hooks/cryptroot 416c416 < find -L "$LIBC_DIR" -maxdepth 1 -name 'libgcc_s.*' -type f | while read so; do --- > find -L "/lib" -maxdepth 1 -name 'libgcc_s.*' -type f | while read so; do After this, I updated initramfs with "update-initramfs -u -k all". Note: for this to work cleanly, you need to bind proc, dev etc. and you need to open your encrypted volume with the same name as described in your system's /etc/crypttab. The commands I used: sudo cryptsetup open /dev/sda5 sda5_crypt [...] sudo mount --bind /dev /mnt/dev [...] Cheers Nico [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950556
Bug#947058: pygalmesh: autopkgtest failure on arm64 (and ppc64el, s390x)
Just can just relax the relative tolerance to 2.0e-3 with a patch, I'll include in the next release. Cheers, Nico On Mon, Dec 30, 2019 at 3:27 PM Graham Inggs wrote: > > Control: reopen -1 > > Hi Drew > > The test gets a little further [1], and now fails at: > > ___ test_inr > ___ > > def test_inr(): > this_dir = os.path.dirname(os.path.abspath(__file__)) > mesh = pygalmesh.generate_from_inr( > os.path.join(this_dir, "meshes", "skull_2.9.inr"), > cell_size=5.0, verbose=False > ) > > tol = 2.0e-3 > ref = [2.031053e02, 3.739508e01, 2.425594e02, 2.558910e01, > 2.300883e02, 1.775010e00] > assert abs(max(mesh.points[:, 0]) - ref[0]) < tol * ref[0] > assert abs(min(mesh.points[:, 0]) - ref[1]) < tol * ref[1] > assert abs(max(mesh.points[:, 1]) - ref[2]) < tol * ref[2] > assert abs(min(mesh.points[:, 1]) - ref[3]) < tol * ref[3] > assert abs(max(mesh.points[:, 2]) - ref[4]) < tol * ref[4] > assert abs(min(mesh.points[:, 2]) - ref[5]) < tol * ref[5] > > vol = sum(helpers.compute_volumes(mesh.points, mesh.cells["tetra"])) > ref = 2.725335e06 > > assert abs(vol - ref) < ref * 1.0e-3 > E assert 4425.526206357405 < (2725335.0 * 0.001) > E+ where 4425.526206357405 = abs((2729760.5262063574 - 2725335.0)) > > test/test_inr.py:24: AssertionError > > Regards > Graham > > > [1] > https://ci.debian.net/data/autopkgtest/testing/arm64/p/pygalmesh/3810331/log.gz >
Bug#946590: python3-dolfin: cannot find -lmpi
Package: python3-dolfin
Version: 2019.1.0-7
Severity: normal
I don't know if this is a bug in the package or in my system. With the simplest
of python dolfin projects, I'm getting
```
--- Start compiler output
/usr/bin/ld: cannot find -lmpi
collect2: error: ld returned 1 exit status
--- End compiler output
Compilation failed! Sources, command, and errors have been written to:
/tmp/jitfailure-dolfin_expression_0ca911efb98de95f0dd6d82a8f353384
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/dolfin/jit/jit.py", line 167, in
compile_class
mpi_comm=mpi_comm)
File "/usr/lib/python3/dist-packages/dolfin/jit/jit.py", line 47, in mpi_jit
return local_jit(*args, **kwargs)
File "/usr/lib/python3/dist-packages/dolfin/jit/jit.py", line 103, in
dijitso_jit
return dijitso.jit(*args, **kwargs)
File "/usr/lib/python3/dist-packages/dijitso/jit.py", line 217, in jit
% err_info['fail_dir'], err_info)
dijitso.jit.DijitsoError: Dijitso JIT compilation failed, see '/tmp/jitfailure-
dolfin_expression_0ca911efb98de95f0dd6d82a8f353384' for details
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "l.py", line 37, in
u0 = Expression("a*sin(2.5*pi*x[1])*x[0]", a=0.2, degree=5)
File "/usr/lib/python3/dist-packages/dolfin/function/expression.py", line
400, in __init__
self._cpp_object = jit.compile_expression(cpp_code, params)
File "/usr/lib/python3/dist-packages/dolfin/function/jit.py", line 158, in
compile_expression
expression = compile_class(cpp_data, mpi_comm=mpi_comm)
File "/usr/lib/python3/dist-packages/dolfin/jit/jit.py", line 170, in
compile_class
raise RuntimeError("Unable to compile C++ code with dijitso")
RuntimeError: Unable to compile C++ code with dijitso
```
Is there a missing dependency? MPI seems to be there:
```
$ ls /usr/lib/x86_64-linux-gnu/libmpi.so.40*
/usr/lib/x86_64-linux-gnu/libmpi.so.40
/usr/lib/x86_64-linux-gnu/libmpi.so.40.20.2
```
-- System Information:
Debian Release: bullseye/sid
APT prefers focal
APT policy: (500, 'focal')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.3.0-19-generic (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages python3-dolfin depends on:
ii libc6 2.30-0ubuntu2
ii libdolfin-dev 2019.1.0-7
ii libdolfin2019.1 2019.1.0-7
ii libgcc1 1:9.2.1-21ubuntu1
ii libopenmpi3 4.0.2-4
ii libpetsc-real3.11 3.11.4+dfsg1-3build1
ii libstdc++6 9.2.1-21ubuntu1
ii python3 3.7.5-1ubuntu1
ii python3-dijitso 2019.1.0-3
ii python3-ffc 2019.1.0.post0-2
ii python3-numpy [python3-numpy-abi9] 1:1.17.4-3ubuntu2
ii python3-petsc4py3.11.0-4
ii python3-pkgconfig 1.5.1-3
ii python3-ply 3.11-3
ii python3-pybind112.3.0-2
ii python3-six 1.12.0-2build1
ii python3-slepc4py3.11.0-2build1
ii python3-sympy 1.4-1
ii python3-ufl 2019.1.0-2
python3-dolfin recommends no packages.
Versions of packages python3-dolfin suggests:
pn dolfin-doc
-- no debconf information
Bug#946234: [NMU] FTFBS with CGAL 5.0 (if cmake is absent)
It's fixed upstream, I released a new version and Drew is on it bumping the version in Debian. [1] [1] https://github.com/nschloe/pygalmesh/issues/56 On Fri, Dec 6, 2019 at 2:30 PM Joachim Reichel wrote: > > > Upstream 0.5.0 now builds against CGAL 5, so we only need an upload here. > > What do you mean with "only"? Is there already a package for the new upstream > ready to be uploaded? > > NMU uploaded to DELAYED/5-day. >
Bug#946234:
Upstream 0.5.0 now builds against CGAL 5, so we only need an upload here.
Bug#946189: python-numpy: blas -> blis
Package: python-numpy Version: 1.16.0 Severity: wishlist Since version 1.17.0, numpy's own blas detection order is mkl,blis,openblas,atlas,accelerate,blas The first one available on Debian is BLIS, so perhaps it's time to think about replacingthe BLAS dependency with BLIS. Cheers, Nico -- System Information: Debian Release: bullseye/sid APT prefers focal APT policy: (500, 'focal') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.3.0-19-generic (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python-numpy depends on: ii libblas3 [libblas.so.3] 3.9.0-1 ii libc62.30-0ubuntu2 ii liblapack3 [liblapack.so.3] 3.9.0-1 pn python-pkg-resources pn python2 pn python2.7 python-numpy recommends no packages. Versions of packages python-numpy suggests: ii gcc 4:9.2.1-3.1ubuntu1 ii gfortran 4:9.2.1-3.1ubuntu1 pn python-dev pn python-numpy-dbg pn python-numpy-doc pn python-pytest
Bug#944361: cgal: cgal 5.0 released
Alright, thanks for the update! (I didn't even know there was discussion about git atm.) On Fri, Nov 8, 2019, 5:40 PM Joachim Reichel wrote: > tag 944361 +pending > thanks > > Hi, > > I did not see any release announcement for CGAL 5.0 final yet, only for > Beta 2. > > Thanks for your offer to help, but I'm already working on updating the > packaging > and in contact with upstream to get the last problems fixed. Updating the > packaging requires non-trivial changes due to the header-only mode now > being the > default. Also, CGAL 5.0 will need to go to experimental first and needs a > transition slot. > > Yes, the package is not on salsa yet. I plan to do that eventually, but > wanted > to wait for the outcome of the currently ongoing discussion about git > packaging. > > Joachim >
Bug#944361: cgal: cgal 5.0 released
Package: libcgal-dev Version: 4.14-5 Severity: wishlist File: cgal CGAL 5.0 has been released this afternoon. I'd love to take a stab at it, but apparently the debian sources aren't on salsa yet. Any chance of moving them there? -- System Information: Debian Release: buster/sid APT prefers eoan-updates APT policy: (500, 'eoan-updates'), (500, 'eoan'), (100, 'eoan-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.3.0-19-generic (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_DIE, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libcgal-dev:amd64 depends on: ii libboost-dev 1.67.0.2 ii libboost-program-options-dev 1.67.0.2 ii libboost-system-dev 1.67.0.2 ii libboost-thread-dev 1.67.0.2 ii libcgal13 4.14-5 ii libgmp-dev [libgmp10-dev] 2:6.1.2+dfsg-4 ii libmpfr-dev 4.0.2-1 ii zlib1g-dev1:1.2.11.dfsg-1ubuntu3 libcgal-dev:amd64 recommends no packages. Versions of packages libcgal-dev:amd64 suggests: pn libmpfi-dev pn libntl-dev ii libtbb-dev 2019~U8-1 -- no debconf information
Bug#929453: lftp: hangs on getting directory contents at the end of mirror
Any idea what is causing this?
Bug#942675: meshio not compatible with python 3.8, installation fails
I've fixed this upstream in 3.2.2, upload coming in soon. On Sat, Oct 19, 2019 at 11:51 PM Matthias Klose wrote: > > Package: src:python-meshio > Version: 3.1.6-1 > Severity; serious > Tags: sid bullseye > > Trying to setup the package with pytho3-defaults installed from experimental, > the installation fails when trying to compile with Python 3.8: > > Setting up python3-meshio (3.1.6-1) ... > Traceback (most recent call last): >File "/usr/lib/python3.8/py_compile.py", line 144, in compile > code = loader.source_to_code(source_bytes, dfile or file, >File "", line 846, in source_to_code >File "", line 219, in > _call_with_frames_removed >File "/usr/lib/python3/dist-packages/meshio/_mdpa.py", line 338 > break > ^ > SyntaxError: 'break' outside loop >
Bug#939326: [gmsh] Could you please restore MED support?
Upstream recommends against using MPI [1], so we should probably stick to that. You can always use meshio [2] to convert between mesh formats. Cheers, Nico [1] https://gitlab.onelab.info/gmsh/gmsh/issues/502#note_6582 [2] https://github.com/nschloe/meshio On Tue, Sep 3, 2019 at 1:51 PM Christophe Trophime wrote: > > Package: gmsh > Version: 4.4.1+ds1-2 > Severity: normal > > MED support has been disabled in latest build. > This is very annoying. > > Could we consider restore it? > > I understand that it implies to rebuild with MPI support > since MED is compiled with MPI support. > > Best > C
Bug#933995: ITP: Mmg
Package: mmg Version: 5.4.1-201908051833-1eoan1 Severity: wishlist I intent to package Mmg [1], a (scientific) mesh generator and optimizer. It produces pretty high-quality 3D meshes, is open-source and well-supported by its GitHub upstream [2]. I'm working on this in a salsa repo [3]. Cheers, Nico [1] https://www.mmgtools.org [2] https://github.com/MmgTools/mmg [3] https://salsa.debian.org/science-team/mmg -- System Information: Debian Release: buster/sid APT prefers eoan APT policy: (500, 'eoan') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-8-generic (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mmg depends on: ii libc6 2.29-0ubuntu3 ii libmmg 5.4.1-201908051833-1eoan1 mmg recommends no packages. mmg suggests no packages. -- no debconf information
Bug#929453: lftp: hangs on getting directory contents at the end of mirror
Package: lftp
Version: 4.8.4-2
Severity: important
Hi Noël,
First thanks for maintaining lftp!
I've got two machines that run the same version of Debian and the same version
(and same configuration)
of lftp and one of them, lftp behaves very weird at the end of mirror command.
This manifests in the following output:
...
Transferring file `foo01'
Transferring file `foo02'
Transferring file `foo03'
New: 11 files, 0 symlinks
421696988 bytes transferred in 47 seconds (8.58 MiB/s)
Retrying mirror...
Getting directory contents (0) [Waiting for response...]
At that point, lftp is just stuck.
The exact mirror command that is executed is "mirror -R -c -v".
I have attached a minimal config for which this problem occurs and hope that
helps. Specifically, the timeout does not seem to kick in and I have no idea
why. There's also nothing obvious in the transfer log that hints to a problem.
I have also attached an strace from slightly before this happens, i.e. when
the files are stat'ed the last time. It seems lftp hangs up in some infinite
select loop without valuing the timeout or noticing that the server has closed
the connection. FWIW, this connection uses sftp.
Hope this helps. This has been bugging me for a while now and I've got no idea
what this is.
Thanks!
Nico
set ftp:passive-mode yes
set ftp:ssl-allow yes
set ftp:ssl-allow-anonymous no
set ftp:ssl-auth TLS
set ftp:ssl-data-use-keys yes
set ftp:ssl-force yes
set ftp:ssl-protect-data yes
set ftp:ssl-protect-fxp yes
set ftp:ssl-protect-list yes
set ssl:verify-certificate yes
set mirror:set-permissions off
set cache:enable false
set ftp:use-site-idle false
set ftp:use-mdtm false
set ftp:lang false
set ftp:use-hftp false
set ftp:use-feat false
set ftp:use-stat false
set ftp:stat-interval 30
set ftp:sync-mode true
set ftp:skey-allow false
set mirror:no-empty-dirs true
set net:timeout 10
set net:max-retries 2
set net:reconnect-interval-base 5
set net:reconnect-interval-multiplier 1
debug
lstat("/home/bla/foo01", {st_mode=S_IFREG|0644, st_size=21696051, ...}) = 0
lstat("/home/bla/foo02", {st_mode=S_IFREG|0644, st_size=5000, ...}) = 0
lstat("/home/bla/foo03", {st_mode=S_IFREG|0644, st_size=540, ...}) = 0
socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 7
fcntl(7, F_GETFL) = 0x2 (flags O_RDWR)
fcntl(7, F_SETFL, O_RDWR|O_NONBLOCK)= 0
fcntl(7, F_SETFD, FD_CLOEXEC) = 0
setsockopt(7, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
getsockname(4, {sa_family=AF_INET, sin_port=htons(54152),
sin_addr=inet_addr("X")}, [28->16]) = 0
bind(7, {sa_family=AF_INET, sin_port=htons(0),
sin_addr=inet_addr("XX")}, 16) = 0
getsockname(7, {sa_family=AF_INET, sin_port=htons(34865),
sin_addr=inet_addr("XX")}, [28->16]) = 0
sendmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\27\3\3\0
\0\0\0\0\0\0\0(\206\240\225\326h%YA\234h\307~g\206\310`\337\232\233"...,
iov_len=37}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 37
brk(0x560b2eb48000) = 0x560b2eb48000
close(5)= 0
select(5, [], [4], NULL, {tv_sec=0, tv_usec=13894}) = 1 (out [4], left
{tv_sec=0, tv_usec=13892})
recvfrom(4, 0x560b2eafdbb3, 5, 0, NULL, NULL) = -1 EAGAIN (Resource temporarily
unavailable)
select(5, [4], [], NULL, {tv_sec=0, tv_usec=13787}) = 0 (Timeout)
ioctl(0, TIOCGPGRP, [1772]) = 0
getpgrp() = 1772
ioctl(1, TIOCGWINSZ, {ws_row=48, ws_col=211, ws_xpixel=0, ws_ypixel=0}) = 0
write(1, "Getting directory contents (0) ["..., 56) = 56
write(1, "\r", 1) = 1
select(5, [4], [], NULL, {tv_sec=0, tv_usec=78028}) = 1 (in [4], left
{tv_sec=0, tv_usec=75885})
recvfrom(4, "\27\3\3\0,", 5, 0, NULL, NULL) = 5
recvfrom(4,
",r`\317\224\351\nl/\367\214\374+\273\26\2524.\234\230\245\363E\365h\275*5\26\10\10I"...,
44, 0, NULL, NULL) = 44
recvfrom(4, 0x560b2eafdbb3, 5, 0, NULL, NULL) = -1 EAGAIN (Resource temporarily
unavailable)
sendmsg(4, {msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="\27\3\3\0\36\0\0\0\0\0\0\0)AX\200\347\262\335s\221\246V\221|\320\336z:9\271v"...,
iov_len=35}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 35
select(5, [], [4], NULL, {tv_sec=0, tv_usec=74351}) = 1 (out [4], left
{tv_sec=0, tv_usec=74349})
recvfrom(4, 0x560b2eafdbb3, 5, 0, NULL, NULL) = -1 EAGAIN (Resource temporarily
unavailable)
select(5, [4], [], NULL, {tv_sec=0, tv_usec=74195}) = 1 (in [4], left
{tv_sec=0, tv_usec=57018})
recvfrom(4, "\27\3\3\0J", 5, 0, NULL, NULL) = 5
recvfrom(4,
",r`\317\224\351\nm\302\t\r>si\356$\346DS\222\362\362\327\201\307\274D[\254S\361\264"...,
74, 0, NULL, NULL) = 74
recvfrom(4, 0x560b2eafdbb3, 5, 0, NULL, NULL) = -1 EAGAIN (Resource temporarily
unavailable)
getpeername(4, {sa_family=AF_INET, sin_port=htons(43486),
sin_addr=inet_addr("Y&q
Bug#929390: VTK 8
Package: vtk7 Version: VTK 8 is now out for about two years (June 2017). Perhaps we should start supporting it?
Bug#928140: pygalmesh: FTBFS on 32-bit architectures: virtual memory exhausted
cf. https://stackoverflow.com/questions/55801777/set-compile-flags-when-installing-python-c-project On Fri, May 3, 2019 at 10:29 AM Drew Parsons wrote: > > On 2019-05-03 16:24, Nico Schlömer wrote: > >> Do you know how to control it? > > > > I'd been looking at this once, to no avail. Locally I just use > > CC=clang++ now. > > > > It's very odd that they make it difficult to deal with. > > The offending definition looks like OPT in > /usr/lib/python3.7/config-3.7m-x86_64-linux-gnu/Makefile > > But despite the "helpful" advices on stackoverflow, >OPT="" /usr/bin/python3 setup.py build > fails to override it. > > Drew >
Bug#928140: pygalmesh: FTBFS on 32-bit architectures: virtual memory exhausted
> Do you know how to control it? I'd been looking at this once, to no avail. Locally I just use CC=clang++ now. On Fri, May 3, 2019 at 10:11 AM Drew Parsons wrote: > > On 2019-04-29 15:49, Nico Schlömer wrote: > >> No easy way around it. > > > > Indeed. > > > >> Building with -g -O1 (or -O2 without -g) helps mshr, we can test if it > >> helps pygalmesh too. > > > > Removing `-g` almost certainly improves things. Using clang++ instead > > of c++ also helps. > > > I can remove Debian's -g flag easily enough (CFLAGS from > dpkg-buildflags). > > But you can see in the log that -g is invoked twice in the gcc call. > > The first -g comes from the default compiler flags invoked by setup.py > when compiling an extension. I can't see how to control or remove this > one. The distutils.Extension documentation is sparse. Do you know how > to control it? > > Drew
Bug#928140: pygalmesh: FTBFS on 32-bit architectures: virtual memory exhausted
> No easy way around it. Indeed. > Building with -g -O1 (or -O2 without -g) helps mshr, we can test if it helps > pygalmesh too. Removing `-g` almost certainly improves things. Using clang++ instead of c++ also helps. On Mon, Apr 29, 2019 at 9:06 AM Drew Parsons wrote: > > Source: pygalmesh > Followup-For: Bug #928140 > > Not a regression as such: 0.2.6-1 also exhausts memory on i386 > sometimes (not always), cf. > https://tests.reproducible-builds.org/debian/logs/unstable/i386/pygalmesh_0.2.6-1.build2.log.gz > > This is a general problem with meshing libraries. mshr has a > similar problem on i386, > https://bitbucket.org/fenics-project/mshr/issues/89/ > > I spoke with upstream about it, he said the reason will be cgal's > heavy use of c++ templates. No easy way around it. > > Building with -g -O1 (or -O2 without -g) helps mshr, we can test if it > helps pygalmesh too. > > Drew >
Bug#927808: gmsh: FTBFS in buster (c++: error: unrecognized command line option '-Wint-to-void-pointer-cast')
This could all be fixed in master (where we have Gmsh 4.3.0). Should
perhaps be uploaded soon.
On Wed, Apr 24, 2019 at 8:33 PM Juhani Numminen
wrote:
>
> Control: retitle -1 gmsh: FTBFS in buster
> ("/usr/include/occt/Standard_Version.hxx" cannot be read)
>
>
> Hi,
>
> I believe the relevant error message is actually this:
>
> CMake Error at CMakeLists.txt:1161 (file):
> file STRINGS file "/usr/include/occt/Standard_Version.hxx" cannot be read.
>
> It seems that /usr/include/occt was changed to /usr/include/opencascade.
> https://salsa.debian.org/science-team/opencascade/commit/05357f551748a6842bf2788e2bbc604daa0dfc16
>
> Kurt, will you be able to make gmsh 4.1.3+ds1-1 buildable in ‘testing’?
>
> Regards,
> Juhani
>
Bug#923921: systemd: Updating systemd breaks Dovecot (and possibly other services)
Dear Mika, dear Michael, thank you for your answers and apologies for answering them so late. Am 07.03.2019 um 09:15 schrieb Michael Prokop: * Nico Haase [Thu Mar 07, 2019 at 08:33:57AM +0100]: Package: systemd Version: 241-1~bpo9+1 Severity: normal Dear Maintainer, this morning, apticron reminded me (once more) to upgrade some packages from stretch-backports. These included dovecot-core and systemd (and others). After having installed all of them, Dovecot refused to start. The following lines were reported in daemon.log: Mar 7 07:35:25 host systemd[1]: Started Dovecot IMAP/POP3 email server. Mar 7 07:35:25 host systemd[30913]: dovecot.service: Failed to set up mount namespacing: Permission denied Mar 7 07:35:25 host systemd[30913]: dovecot.service: Failed at step NAMESPACE spawning /usr/sbin/dovecot: Permission denied Mar 7 07:35:25 host systemd[1]: dovecot.service: Main process exited, code=exited, status=226/NAMESPACE Mar 7 07:35:25 host systemd[1]: dovecot.service: Failed with result 'exit-code'. I have no clue how to solve this, as there a no canonical sources for that messages. The only obvious thing was to downgrade systemd to 232-25+deb9u9 again, which let me start Dovecot again. If there is anything I can do to help you spot the error, please ask. I'm not that experienced with systemd, but I'd be able to run upgrades or other commands that could provide more information. So you're using a (quite old) Proxmox kernel: Kernel: Linux 4.4.134-1-pve (SMP w/12 CPU cores) Any reason why you don't use a more recent version like 4.15.18-11-pve? Yep, you've found the one thing I cannot change: my system is running virtualized, and my provider is currently not able to upgrade the kernel. Even if I know that such checks can get pretty expansive, would it be possible to introduce a clear warning if such incompatibilities arise? If you know exactly that there might be a feature missing from a more current kernel, could you give a clear hint or even reject upgrading the package? Regards Nico
Bug#915187: netfilter-persistent: Updating netfilter-persistent results in error
Hi Gustavo,
I'm sorry, but I still don't get it completely.
Am 16.12.2018 um 02:31 schrieb gustavo panizzo:
Is not a parsing problem, the CHAINs do not exists.
You need to check your setup. Check where the ip6*tables* symlinks
points to and make it consistent.
ip6tables-save points to /usr/sbin/ip6tables-nft-save, the version
string is ip6tables-save v1.8.2 (nf_tables). ip6tables-restore points to
/usr/sbin/ip6tables-nft-restore, which is of the same version v1.8.2.
I've never touched these symlinks on my own.
Also remove the legacy rules before applying new rules.
if ip{,6}tables-save and ip{,6}tables-restore dont work in your system,
netfilter-persistent won't work either (is just a wrapper around them to
start the firewall at boot time)
Yeah, and that is still my point of asking here: how can it be possible
that dumping the rules and importing with tools from the same package
with the same version throws an error? Shouldn't the process to write
the rules generate a file that is sound and can be restored?
Is it possible that there are incompatibilities with other parts? For
example, I'm running the kernel version 4.4.134.
I'm sorry to keep asking questions rather than providing a solution on
my own, but I'm not that experienced with iptables. I've seen it
throwing an error during an update and this looks like a bug to me. I'd
be very happy if you could guide me to the neccessary steps of providing
more information to inspect this.
Regards
Nico
Bug#915187: netfilter-persistent: Updating netfilter-persistent results in error
Hi there, I wanted to check if there are some news. Through removing the saved rules files, the update has succeeded. But still, I think that this is not solved: after the update went through, I've tried to dump the rules through the following command: ip6tables-save > /etc/iptables/rules.v6 This created the following dump: # Generated by xtables-save v1.8.2 on Mon Dec 10 18:40:39 2018 *filter :OUTPUT ACCEPT [64:15232] :FORWARD ACCEPT [0:0] :INPUT ACCEPT [64:15232] COMMIT # Completed on Mon Dec 10 18:40:39 2018 Afterwards, I tried to restore the rules that I've just dumped, and that threw the same message as before: ip6tables-restore v1.8.2 (nf_tables): line 3: CHAIN_UPDATE failed (No such file or directory): chain OUTPUT line 4: CHAIN_UPDATE failed (No such file or directory): chain FORWARD line 5: CHAIN_UPDATE failed (No such file or directory): chain INPUT I understand that there might be some things that could work in another way due to a legacy version, but still: how could saving the rules with the current version result in a file that the current version cannot parse? Regards Nico
Bug#915187: netfilter-persistent: Updating netfilter-persistent results in error
Hi Gustavo, thanks for your answer so far! Am 02.12.2018 um 04:45 schrieb gustavo panizzo: Hello On Sat, Dec 01, 2018 at 04:27:19PM +0100, Nico Haase wrote: Nov 29 06:42:10 host netfilter-persistent[24163]: run-parts: executing /usr/share/netfilter-persistent/plugins.d/25-ip6tables start Nov 29 06:42:10 host netfilter-persistent[24163]: ip6tables-restore v1.8.2 (nf_tables): Nov 29 06:42:10 host netfilter-persistent[24163]: line 3: CHAIN_UPDATE failed (No such file or directory): chain PREROUTING Nov 29 06:42:10 host netfilter-persistent[24163]: line 4: CHAIN_UPDATE failed (No such file or directory): chain INPUT Nov 29 06:42:10 host netfilter-persistent[24163]: line 5: CHAIN_UPDATE failed (No such file or directory): chain OUTPUT Nov 29 06:42:10 host netfilter-persistent[24163]: line 6: CHAIN_UPDATE failed (No such file or directory): chain POSTROUTING Nov 29 06:42:10 host netfilter-persistent[24163]: run-parts: /usr/share/netfilter-persistent/plugins.d/25-ip6tables exited with return code 4 ip6tables-restore fails to load your ip6 rules, /etc/iptables/rules.v6 It looks to me looking at the error that you are mixing iptables and nftables, in iptables world PREROUTING/INPUT/OUTPUT/POSTROUTING tables *always* exist show me the output of # systemctl status nftables That displays: Unit nftables.service could not be found. # nft list tables That displays: command not found # ip6tables-restore < /etc/iptables/rules.v6 As you already mentioned, this prints the same message as above. And that is the current content of rules.v6, which I've never edited manually: # Generated by ip6tables-save v1.6.2 on Wed Oct 24 06:16:46 2018 *nat :PREROUTING ACCEPT [0:0] :INPUT ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] COMMIT # Completed on Wed Oct 24 06:16:46 2018 # Generated by ip6tables-save v1.6.2 on Wed Oct 24 06:16:46 2018 *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] COMMIT # Completed on Wed Oct 24 06:16:46 2018 Nov 29 06:42:10 host systemd[1]: netfilter-persistent.service: Main process exited, code=exited, status=1/FAILURE Nov 29 06:42:10 host systemd[1]: netfilter-persistent.service: Failed with result 'exit-code'. Nov 29 06:42:10 host systemd[1]: Failed to start netfilter persistent configuration. What can I do to make this work? Is it a configuration problem on my server, or a bug in the package? I think you are mixing nftables and iptables-legacy, please read /usr/share/doc/iptables/README.Debian That might be the case, but I don't have a clue why only the latest update throws such an error. Up to this version, there were no errors or warnings mentioned; and if there is a larger incompatibility between installed packages and new updates, I think there should be a more clear message logged. As these rules were dumped there automatically and the file was not edited by hand, what can I do to make this work again? Regards Nico
Bug#915187: netfilter-persistent: Updating netfilter-persistent results in error
Package: netfilter-persistent Version: 1.0.10 Severity: normal Dear Maintainer, unattended-upgrades performed an update from 1.0.9 to 1.0.10 some days ago. Since then, this upgrade is triggered on each run, as it won't finish. The following error is given: Job for netfilter-persistent.service failed because the control process exited with error code. See "systemctl status netfilter-persistent.service" and "journalctl -xe" for details. invoke-rc.d: initscript netfilter-persistent, action "restart" failed. ● netfilter-persistent.service - netfilter persistent configuration Loaded: loaded (/lib/systemd/system/netfilter-persistent.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Thu 2018-11-29 06:42:10 CET; 5ms ago Process: 24163 ExecStart=/usr/sbin/netfilter-persistent start (code=exited, status=1/FAILURE) Main PID: 24163 (code=exited, status=1/FAILURE) Nov 29 06:42:10 host netfilter-persistent[24163]: run-parts: executing /usr/share/netfilter-persistent/plugins.d/25-ip6tables start Nov 29 06:42:10 host netfilter-persistent[24163]: ip6tables-restore v1.8.2 (nf_tables): Nov 29 06:42:10 host netfilter-persistent[24163]: line 3: CHAIN_UPDATE failed (No such file or directory): chain PREROUTING Nov 29 06:42:10 host netfilter-persistent[24163]: line 4: CHAIN_UPDATE failed (No such file or directory): chain INPUT Nov 29 06:42:10 host netfilter-persistent[24163]: line 5: CHAIN_UPDATE failed (No such file or directory): chain OUTPUT Nov 29 06:42:10 host netfilter-persistent[24163]: line 6: CHAIN_UPDATE failed (No such file or directory): chain POSTROUTING Nov 29 06:42:10 host netfilter-persistent[24163]: run-parts: /usr/share/netfilter-persistent/plugins.d/25-ip6tables exited with return code 4 Nov 29 06:42:10 host systemd[1]: netfilter-persistent.service: Main process exited, code=exited, status=1/FAILURE Nov 29 06:42:10 host systemd[1]: netfilter-persistent.service: Failed with result 'exit-code'. Nov 29 06:42:10 host systemd[1]: Failed to start netfilter persistent configuration. What can I do to make this work? Is it a configuration problem on my server, or a bug in the package? Regards Nico -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (700, 'testing'), (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 4.4.134-1-pve (SMP w/12 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages netfilter-persistent depends on: ii lsb-base 9.20170808 netfilter-persistent recommends no packages. Versions of packages netfilter-persistent suggests: iu iptables-persistent 1.0.10 -- no debconf information
Bug#907844:
As a side note: Can we include the optional dependency on PETSc for the new Gmsh? I'm getting mesh generation errors without (see https://github.com/nschloe/pygmsh/pull/214). Cheers, Nico On Tue, 4 Sep 2018 07:29:46 +0200 =?UTF-8?Q?Nico_Schl=C3=B6mer?= < nico.schloe...@gmail.com> wrote: > Where can I find this work. (Need Gmsh 4 for another project.) > > Cheers, > Nico
Bug#907920: use optional PETSc dependency
Package: hello Version: 3.0.6+dfsg1-3 When building some meshes, I'm getting ``` Error : Petsc is required (we do need complex in discreteFace::crossField()) ``` followed a double free or corruption. See, e.g., < https://github.com/nschloe/pygmsh/pull/214>. Please include the dependency on PETSc. Cheers, Nico
Bug#907844:
Where can I find this work. (Need Gmsh 4 for another project.) Cheers, Nico
Bug#902225: RFS: ii/1.8-1
Hi itd, the license change for debian patches is fine! Cheers, Nico -- Nico Golde - XMPP: n...@jabber.ccc.de - GPG: 0xA0A0 signature.asc Description: PGP signature
Bug#852159: mktorrent: upstream changed maintainer, actual version missing new interesting features
Hi, * Paride Legovini [2018-08-01 22:31]: > Nico Golde wrote on 29/07/2018: > > * Paride Legovini [2018-07-29 19:52]: [...] > The Debian packaging is Copyright (C) 2009, Nico Golde > and is licensed under the GPL, see `/usr/share/common-licenses/GPL-2'. > > Does this mean GPL2 or GPL2+ (GPL2 or any later version)? (Upstream is > licensed as GPL2+, so I think it would be nice to use the same licensing > terms for homogeneity, but it's up to you.) Feel free to change any aspect as you like, including this one. Cheers, Nico -- Nico Golde - XMPP: n...@jabber.ccc.de - GPG: 0xA0A0
Bug#852159: mktorrent: upstream changed maintainer, actual version missing new interesting features
Hi, I just realized I haven't responded to this bug ever. I'm very short on time at the moment and in fact will retire my Debian account soon. If you or anyone is interested in hijacking this package, please go ahead! Kind regards, Nico -- Nico Golde - XMPP: n...@jabber.ccc.de - GPG: 0xA0A0 signature.asc Description: PGP signature
Bug#895634: please package lftp 4.8.3
Source:lftp Severity:wishlist Hey Noël, Could you update lftp to 4.8.3? This brings some useful features such as the parallel option for mget. Thanks! Nico -- Nico Golde - XMPP: n...@jabber.ccc.de - GPG: 0xA0A0 signature.asc Description: PGP signature
Bug#895419: Acknowledgement (python3-dolfin: JIT compilation fails as python3-instant tries to includes petsc4py from python2)
I've had that issue in the past, but never bothered looking into it. Me, I'll hold out for 2018.1 (which kills Python 2 support) to fix these kind of bugs. Cheers, Nico On Fri, Apr 13, 2018 at 4:54 PM Fabrice Silva <si...@lma.cnrs-mrs.fr> wrote: > Additional information from Johannes Ring (fenics dev) on > https://groups.google.com/d/topic/fenics-support/mfJdWYwq0-w/discussion > >The problem is that the path to petsc4py is included in >/usr/share/dolfin/cmake/DOLFINConfig.cmake and >/usr/share/dolfin/cmake/DOLFINTargets.cmake, while it should only >have been included in /usr/share/dolfin/cmake/DOLFINPython27.cmake >and /usr/share/dolfin/cmake/DOLFINPython36.cmake. > >The quick fix would be to either install python-petsc4py (the >petsc4py include files are the same for python2 and python3) or to >remove the path to petsc4py from DOLFINConfig.cmake and >DOLFINTargets.cmake. > > These recommendations solve the trouble (even if other errors are still > raised in the overly-simplified script). > >
Bug#893178: libinput upgrade fixed this bug
I've been running my desktop with the libinput version 1.10.3-2 and touchpad enabled for hours now, so I consider this bug resolved.
Bug#893178: Disabling touchpad works as a mitigation strategy
On my W520 ThinkPad I've disabled my touchpad using Gnome Settings, and so far this bug hasn't occured. Although this doesn't resolve this underlying issue, it makes the desktop usable again. Considering that this bug is touchpad related, using an external mouse and disabling the touchpad could work for anyone. In 2 days time the new version of libinput should land in Buster, so then I can verify this issue is resolved.
Bug#893178: Seems to be fixed upstream
Looking for the assertion code, a similar bug pops up, with an offset of 2 lines in the source file: https://bugs.freedesktop.org/show_bug.cgi?id=105275 which duplicates: https://bugs.freedesktop.org/show_bug.cgi?id=105258 That bug is fixed in libinput 1.10.3. I'm currently on 1.10.2-1 so this should improve in the near future. I've disabled the touchpad altogether for now, hoping will prevent the crashes.
Bug#893178: Wayland attempt
I just tried switching to a Wayland session (verified using loginctl show-session -p Type) but that didn't change the restarting behavior.
Bug#893178: gdm3 crashes: tp_tap_handle_state: Assertion `tp->tap.nfingers_down >= 1' failed.
Package: gdm3 Version: 3.26.2.1-3 Severity: important Dear Maintainer, This occurs seemingly randomly at intervals of anywhere between 2 and 30 minutes. The desktop isn't running anything fancy. An open terminal window and the ReportBug application are enough to make it crash. I get the impression that me using the trackpad is related, as I'm certain that was the case for the last few crashes. Every single time I got the same stracktrace in /usr/lib/gdm3/gdm-x-session (~/.local/share/xorg/Xorg.0.log.old) so I'm certain this is related. After the crash other processes are terminated and the desktop is reloaded. The stacktrace as seen in journalctl: mrt 17 08:16:34 t400 /usr/lib/gdm3/gdm-x-session[29917]: Xorg: ../src/evdev-mt- touchpad-tap.c:1028: tp_tap_handle_state: Assertion `tp->tap.nfingers_down >= 1' failed. mrt 17 08:16:34 t400 /usr/lib/gdm3/gdm-x-session[29917]: (EE) mrt 17 08:16:34 t400 /usr/lib/gdm3/gdm-x-session[29917]: (EE) Backtrace: mrt 17 08:16:34 t400 /usr/lib/gdm3/gdm-x-session[29917]: (EE) 0: /usr/lib/xorg/Xorg (xorg_backtrace+0x4d) [0x55c67d570e3d] mrt 17 08:16:34 t400 /usr/lib/gdm3/gdm-x-session[29917]: (EE) 1: /usr/lib/xorg/Xorg (0x55c67d3b9000+0x1bbbd9) [0x55c67d574bd9] mrt 17 08:16:34 t400 /usr/lib/gdm3/gdm-x-session[29917]: (EE) 2: /lib/x86_64-linux-gnu/libpthread.so.0 (0x7ff9164a5000+0x11f50) [0x7ff9164b6f50] mrt 17 08:16:34 t400 /usr/lib/gdm3/gdm-x-session[29917]: (EE) 3: /lib/x86_64-linux-gnu/libc.so.6 (gsignal+0x10b) [0x7ff91611fe7b] mrt 17 08:16:34 t400 /usr/lib/gdm3/gdm-x-session[29917]: (EE) 4: /lib/x86_64-linux-gnu/libc.so.6 (abort+0x151) [0x7ff916121231] mrt 17 08:16:34 t400 /usr/lib/gdm3/gdm-x-session[29917]: (EE) 5: /lib/x86_64-linux-gnu/libc.so.6 (0x7ff9160eb000+0x2d9da) [0x7ff9161189da] mrt 17 08:16:34 t400 /usr/lib/gdm3/gdm-x-session[29917]: (EE) 6: /lib/x86_64-linux-gnu/libc.so.6 (0x7ff9160eb000+0x2da52) [0x7ff916118a52] mrt 17 08:16:34 t400 /usr/lib/gdm3/gdm-x-session[29917]: (EE) 7: /usr/lib/x86_64-linux-gnu/libinput.so.10 (0x7ff912ed8000+0x1e693) [0x7ff912ef6693] mrt 17 08:16:34 t400 /usr/lib/gdm3/gdm-x-session[29917]: (EE) 8: /usr/lib/x86_64-linux-gnu/libinput.so.10 (0x7ff912ed8000+0x19857) [0x7ff912ef1857] mrt 17 08:16:34 t400 /usr/lib/gdm3/gdm-x-session[29917]: (EE) 9: /usr/lib/x86_64-linux-gnu/libinput.so.10 (0x7ff912ed8000+0x1ba20) [0x7ff912ef3a20] mrt 17 08:16:34 t400 /usr/lib/gdm3/gdm-x-session[29917]: (EE) 10: /usr/lib/x86_64-linux-gnu/libinput.so.10 (0x7ff912ed8000+0xfe51) [0x7ff912ee7e51] mrt 17 08:16:34 t400 /usr/lib/gdm3/gdm-x-session[29917]: (EE) 11: /usr/lib/x86_64-linux-gnu/libinput.so.10 (libinput_dispatch+0x5f) [0x7ff912ee3e7f] mrt 17 08:16:34 t400 /usr/lib/gdm3/gdm-x-session[29917]: (EE) 12: /usr/lib/xorg/modules/input/libinput_drv.so (0x7ff913112000+0x8988) [0x7ff91311a988] mrt 17 08:16:34 t400 /usr/lib/gdm3/gdm-x-session[29917]: (EE) 13: /usr/lib/xorg/Xorg (0x55c67d3b9000+0x1b9fb3) [0x55c67d572fb3] mrt 17 08:16:34 t400 /usr/lib/gdm3/gdm-x-session[29917]: (EE) 14: /usr/lib/xorg/Xorg (0x55c67d3b9000+0x1bc6b1) [0x55c67d5756b1] mrt 17 08:16:34 t400 /usr/lib/gdm3/gdm-x-session[29917]: (EE) 15: /usr/lib/xorg/Xorg (0x55c67d3b9000+0x1b9dfe) [0x55c67d572dfe] mrt 17 08:16:34 t400 /usr/lib/gdm3/gdm-x-session[29917]: (EE) 16: /lib/x86_64-linux-gnu/libpthread.so.0 (0x7ff9164a5000+0x75aa) [0x7ff9164ac5aa] mrt 17 08:16:34 t400 /usr/lib/gdm3/gdm-x-session[29917]: (EE) 17: /lib/x86_64-linux-gnu/libc.so.6 (clone+0x3f) [0x7ff9161e1cbf] mrt 17 08:16:34 t400 /usr/lib/gdm3/gdm-x-session[29917]: (EE) mrt 17 08:16:34 t400 /usr/lib/gdm3/gdm-x-session[29917]: Fatal server error: mrt 17 08:16:34 t400 /usr/lib/gdm3/gdm-x-session[29917]: (EE) Caught signal 6 (Aborted). Server aborting mrt 17 08:16:34 t400 /usr/lib/gdm3/gdm-x-session[29917]: (EE) mrt 17 08:16:34 t400 /usr/lib/gdm3/gdm-x-session[29917]: Please consult the The X.Org Foundation support mrt 17 08:16:34 t400 /usr/lib/gdm3/gdm-x-session[29917]: at http://wiki.x.org mrt 17 08:16:34 t400 /usr/lib/gdm3/gdm-x-session[29917]: for help. mrt 17 08:16:34 t400 /usr/lib/gdm3/gdm-x-session[29917]: (EE) Please also check the log file at "/home/nico/.local/share/xorg/Xorg.0.log" for additional information. mrt 17 08:16:34 t400 /usr/lib/gdm3/gdm-x-session[29917]: (EE) mrt 17 08:16:34 t400 /usr/lib/gdm3/gdm-x-session[29917]: (II) AIGLX: Suspending AIGLX clients for VT switch mrt 17 08:16:34 t400 /usr/lib/gdm3/gdm-x-session[29917]: (EE) Server terminated with error (1). Closing log file. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.14.0-3-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gdm3 depends on: ii accountsservice 0.6.
Bug#890995: ii: new upstream version
Hi, * itd <i...@firemail.cc> [2018-02-21 13:48]: > thanks for maintaining ii. > > As of 2018-02-04 ii version 1.8 is available. Please consider packaging it. > Feel > free to use the patch attached as you think fit to do so (no attribution > required). [1] Do you want to hijack the package? You are more than welcome to do so! Kind regards, Nico -- Nico Golde - XMPP: n...@jabber.ccc.de - GPG: 0xA0A0 signature.asc Description: PGP signature
Bug#890364:
I depend on this as well. As a stop-gap measure, I've set of a PPA [1]. Cheers, Nico [1] https://launchpad.net/~nschloe/+archive/ubuntu/pybind11-backports/
Bug#712485:
Perhaps it's useful to report which are the offending lines in the build log. For Trilinos [1], for example, a hidden flags are reported, but I have no idea why. Can you help me out? Cheers, Nico [1] https://buildd.debian.org/status/fetch.php?pkg=trilinos=amd64=12.12.1-5=1517856320=0
Bug#889682: openimageio: Provide Python 3 interface
Package: libopenimageio-dev Version: 1.6.17~dfsg0-1ubuntu5 Severity: normal File: openimageio OpenImageIO supports Python 3 for a while now. Please provide the respective package in Debian. -- System Information: Debian Release: stretch/sid APT prefers artful-updates APT policy: (500, 'artful-updates'), (500, 'artful-security'), (500, 'artful'), (100, 'artful-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.13.0-32-generic (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libopenimageio-dev depends on: ii libopenimageio-doc 1.6.17~dfsg0-1ubuntu5 ii libopenimageio1.6 1.6.17~dfsg0-1ubuntu5 libopenimageio-dev recommends no packages. libopenimageio-dev suggests no packages. -- no debconf information
Bug#881881: libtrilinos-kokkos-kernels-dev: fails to upgrade from 'testing' - trying to overwrite /usr/include/trilinos/Kokkos_ArithTraits.hpp
Ah, yes, these files seem to have moved from Tpetra to Kokkos. These two upstream packages are tightly related, so no surprise there. I'll see if I can get this fixed. Cheers, Nico On Thu, Nov 16, 2017 at 2:15 AM Andreas Beckmann <a...@debian.org> wrote: > Package: libtrilinos-kokkos-kernels-dev > Version: 12.12.1-1 > Severity: serious > User: debian...@lists.debian.org > Usertags: piuparts > > Hi, > > during a test with piuparts I noticed your package fails to upgrade from > 'testing'. > It installed fine in 'testing', then the upgrade to 'sid' fails > because it tries to overwrite other packages files without declaring a > Breaks+Replaces relation. > > See policy 7.6 at > https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces > > From the attached log (scroll to the bottom...): > > Selecting previously unselected package > libtrilinos-kokkos-kernels-dev:amd64. > Preparing to unpack > .../libtrilinos-kokkos-kernels-dev_12.12.1-1_amd64.deb ... > Unpacking libtrilinos-kokkos-kernels-dev:amd64 (12.12.1-1) ... > dpkg: error processing archive > /var/cache/apt/archives/libtrilinos-kokkos-kernels-dev_12.12.1-1_amd64.deb > (--unpack): >trying to overwrite '/usr/include/trilinos/Kokkos_ArithTraits.hpp', > which is also in package libtrilinos-tpetra-dev 12.10.1-4+b1 > dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) > Errors were encountered while processing: > > /var/cache/apt/archives/libtrilinos-kokkos-kernels-dev_12.12.1-1_amd64.deb > > > cheers, > > Andreas >
Bug#881873: trilinos: FTBFS on sparc64: Bus errors in 11 tests
Chances are slim for to ever be resolved. Upstream only supports amd64, and PRs to fix building for other architectures are rejected. (See, e.g., [1].) I'd say we'll have to live with trilinos not running on sparc64. Cheers, Nico [1] https://github.com/kokkos/kokkos/pull/576 On Thu, Nov 16, 2017 at 1:21 AM Aaron M. Ucko <u...@debian.org> wrote: > Source: trilinos > Version: 12.10.1-4+b1 > Severity: important > Tags: upstream > Justification: fails to build from source (but built successfully in the > past) > User: debian-sp...@lists.debian.org > Usertags: sparc64 > > Builds of trilinos for sparc64 (admittedly not a release architecture) > have been failing lately with bus errors (indicating attempts to use > underaligned pointers, about which sparc64 is notoriously strict), per > the below excerpts from > > https://buildd.debian.org/status/fetch.php?pkg=trilinos=sparc64=12.12.1-1=1510746436=0 > . > > Could you please take a look? > > Thanks! > > > > [...] > 521/871 Test #521: EpetraExt_Transpose_test_LL_MPI_4 > ..***Failed2.31 sec > Epetra::MpiComm::Processor 0 of 4 total processors. > EpetraExt in Trilinos 12.12.1 > > Epetra::MpiComm::Processor 1 of 4 total processors. > Epetra::MpiComm::Processor 2 of 4 total processors. > Epetra::MpiComm::Processor 3 of 4 total processors. > [landau:24458] *** Process received signal *** > [landau:24458] Signal: Bus error (10) > [landau:24458] Signal code: Invalid address alignment (1) > [landau:24458] Failing at address: 0x15ef4bc > [landau:24459] *** Process received signal *** > [landau:24459] Signal: Bus error (10) > [landau:24459] Signal code: Invalid address alignment (1) > [landau:24459] Failing at address: 0x15eca7c > [landau:24458] *** End of error message *** > [landau:24459] *** End of error message *** > [landau:24456] *** Process received signal *** > [landau:24456] Signal: Bus error (10) > [landau:24456] Signal code: Invalid address alignment (1) > [landau:24456] Failing at address: 0x160a96c > [landau:24457] *** Process received signal *** > [landau:24457] Signal: Bus error (10) > [landau:24457] Signal code: Invalid address alignment (1) > [landau:24457] Failing at address: 0x15ef4dc > [landau:24456] *** End of error message *** > [landau:24457] *** End of error message *** > -- > mpiexec noticed that process rank 1 with PID 0 on node landau exited on > signal 10 (Bus error). > -- > [...] > The following tests FAILED: > 517 - EpetraExt_Permutation_test_LL_MPI_4 (Failed) > 521 - EpetraExt_Transpose_test_LL_MPI_4 (Failed) > 523 - EpetraExt_inout_test_LL_MPI_4 (Failed) > 525 - EpetraExt_MatrixMatrix_test_LL_MPI_4 (Failed) > 621 - AztecOO_AztecOO_test_LL_MPI_4 (Failed) > 633 - ML_AztecSimple_MPI_4 (Failed) > 636 - ML_MatrixFree_MPI_4 (Failed) > 638 - ML_ML_Operator2Epetra_RowMatrix_MPI_4 (Failed) > 639 - ML_MLP_Maxwell_MPI_4 (Failed) > 640 - ML_MLP_NonSym_MPI_4 (Failed) > 648 - Komplex_simple_MPI_4 (Failed) > Errors while running CTest > > -- > Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) > http://www.mit.edu/~amu/ | > http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu > >
Bug#880964: closed by Guido Günther <a...@sigxcpu.org> (Re: Bug#880964: git-buildpackage: non-ascii character in d/changelog: UnicodeDecodeError)
> I'm not uploading any wheels only the sources to pypi. I know; sources are Python version agnostic, so there's no handle on how to restrict the version; hence the idea of publishing wheels instead of sources. There appears to be another option though, see [1]. [1] https://stackoverflow.com/a/42792413/353337 On Mon, Nov 6, 2017 at 4:03 PM Guido Günther <a...@sigxcpu.org> wrote: > Hi, > On Mon, Nov 06, 2017 at 02:53:11PM +, Nico Schlömer wrote: > > Thanks for following up on this. > > > > > But this is not Python2. > > > > This is the culprit. I installed gbp with pip on my system, with pip > > defaulting to python2, which leads to an array of errors, e.g., the > > encoding error from above. Perhaps one way of preventing pip2-installs > from > > pypi is to create wheels with > > ``` > > python3 setup.py bdist_wheel > > ``` > > (not `python setup.py bdist_wheel --universal`); see [1]. > > I'm not uploading any wheels only the sources to pypi. I have no idea > how to make pip not use modules that are "Programming Language :: Python > :: 3" with Python2. > > Cheers, > -- Guido >
Bug#880964: closed by Guido Günther <a...@sigxcpu.org> (Re: Bug#880964: git-buildpackage: non-ascii character in d/changelog: UnicodeDecodeError)
Thanks for following up on this. > But this is not Python2. This is the culprit. I installed gbp with pip on my system, with pip defaulting to python2, which leads to an array of errors, e.g., the encoding error from above. Perhaps one way of preventing pip2-installs from pypi is to create wheels with ``` python3 setup.py bdist_wheel ``` (not `python setup.py bdist_wheel --universal`); see [1]. [1] https://packaging.python.org/tutorials/distributing-packages/#pure-python-wheels On Mon, Nov 6, 2017 at 3:33 PM Guido Günther <a...@sigxcpu.org> wrote: > Hi, > On Mon, Nov 06, 2017 at 02:21:16PM +, Nico Schlömer wrote: > > I've tried with 0.9.1 and I'm getting the same error. The error message > > makes sense too: In `_run_parsechangelog` one finds > > Then please provide steps to reproduce. > > > ``` > > self._contents.encode() > > ``` > > which fails in Python 2 if `self._contents` contains a non-ascii > character. > > (Reproducable with `'ö'.encode()`.) > > But this is not Python2. I know about encoding/decoding of strings in > Python but I don't know why it fails on your system. I have parsed all > changelogs in the archive in the passt and believe me your name isn't > the only one with an umlaut. What locale are you running under? What's > the exact git tree to reproduce this? > > Cheers, > -- Guido > > > Position 399 in the error message > > ``` > > UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 399: > > ordinal not in range(128) > > ``` > > also refers to an "ö". > > > > I would hence vote for reopening this bug. > > > > On Mon, Nov 6, 2017 at 2:30 PM Debian Bug Tracking System < > > ow...@bugs.debian.org> wrote: > > > > > This is an automatic notification regarding your Bug report > > > which was filed against the git-buildpackage package: > > > > > > #880964: git-buildpackage: non-ascii character in d/changelog: > > > UnicodeDecodeError > > > > > > It has been closed by Guido Günther <a...@sigxcpu.org>. > > > > > > Their explanation is attached below along with your original report. > > > If this explanation is unsatisfactory and you have not received a > > > better one in a separate message then please contact Guido Günther < > > > a...@sigxcpu.org> by > > > replying to this email. > > > > > > > > > -- > > > 880964: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880964 > > > Debian Bug Tracking System > > > Contact ow...@bugs.debian.org with problems > > > > > > > > > > > > -- Forwarded message -- > > > From: "Guido Günther" <a...@sigxcpu.org> > > > To: 880964-d...@bugs.debian.org > > > Cc: > > > Bcc: > > > Date: Mon, 6 Nov 2017 14:27:19 +0100 > > > Subject: Re: Bug#880964: git-buildpackage: non-ascii character in > > > d/changelog: UnicodeDecodeError > > > Version: git-buildpackge/0.9.1 > > > > > > Hi, > > > On Mon, Nov 06, 2017 at 02:17:29PM +0100, Nico Schlömer wrote: > > > > Package: git-buildpackage > > > > Version: 0.8.18 > > > > Severity: important > > > > > > > > When running > > > > ``` > > > > gbp import-orig --uscan --pristine-tar > > > > ``` > > > > on the gmsh package, gbp bails out with the error message > > > > ``` > > > > UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position > 399: > > > > ordinal not in range(128) > > > > ``` > > > > referring to > > > > ``` > > > > File "/usr/local/lib/python2.7/dist-packages/gbp/deb/changelog.py", > > > line 100, > > > > in _run_parsechangelog > > > > (stdout, stderr) = cmd.communicate(self._contents.encode()) > > > > > > > > ``` > > > > This is because of the non-ascii character "ö". > > > > > > This is wired and likely not the source of the problem (not that my > name > > > contiains a 'ü' as well). However I can't reproduce this with 0.9.x on > > > gmsh from sid. > > > Cheers, > > > -- Guido > > > > > > > > > -- Forwarded message -- > > > From: "Nico Schlömer" <nico.schloe...@gmail.com> > > > To: Debian Bug Tracking System <sub...@bugs.debian.org> > > > Cc: > > > Bcc: > > > Date: Mon, 06 Nov 2017 14:17:29 +0100 >
Bug#880964:
Digging further, I found that the error can be fixed with
```
io.open(self.filename, mode='r', encoding='utf-8')
```
in `_read`, just as described in [1]. Note that
```
self._contents.encode()
```
needs to become
```
self._contents.encode('utf-8')
```
then, too.
[1] https://stackoverflow.com/a/83/353337
Bug#880964: closed by Guido Günther <a...@sigxcpu.org> (Re: Bug#880964: git-buildpackage: non-ascii character in d/changelog: UnicodeDecodeError)
I've tried with 0.9.1 and I'm getting the same error. The error message makes sense too: In `_run_parsechangelog` one finds ``` self._contents.encode() ``` which fails in Python 2 if `self._contents` contains a non-ascii character. (Reproducable with `'ö'.encode()`.) Position 399 in the error message ``` UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 399: ordinal not in range(128) ``` also refers to an "ö". I would hence vote for reopening this bug. On Mon, Nov 6, 2017 at 2:30 PM Debian Bug Tracking System < ow...@bugs.debian.org> wrote: > This is an automatic notification regarding your Bug report > which was filed against the git-buildpackage package: > > #880964: git-buildpackage: non-ascii character in d/changelog: > UnicodeDecodeError > > It has been closed by Guido Günther <a...@sigxcpu.org>. > > Their explanation is attached below along with your original report. > If this explanation is unsatisfactory and you have not received a > better one in a separate message then please contact Guido Günther < > a...@sigxcpu.org> by > replying to this email. > > > -- > 880964: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880964 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems > > > > -- Forwarded message -- > From: "Guido Günther" <a...@sigxcpu.org> > To: 880964-d...@bugs.debian.org > Cc: > Bcc: > Date: Mon, 6 Nov 2017 14:27:19 +0100 > Subject: Re: Bug#880964: git-buildpackage: non-ascii character in > d/changelog: UnicodeDecodeError > Version: git-buildpackge/0.9.1 > > Hi, > On Mon, Nov 06, 2017 at 02:17:29PM +0100, Nico Schlömer wrote: > > Package: git-buildpackage > > Version: 0.8.18 > > Severity: important > > > > When running > > ``` > > gbp import-orig --uscan --pristine-tar > > ``` > > on the gmsh package, gbp bails out with the error message > > ``` > > UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 399: > > ordinal not in range(128) > > ``` > > referring to > > ``` > > File "/usr/local/lib/python2.7/dist-packages/gbp/deb/changelog.py", > line 100, > > in _run_parsechangelog > > (stdout, stderr) = cmd.communicate(self._contents.encode()) > > > > ``` > > This is because of the non-ascii character "ö". > > This is wired and likely not the source of the problem (not that my name > contiains a 'ü' as well). However I can't reproduce this with 0.9.x on > gmsh from sid. > Cheers, > -- Guido > > > -- Forwarded message -- > From: "Nico Schlömer" <nico.schloe...@gmail.com> > To: Debian Bug Tracking System <sub...@bugs.debian.org> > Cc: > Bcc: > Date: Mon, 06 Nov 2017 14:17:29 +0100 > Subject: git-buildpackage: non-ascii character in d/changelog: > UnicodeDecodeError > Package: git-buildpackage > Version: 0.8.18 > Severity: important > > When running > ``` > gbp import-orig --uscan --pristine-tar > ``` > on the gmsh package, gbp bails out with the error message > ``` > UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 399: > ordinal not in range(128) > ``` > referring to > ``` > File "/usr/local/lib/python2.7/dist-packages/gbp/deb/changelog.py", line > 100, > in _run_parsechangelog > (stdout, stderr) = cmd.communicate(self._contents.encode()) > > ``` > This is because of the non-ascii character "ö". > > > > -- System Information: > Debian Release: stretch/sid > APT prefers artful-updates > APT policy: (500, 'artful-updates'), (500, 'artful-security'), (500, > 'artful') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 4.13.0-16-generic (SMP w/4 CPU cores) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), > LANGUAGE=en_US.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages git-buildpackage depends on: > ii devscripts2.17.9build1 > ii git 1:2.14.1-1ubuntu4 > ii man-db2.7.6.1-2 > ii python2.7.14-2ubuntu1 > ii python-dateutil 2.6.0-1 > ii python-pkg-resources 36.2.7-2 > ii python-six1.10.0-4 > > Versions of packages git-buildpackage recommends: > ii pbuilder 0.228.9 > ii pristine-tar 1.41 > ii python-requests 2.18.1-1 > > Versions of packages git-buildpackage suggests: > pn python-notify > ii sudo 1.8.20p2-1ubuntu1 > ii unzip 6.0-21ubuntu1 > > -- Configuration Files: > /etc/git-buildpackage/gbp.conf changed [not included] > > -- no debconf information >
Bug#880964: git-buildpackage: non-ascii character in d/changelog: UnicodeDecodeError
Package: git-buildpackage Version: 0.8.18 Severity: important When running ``` gbp import-orig --uscan --pristine-tar ``` on the gmsh package, gbp bails out with the error message ``` UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 399: ordinal not in range(128) ``` referring to ``` File "/usr/local/lib/python2.7/dist-packages/gbp/deb/changelog.py", line 100, in _run_parsechangelog (stdout, stderr) = cmd.communicate(self._contents.encode()) ``` This is because of the non-ascii character "ö". -- System Information: Debian Release: stretch/sid APT prefers artful-updates APT policy: (500, 'artful-updates'), (500, 'artful-security'), (500, 'artful') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.13.0-16-generic (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages git-buildpackage depends on: ii devscripts2.17.9build1 ii git 1:2.14.1-1ubuntu4 ii man-db2.7.6.1-2 ii python2.7.14-2ubuntu1 ii python-dateutil 2.6.0-1 ii python-pkg-resources 36.2.7-2 ii python-six1.10.0-4 Versions of packages git-buildpackage recommends: ii pbuilder 0.228.9 ii pristine-tar 1.41 ii python-requests 2.18.1-1 Versions of packages git-buildpackage suggests: pn python-notify ii sudo 1.8.20p2-1ubuntu1 ii unzip 6.0-21ubuntu1 -- Configuration Files: /etc/git-buildpackage/gbp.conf changed [not included] -- no debconf information
Bug#868523: FTBFS: test failed 617 ML_MLP_NonSym_MPI_4, 668 Phalanx_dag_manager_MPI_1
> I intentionally didn't close this bug because the tests still fail if they are enabled. Right. Well, I've reported the bug upstream [1] and at this point there's not much more than we can do. Unfortunately, Trilinos has a history of failing tests, the list of subpackages for which we have to disable them is long: ``` -DAmesos2_ENABLE_TESTS:BOOL=OFF \ -DAnasazi_ENABLE_TESTS:BOOL=OFF \ -DBelos_ENABLE_TESTS:BOOL=OFF \ -DDomi_ENABLE_TESTS:BOOL=OFF \ -DEpetra_ENABLE_TESTS:BOOL=OFF \ -DIfpack_ENABLE_TESTS:BOOL=OFF \ -DIsorropia_ENABLE_TESTS:BOOL=OFF \ -DMueLu_ENABLE_TESTS:BOOL=OFF \ -DNOX_ENABLE_TESTS:BOOL=OFF \ -DPhalanx_ENABLE_TESTS:BOOL=OFF \ -DPiro_ENABLE_TESTS:BOOL=OFF \ -DShyLU_ENABLE_TESTS:BOOL=OFF \ -DShyLUCore_ENABLE_TESTS:BOOL=OFF \ -DStratimikos_ENABLE_TESTS:BOOL=OFF \ -DTeko_ENABLE_TESTS:BOOL=OFF \ -DTeuchos_ENABLE_TESTS:BOOL=OFF \ -DTeuchosComm_ENABLE_TESTS:BOOL=OFF \ -DTeuchosCore_ENABLE_TESTS:BOOL=OFF \ -DXpetra_ENABLE_TESTS:BOOL=OFF \ -DZoltan_ENABLE_TESTS:BOOL=OFF \ -DZoltan2_ENABLE_TESTS:BOOL=OFF \ ``` Not all of those disables are associated with upstream bugs, unfortunately, but then again it's probably a Sisyphean task to do so. As usual for those bugs, either they are fixed immediately or never. Cheers, Nico [1] https://github.com/trilinos/Trilinos/issues/1332 On Mon, Jul 24, 2017 at 10:53 AM Graham Inggs <gin...@debian.org> wrote: > On 24/07/2017 10:40, Nico Schlömer wrote: > > Sounds more like a gAM bug then. Can this be closed? > > I intentionally didn't close this bug because the tests still fail if > they are enabled. > > If the problem is caused by another package, then this bug should be > reassigned to that package and marked that it affects trilinos. >
Bug#853679:
With tbb 2017~U7-2 in experimental, this can probably be closed now. Cheers, Nico
Bug#868523: FTBFS: test failed 617 ML_MLP_NonSym_MPI_4, 668 Phalanx_dag_manager_MPI_1
> Still comes out corrupted in the gnome Archive Manager, but extracts fine on the command line. Sounds more like a gAM bug then. Can this be closed? Cheers, Nico On Mon, Jul 17, 2017 at 4:33 AM Drew Parsons <dpars...@debian.org> wrote: > On Mon, 17 Jul 2017 10:21:03 +0800 Drew Parsons <dpars...@debian.org> > wrote: > > > > For whatever reason, the build does not fail on the buildd (odd, my > > test ran 842 tests, buildd only runs 830). > > Ah I see, you uploaded -4 while we were testing :) > The bugserver didn't send me the bug traffic. > > > Adding my build log again, the first attachment appears corrupted. > > Still comes out corrupted in the gnome Archive Manager, but extracts > fine on the command line. > >
Bug#868873: dependence on libmumps-4.10.0 _AND_ libmumps-5.1.1 breaks make
Thanks, Graham, for the analysis. It appears that with 12.10.1-4 we're on top of things, so I guess this can be closed. Cheers, Nico On Sun, Jul 23, 2017 at 9:51 PM Graham Inggs <gin...@debian.org> wrote: > On 23 July 2017 at 18:07, Nico Schlömer <nico.schloe...@gmail.com> wrote: > > Hm, funny! I don't get how libtrilinos-amesos12 should depend on > > libmumps-4.10.0 when 5.1.1 is available. > > libtrilinos-amesos12/12.10.1-3 depends on libmumps-4.10.0 because > libtrilinos_amesos.so.12 is linked to libdmumps-4.10.0.so and > libmumps_common-4.10.0.so > > As per debian/control, libtrilinos-amesos-dev depends on any version > of libmumps-dev. > > The new version of MUMPS changed ABI in a backward-incompatible way, > requiring a transition in Debian and every package that was built > against libmumps-4.10.0 needed to be rebuilt against libmumps-5.1.1 to > pick up the new dependencies. See the transition bug #864650 for more > details. > > The binNMU of trilinos 12.10.1-3+b1, which was supposed to pick up the > new dependencies, failed to build from source, see: > https://buildd.debian.org/status/logs.php?pkg=trilinos=amd64 > and also bug #868523. > > > We've recently uploaded 12.10.1-4, perhaps this rebuild will solve your > > problem. > > Trilinos 12.10.1-4 was built against libmumps-5.1.1 and migrated to > testing on 2017-07-22, see: > https://packages.qa.debian.org/t/trilinos/news/20170722T043921Z.html >
Bug#868873: dependence on libmumps-4.10.0 _AND_ libmumps-5.1.1 breaks make
Hm, funny! I don't get how libtrilinos-amesos12 should depend on libmumps-4.10.0 when 5.1.1 is available. I've rebuild this on ubuntu artsy [1] and it selects all the right versions. Perhaps this got corrupted in the transition somehow? We've recently uploaded 12.10.1-4, perhaps this rebuild will solve your problem. Cheers, Nico [1] https://launchpadlibrarian.net/329863686/buildlog_ubuntu-artful-amd64.trilinos_12.11~git20170720-31a5b251-1artful1_BUILDING.txt.gz [2] https://packages.debian.org/buster/trilinos-all-dev On Sun, Jul 23, 2017 at 1:12 PM Joachim Wuttke <j.wut...@fz-juelich.de> wrote: > > I don't think it is possible for trilinos to depend on both versions. > > Of course it should not. > But it does. > > $ apt-cache show libtrilinos-amesos-dev > Package: libtrilinos-amesos-dev > Source: trilinos > Version: 12.10.1-3 > .. > Depends: libmumps-dev, libtrilinos-amesos12 (= 12.10.1-3), trilinos-dev > > $ apt-cache show libmumps-dev > Package: libmumps-dev > Source: mumps > Version: 5.1.1-2 > .. > Depends: libmumps-5.1.1 (= 5.1.1-2), libscalapack-mpi-dev, mpi-default-dev > > $ apt-cache show libtrilinos-amesos12 > Package: libtrilinos-amesos12 > Source: trilinos > Version: 12.10.1-3 > .. > Depends: libc6 (>= 2.14), libgcc1 (>= 1:3.0), libmumps-4.10.0, > libopenmpi2, libstdc++6 (>= 5.2), libtrilinos-epetra12, > libtrilinos-epetraext12, libtrilinos-teuchos12 > >
Bug#868894: find_package option COMPONENTS ineffective because of hard-coded includes in TrilinosConfig.cmake
Thanks, Joachim, for the report! This definitely sounds like an upstream bug. Would you mind reporting it on [1]? Together with the Trilinos devs, we'll be able to take it from there. That being said, at first glance the inclusion of the subpackage configs doesn't seem to override anything. I'd be interested to improve the cmake export config though. Cheers, Nico [1] https://github.com/trilinos/trilinos/issues On Sun, Jul 23, 2017 at 1:36 PM Joachim Wuttke <j.wut...@fz-juelich.de> wrote: > Package: trilinos-dev > Version: 12.10.1-3 > > CMake's find_package takes an option COMPONENTS. > Usage with Trilinos seems to be documented nowhere, > but TrilinosConfig.cmake clearly is intended to > support e.g. > find_package(Trilinos REQUIRED COMPONENTS Epetra Belos Ifpack) > > However, at the bottom of TrilinosConfig.cmake there > is a long list that includes all Trilinos subproject > CMake files. This overwrites the component selection, > and makes it ineffective: the client application will > depend on _all_ of Trilinois, not just on the selected > components. > >
Bug#868523: FTBFS: test failed 617 ML_MLP_NonSym_MPI_4, 668 Phalanx_dag_manager_MPI_1
I've disabled the phalanx tests in master, and also fixed two other things. Perhaps it's time for an upload? Cheers, Nico On Sun, Jul 16, 2017 at 2:16 PM Nico Schlömer <nico.schloe...@gmail.com> wrote: > The issue was reported to upstream in May [1]. I think until we get a fix, > it's best to disable that specific test. > > Cheers, > Nico > > > [1] https://github.com/trilinos/Trilinos/issues/1332 > > On Sun, Jul 16, 2017 at 1:51 PM Graham Inggs <gin...@debian.org> wrote: > >> On 16 July 2017 at 13:12, Drew Parsons <dpars...@debian.org> wrote: >> > Testing trilinos build on a porterbox for the mumps 5.1.1 transition. >> > >> > The following tests FAILED: >> > 617 - ML_MLP_NonSym_MPI_4 (Failed) >> > 668 - Phalanx_dag_manager_MPI_1 (Failed) >> > >> > Not sure if it's the new mumps, new openmpi 2.1.1 or something else. >> > Full build log attached. >> >> Reproducible build history shows FTBFS since 2017-07-02: >> https://tests.reproducible-builds.org/debian/history/amd64/trilinos.html >> >> Although with only one test failure: >> >> The following tests FAILED: >> 668 - Phalanx_dag_manager_MPI_1 (Failed) >> >>
Bug#868523: FTBFS: test failed 617 ML_MLP_NonSym_MPI_4, 668 Phalanx_dag_manager_MPI_1
The issue was reported to upstream in May [1]. I think until we get a fix, it's best to disable that specific test. Cheers, Nico [1] https://github.com/trilinos/Trilinos/issues/1332 On Sun, Jul 16, 2017 at 1:51 PM Graham Inggs <gin...@debian.org> wrote: > On 16 July 2017 at 13:12, Drew Parsons <dpars...@debian.org> wrote: > > Testing trilinos build on a porterbox for the mumps 5.1.1 transition. > > > > The following tests FAILED: > > 617 - ML_MLP_NonSym_MPI_4 (Failed) > > 668 - Phalanx_dag_manager_MPI_1 (Failed) > > > > Not sure if it's the new mumps, new openmpi 2.1.1 or something else. > > Full build log attached. > > Reproducible build history shows FTBFS since 2017-07-02: > https://tests.reproducible-builds.org/debian/history/amd64/trilinos.html > > Although with only one test failure: > > The following tests FAILED: > 668 - Phalanx_dag_manager_MPI_1 (Failed) > >
Bug#866678: libtbb-dev: upstream on github
Package: libtbb-dev Version: 4.4~20160526-0ubuntu2 Severity: minor The watch file still points to https://www.threadingbuildingblocks.org/download https://www.threadingbuildingblocks.org/sites/default/files/software_releases/source/tbb([0-9_]+)oss_src\.tgz but upstream has moved to GitHub [1] a while ago. `watch` should be updated. [1] https://github.com/01org/tbb/releases -- System Information: Debian Release: stretch/sid APT prefers zesty-updates APT policy: (500, 'zesty-updates'), (500, 'zesty-security'), (500, 'zesty'), (100, 'zesty-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.10.0-24-generic (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libtbb-dev depends on: ii libtbb2 4.4~20160526-0ubuntu2 libtbb-dev recommends no packages. Versions of packages libtbb-dev suggests: pn libtbb-doc pn tbb-examples -- no debconf information
Bug#859173: ninja-build is unuseable for package cross compilation
Hi, I'm the upstream ninja maintainer. Helmut asked me to leave a short comment here after talking on IRC. I believe option 1 should be safe; ninja shouldn't change in behavior for different build, host, or target*. *: (One small deviation is Windows: ninja built on Windows behaves slightly differently than ninja built on non-Windows, but in fairly minor ways, and I think this shouldn't affect debian.)
Bug#864779: Epetra doc missing
Let me add also that Epetra isn't that important anymore. Trilinos devs try to get people to switch over to Tpetra, and in fact Epetra hasn't seen substantial development in many years now. Cheers, Nico On Thu, Jun 15, 2017 at 5:22 PM Nico Schlömer <nico.schloe...@gmail.com> wrote: > Thanks Joachim for report. > > This is more of an upstream issue, see [1]. Once that is done, the package > will have the Epetra documentation shipped. > > Cheers, > Nico > > [1] https://github.com/trilinos/Trilinos/issues/1431 > > On Wed, Jun 14, 2017 at 6:42 PM Joachim Wuttke <j.wut...@fz-juelich.de> > wrote: > >> Package: trilinos-doc >> Version: 12.10.1-3 >> >> Documentation of the important Trilinos component Epetra >> is missing in /usr/share/doc/trilinos. >> >>
Bug#864779: Epetra doc missing
Thanks Joachim for report. This is more of an upstream issue, see [1]. Once that is done, the package will have the Epetra documentation shipped. Cheers, Nico [1] https://github.com/trilinos/Trilinos/issues/1431 On Wed, Jun 14, 2017 at 6:42 PM Joachim Wuttke <j.wut...@fz-juelich.de> wrote: > Package: trilinos-doc > Version: 12.10.1-3 > > Documentation of the important Trilinos component Epetra > is missing in /usr/share/doc/trilinos. > >
Bug#863760: dput-ng: document return codes
Package: dput-ng Severity: minor dput-ng often fails to upload with output like ``` dput -c /path/to/dput.cf mypackage mypackage_1.0.0-1xenial1_source.changes Return code: 3 Output: None ``` The return code may differ, and it's always unclear what it actually means. Please document dput-ng's return codes. -- System Information: Debian Release: stretch/sid APT prefers zesty-updates APT policy: (500, 'zesty-updates'), (500, 'zesty-security'), (500, 'zesty'), (100, 'zesty-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.10.0-21-generic (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#863723: dput-ng: skip `please login: To accept ssh-rsa hostkey [...]`
Package: dput-ng Version: 1.8 Severity: wishlist I'm using dput-ng for submitting builds to launchpad via sftp. Every time I submit, I have to answer the question ``` please login: To accept ssh-rsa hostkey 6b03de9833252318a646b34722cd54f2 for ppa.launchpad.net type "yes": [yes, no]: ``` That makes it impossible to dput in a cron job. I've played around with my SSH settings, but that doesn't seem to have anything do with it. Is there a way to skip the above question? Cheers, Nico -- System Information: Debian Release: stretch/sid APT prefers zesty-updates APT policy: (500, 'zesty-updates'), (500, 'zesty-security'), (500, 'zesty'), (100, 'zesty-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.10.0-21-generic (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#862111: python-slepc4py: Python 3 support
Package: python-slepc4py Version: 3.7.0-2build3 Severity: wishlist slepc4py is compatible with Python 3.2 and up (see [1]), and it'd be nice to this reflected in the package. [1] https://bitbucket.org/slepc/slepc4py -- System Information: Debian Release: stretch/sid APT prefers zesty-updates APT policy: (500, 'zesty-updates'), (500, 'zesty-security'), (500, 'zesty') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.10.0-20-generic (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages python-slepc4py depends on: ii libc6 2.24-9ubuntu2 ii libgcc1 1:6.3.0-12ubuntu2 ii libopenmpi2 2.0.2-2 ii libpetsc3.7.5 [libpetsc3.7] 3.7.5+dfsg1-4build1 ii libslepc3.7.3 [libslepc3.7] 3.7.3+dfsg1-5build1 ii libstdc++66.3.0-12ubuntu2 ii python2.7.13-2 ii python-numpy [python-numpy-abi9] 1:1.12.1-1ubuntu1 ii python-petsc4py 3.7.0-2build1 pn python:any python-slepc4py recommends no packages. python-slepc4py suggests no packages. -- no debconf information
Bug#862110: python-petsc4py: Python 3 support
Package: python-petsc4py Version: 3.7.0-2build1 Severity: wishlist petsc4py is compatible with Python 3.2 and up (see [1]) and it'd be nice to see this reflected in the package. [1] https://bitbucket.org/petsc/petsc4py -- System Information: Debian Release: stretch/sid APT prefers zesty-updates APT policy: (500, 'zesty-updates'), (500, 'zesty-security'), (500, 'zesty') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.10.0-20-generic (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages python-petsc4py depends on: ii libc6 2.24-9ubuntu2 ii libgcc1 1:6.3.0-12ubuntu2 ii libopenmpi2 2.0.2-2 ii libpetsc3.7.5 [libpetsc3.7] 3.7.5+dfsg1-4build1 ii libstdc++66.3.0-12ubuntu2 ii python2.7.13-2 ii python-numpy [python-numpy-abi9] 1:1.12.1-1ubuntu1 pn python:any python-petsc4py recommends no packages. python-petsc4py suggests no packages. -- no debconf information
Bug#860365: mutter: Graphical glitches on Intel GMA X4500 with SNA and Wayland
I can confirm the issue of graphical glitches, being on a fully up to date version of Stretch with Linux 4.9, Gnome 3.22, Mesa 13.0.6. I'm testing this on a Thinkpad T400. Kind regards, Nico Rikken
Bug#810254:
Hi everyone, I did some work on this in the last few days and I got to something. As requested, it's all committed to the vtk6 repo (and also available from [1]). As far as I can tell, it's all in good order. I'm already running a bunch of applications against it with no nasty surprises so far. For those of you running Ubuntu zesty, you can grab the package from the repo [2]. (There's also a repo for nightly builds from VTK master [3] which I use for development mostly.) Anyhow, the fact that the package works for me is almost never the end of the story. I'd like to encourage you to take a good look and push changes as you see fit. Hopefully we can this out to experimental sometime soon. Cheers, Nico [1] https://github.com/nschloe/debian-vtk7 [2] https://launchpad.net/~nschloe/+archive/ubuntu/vtk7 [3] https://launchpad.net/~nschloe/+archive/ubuntu/vtk7-nightly
Bug#860231: libxdmf-dev: update XDMF from Git
Package: libxdmf-dev Severity: wishlist Dear Maintainer, I'm currently in the process of packaging VTK7, and it depends on XDMF3. It does require a version newer than git20160803 however, so I'd be great if that could be updated from upstream. Cheers, Nico -- System Information: Debian Release: stretch/sid APT prefers zesty-updates APT policy: (500, 'zesty-updates'), (500, 'zesty-security'), (500, 'zesty') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.10.0-19-generic (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#651527:
I've had the same error message and definitely isn't a space issue. Apparently, my input FLAC file was broken (?), but I could work around the problem by * converting the sound file to another lossless format, e.g., `ffmpeg -i input.flac input.wav` and * using shnsplit on the new input file.
Bug#854624: fenics: vcs information incorrect
Package: fenics Version: 1:2016.2.0.1~ppa1~yakkety Severity: minor Tags: newcomer Dear Maintainer, on [1], the VCS is still listed as SVN and has a dysfunctional link. This should be updated to the new Git repo (in debian/control). Cheers, Nico [1] https://tracker.debian.org/pkg/fenics -- System Information: Debian Release: stretch/sid APT prefers yakkety-updates APT policy: (500, 'yakkety-updates'), (500, 'yakkety-security'), (500, 'yakkety'), (100, 'yakkety-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.0-37-generic (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages fenics depends on: ii dolfin-bin 2016.2.0-1~ppa3~yakkety1 ii dolfin-doc 2016.2.0-1~ppa3~yakkety1 ii libdolfin-dev 2016.2.0-1~ppa3~yakkety1 ii libmshr-dev 2016.2.0-1~ppa1~yakkety1 ii mshr-demos 2016.2.0-1~ppa1~yakkety1 ii python-dijitso 2016.2.0-1~ppa1~yakkety1 ii python-dolfin 2016.2.0-1~ppa3~yakkety1 ii python-ffc 2016.2.0-1~ppa1~yakkety1 ii python-fiat 2016.2.0-1~ppa1~yakkety1 ii python-instant 2016.2.0-1~ppa1~yakkety1 ii python-mshr 2016.2.0-1~ppa1~yakkety1 ii python-ufl 2016.2.0-1~ppa1~yakkety1 ii python-ufl-doc 2016.2.0-1~ppa1~yakkety1 Versions of packages fenics recommends: pn python-scitools fenics suggests no packages. -- no debconf information
Bug#810254:
Thanks Anton for the swift reply. Is the vtk7-branch in the vtk6 or the original vtk package (which is VTK 5)? Considering that history, I would have opened up a whole new package vtk7. Cheers, Nico On Sat, Feb 4, 2017 at 11:13 AM Anton Gladky <gl...@debian.org> wrote: > Hi Nico, > > thanks for your contribution! We will definitely upload VTK7 after > Stretch will be released. Feel free to commit into the alioth > into the vtk7-branch. > > Best regards > > > Anton > > 2017-02-04 10:54 GMT+01:00 Nico Schlömer <nico.schloe...@gmail.com>: > > Alright, so I've spend last night packaging VTK7 (nightly master) [1]. > It's basically a clone of the vtk6 package with a bunch of fixes. Will have > to be tested some more, but for certain it's already a better-than-nothing. > > Comments and PRs are more than welcome; the code is on GitHub [2]. > > Cheers, > Nico > > [1] https://launchpad.net/~nschloe/+archive/ubuntu/vtk7-nightly > [2] https://github.com/nschloe/debian-vtk7 > > > -- > debian-science-maintainers mailing list > debian-science-maintain...@lists.alioth.debian.org > > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers > >
Bug#810254:
Alright, so I've spend last night packaging VTK7 (nightly master) [1]. It's basically a clone of the vtk6 package with a bunch of fixes. Will have to be tested some more, but for certain it's already a better-than-nothing. Comments and PRs are more than welcome; the code is on GitHub [2]. Cheers, Nico [1] https://launchpad.net/~nschloe/+archive/ubuntu/vtk7-nightly [2] https://github.com/nschloe/debian-vtk7
Bug#851833: binary-or-shlib-defines-rpath too strict
Package: lintian Version: 2.5.48 Severity: normal Since recently, I'm seeing a lot of binary-or-shlib-defines-rpath [1] errors from lintinan on Trilinos [2]. It says in the description of the warning: ``` To fix this problem, look for link lines like: gcc test.o -o test -Wl,--rpath,/usr/local/lib or gcc test.o -o test -R/usr/local/lib and remove the -Wl,--rpath or -R argument. ``` Indeed, the Trilinos installation contains many of those lines, but they are necessary too. When executing the test binaries (which are compiled in the build tree alongside the libraries), they have to find the linked shared libraries. Messing with the rpath is necessary. That's not true later on when the libraries are _installed_, of course. For this, CMake has the switch CMAKE_SKIP_INSTALL_RPATH [3], which serves exactly that purpose. For some reason, lintian doesn't seem to be happy with that though. Looks like a bug in Lintian? Can you confirm? [1] https://lintian.debian.org/tags/binary-or-shlib-defines-rpath.html [2] https://tracker.debian.org/pkg/trilinos [3] https://cmake.org/cmake/help/v3.0/variable/CMAKE_SKIP_INSTALL_RPATH.html -- System Information: Debian Release: stretch/sid APT prefers yakkety-updates APT policy: (500, 'yakkety-updates'), (500, 'yakkety-security'), (500, 'yakkety'), (100, 'yakkety-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.0-34-generic (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages lintian depends on: ii binutils 2.27-8ubuntu2 ii bzip2 1.0.6-8build1 ii diffstat 1.61-1 ii file 1:5.28-2ubuntu1 ii gettext 0.19.8.1-1ubuntu2 ii intltool-debian 0.35.0+20060710.4 ii libapt-pkg-perl 0.1.29build7 ii libarchive-zip-perl 1.59-1 ii libclass-accessor-perl0.34-1 ii libclone-perl 0.38-2 ii libdpkg-perl 1.18.10ubuntu1 ii libemail-valid-perl 1.200-1 ii libfile-basedir-perl 0.07-1 ii libipc-run-perl 0.94-1 ii liblist-moreutils-perl0.416-1 ii libparse-debianchangelog-perl 1.2.0-10 ii libperl5.22 [libdigest-sha-perl] 5.22.2-3 ii libtext-levenshtein-perl 0.13-1 ii libtimedate-perl 2.3000-2 ii liburi-perl 1.71-1 ii libyaml-libyaml-perl 0.41-6build1 ii man-db2.7.5-1 ii patchutils0.3.4-1 ii perl 5.22.2-3 ii t1utils 1.39-2 ii xz-utils 5.1.1alpha+20120614-2.1ubuntu1 Versions of packages lintian recommends: ii dpkg 1.18.10ubuntu1 ii libperlio-gzip-perl 0.19-1build1 ii perl 5.22.2-3 ii perl-modules-5.22 [libautodie-perl] 5.22.2-3 Versions of packages lintian suggests: pn binutils-multiarch ii dpkg-dev 1.18.10ubuntu1 ii libhtml-parser-perl3.72-2 pn libtext-template-perl -- no debconf information
Bug#851787: exodusii: integrate exodusii into trilinos?
Package: exodusii Severity: minor Exodus is developed as part of SEACAS [1] for a while now. While separate releases are still being published [2], it might make more sense to use the Trilinos package [3] to provide SEACAS and Exodus. Thoughts? [1] https://github.com/gsjaardema/seacas/tree/master/packages/seacas/libraries/exodus [2] https://sourceforge.net/projects/exodusii/ [3] https://tracker.debian.org/pkg/trilinos -- System Information: Debian Release: stretch/sid APT prefers yakkety-updates APT policy: (500, 'yakkety-updates'), (500, 'yakkety-security'), (500, 'yakkety'), (100, 'yakkety-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.0-34-generic (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#848770: trilinos: FTBFS: Test failures
Thanks Lucas for the report. A new version (12.10.1-2) has already been submitted to NEW, fixing the test failures. Cheers, Nico On Mon, Dec 19, 2016 at 10:43 PM Lucas Nussbaum <lu...@debian.org> wrote: > Source: trilinos > Version: 12.10.1-1 > Severity: serious > Tags: stretch sid > User: debian...@lists.debian.org > Usertags: qa-ftbfs-20161219 qa-ftbfs > Justification: FTBFS on amd64 > > Hi, > > During a rebuild of all packages in sid, your package failed to build on > amd64. > > Relevant part (hopefully): > > Stokhos = 15.38 sec (52 tests) > > Teko = 45.70 sec (19 tests) > > Teuchos = 10.19 sec (53 tests) > > Thyra= 22.12 sec (80 tests) > > Tpetra = 31.81 sec (113 tests) > > Triutils = 0.55 sec (2 tests) > > > > Total Test time (real) = 320.29 sec > > > > The following tests FAILED: > > 592 - Isorropia_part_sizes_MPI_4 (Failed) > > 630 - ShyLUCore_belos_driver_MPI_4 (Failed) > > 631 - ShyLUCore_shylu_factor_MPI_4 (Failed) > > 677 - Teko_ProbingFactory_MPI_1 (Failed) > > Errors while running CTest > > Makefile:152: recipe for target 'test' failed > > The full build log is available from: >http://aws-logs.debian.net/2016/12/19/trilinos_12.10.1-1_unstable.log > > A list of current common problems and possible solutions is available at > http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! > > About the archive rebuild: The rebuild was done on EC2 VM instances from > Amazon Web Services, using a clean, minimal and up-to-date chroot. Every > failed build was retried once to eliminate random failures. > >
Bug#835406: trilinos: FTBFS on 32-bit architectures
Done [1] and done [2]. Graham, you might want to subscribe to those PRs. Cheers, Nico [1] https://github.com/kokkos/kokkos/pull/57 <https://github.com/kokkos/kokkos/pull/576>5 [2] https://github.com/kokkos/kokkos/pull/576 On Fri, Dec 9, 2016 at 11:22 AM Graham Inggs <gin...@debian.org> wrote: > On 9 December 2016 at 09:49, Nico Schlömer <nico.schloe...@gmail.com> > wrote: > > The patch looks really simple. Great! Do you think it'd be worthwhile > > updating the PR [1] (or opening a new one)? Perhaps the kokkos devs can > > figure out why the remaining tests are failing. > > No harm in trying, I guess. :) > Please update the PR, but I suggest leaving out the static_asserts, > i.e. don't include the changes to Kokkos_Core_fwd.hpp and > Kokkos_TaskQueue.hpp. > Also, I think the changes to Kokkos_Macros.hpp from > kokkos-disable-asm.patch should go in a separate PR. Hopefully they > can merge that right away. >
Bug#835406: trilinos: FTBFS on 32-bit architectures
The patch looks really simple. Great! Do you think it'd be worthwhile updating the PR [1] (or opening a new one)? Perhaps the kokkos devs can figure out why the remaining tests are failing. Cheers, Nico [1] https://github.com/kokkos/kokkos/pull/410 On Fri, Dec 9, 2016 at 8:18 AM Graham Inggs <gin...@debian.org> wrote: > Attached is an updated version of kokkos-32-bit.patch against upstream > 12.10.1. > It turns out that once the templates were fixed, the overloaded > function declarations were not needed. > > Builds and test of Kokkos-only and all Trilinos packages on 64-bit > architectures are not affected. > > On 32-bit architectures that have an 8-byte compare-and-swap > implementation (e.g. armhf and i386), a Kokkos-only build is > successful, but 1 out of the 21 unit tests, > KokkosCore_UnitTest_Serial_MPI_1, fails. > KokkosCore_UnitTest_Serial_MPI_1 includes 60 tests and of these only 4 > fail with errors like: > > Value of: result[i].value[j] > Actual: 5.5e+09 > Expected: (ScalarType) correct > Which is: 7.05083e+08 > > A build of all Trilinos packages fails with a few errors similar to > the following: > > packages/tpetra/core/test/Distributor/createfromsendsandrecvs.cpp:315:61: > error: conversion from ‘Teuchos::ArrayView’ to > non-scalar type ‘Teuchos::ArrayView’ > requested >ArrayView c = dist.getLengthsFrom(); > > > For a Kokkos-only build, which saves a huge amount of time (thanks > Nico!), make the following changes to debian/rules: > > --- a/debian/rules > +++ b/debian/rules > @@ -93,8 +93,9 @@ > -DTrilinos_INSTALL_INCLUDE_DIR:PATH=include/trilinos/ \ > -DTrilinos_USE_GNUINSTALLDIRS:BOOL=ON \ > -DTrilinos_ENABLE_DEVELOPMENT_MODE:BOOL=OFF \ > - -DTrilinos_ENABLE_ALL_PACKAGES:BOOL=ON \ > - -DTrilinos_ENABLE_SECONDARY_TESTED_CODE:BOOL=ON \ > + -DTrilinos_ENABLE_ALL_PACKAGES:BOOL=OFF \ > + -DTrilinos_ENABLE_SECONDARY_TESTED_CODE:BOOL=OFF \ > + -DTrilinos_ENABLE_Kokkos:BOOL=ON \ > -DTrilinos_ASSERT_MISSING_PACKAGES:BOOL=OFF \ > -DTrilinos_ENABLE_EXPLICIT_INSTANTIATION:BOOL=ON \ > -DTrilinos_ENABLE_CTrilinos:BOOL=OFF \ >
