Bug#1036350: O: gcc-msp430 -- GNU C compiler (cross compiler for MSP430)
> The gcc-msp430 package is obviously not maintained anymore. > I hereby orphan it. Please only consider adopting it if you can > afford the time and have the skills to maintain it. Apologies for not seeing/reacting to this bug earlier. This package is effectively an early experimental/forked toolchain, which used to live at https://sourceforge.net/projects/mspgcc/. It has become obsolete in the meanwhile (in favor of plain upstream project) and is not developed anymore. Instead of new adoption, it would be better to drop it from Debian at this point. I'll proceed with a removal request. Cheers, Luca pgpwtteQN68zp.pgp Description: OpenPGP digital signature
Bug#1036349: O: gdb-msp430 -- The GNU debugger for MSP430
> The gdb-msp430 package is obviously not maintained anymore. > I hereby orphan it. Please only consider adopting it if you can > afford the time and have the skills to maintain it. Apologies for not seeing/reacting to this bug earlier. This package is effectively an early experimental/forked toolchain, which used to live at https://sourceforge.net/projects/mspgcc/. It has become obsolete in the meanwhile (in favor of plain upstream project) and is not developed anymore. Instead of new adoption, it would be better to drop it from Debian at this point. I'll proceed with a removal request. Cheers, Luca pgpFu4yqu2hUy.pgp Description: OpenPGP digital signature
Bug#1032461: ITS: gtk-gnutella
On Tue, 7 Mar 2023 12:05:39 +0100 Bastian Germann wrote: > Source: gtk-gnutella > Version: 1.1.15-1 > > I am filing this ITS in order to remove the package after three weeks. > The last maintainer upload was in 2015, two NMUs since then. Ack. I think nowadays the userbase for this package is quite limited, and I'm personally not closely following its development anymore. That said, upstream is still active on GitHub in case people want to follow along: https://github.com/gtk-gnutella/gtk-gnutella/ Ciao, Luca
Bug#1032462: ITS: argon2
On Tue, 7 Mar 2023 12:11:14 +0100 Bastian Germann wrote: > Source: argon2 > Version: 0~20190702-0.1 > > There have been 4 NMUs since the last maintainer upload. > I am filing this ITS in order to orphan the package after three weeks. Ack, I'm still around but I haven't had much time for Debian packaging lately. If somebody wants to take over argon2, feel free to directly take it through salsa.d.o; I can be happily moved as a last-ditch Uploader there. Ciao, Luca
Bug#1008781: nemiver: Intent to remove from Debian
eremy Bicha wrote: > I intend to file a removal bug for nemiver soon. It has failed to > build for more than a year. It wasn't autoremoved sooner because it > was included in one of the metapackages in meta-gnome3. I agree, it's time to let it go. If you are already in the process of asking for its removal, please feel free to proceed. Ciao, Luca
Bug#902972: libargon2-0 install a symlink pointin to libargon2.so.1
On Wednesday, 4 July 2018 07:31:30 UTC you wrote: > The libargon2-0 package is pulling the libargon2-1 package and contains > a symlink pointing to libargon2.so.1. > > This is not a good idea and a proper transition should be done. Is there a specific issue this is causing? While odd, the rationale for such setup is described here: https://salsa.debian.org/debian/argon2/merge_requests/3#note_28753 Ciao, Luca -- "If you build a wall, think of what you leave outside it" - Italo Calvino signature.asc Description: This is a digitally signed message part.
Bug#891434: grub-efi: System fails to boot after "No space left on device" on EFI variable storage
Hi, I experienced the same today after a grub update to '2.02+dfsg1-1' on testing. Looking back at logs, grub-install reported an error but the upgrade process as a whole didn't fail, so I missed it at first: ``` Could not prepare Boot variable: No space left on device grub-install: error: efibootmgr failed to register the boot entry: Input/output error. Failed: grub-install --target=x86_64-efi WARNING: Bootloader is not properly installed, system may not be bootable ``` However, after manually recovering via efibootmgr, the ESP doesn't seem to be full nor close to: ``` # df -h Filesystem Size Used Avail Use% Mounted on /dev/sda4 3.7G 238M 3.2G 7% /boot /dev/sda1 256M 24M 233M 10% /boot/efi ``` My pstore has ~150 entries, all quite small (~1Kb), and none of them are recent. So I'm not sure why this specific upgrade got stuck on ENOSPC. Ciao, Luca -- "If you build a wall, think of what you leave outside it" - Italo Calvino signature.asc Description: This is a digitally signed message part.
Bug#886651: [Pkg-rust-maintainers] Bug#886651: cargo: Missing dependency on llvm to get llvm-config
On Monday, January 8, 2018 3:26:07 PM UTC Sylvestre Ledru wrote:
> Trying to build https://github.com/marco-c/grcov/ using cargo
> $ cargo build
>
> It is failing on:
>
>Compiling rust-crypto v0.2.36
> error: failed to run custom build command for `grcov v0.1.31
> (file:///home/sylvestre/dev/mozilla/grcov)` process didn't exit
> successfully:
> `/home/sylvestre/dev/mozilla/grcov/target/debug/build/grcov-c8b56ee863ef452
> a/build-script-build` (exit code: 101) --- stderr
> thread 'main' panicked at 'Error while running llvm-config: Error { repr: Os
> { code: 2, message: "No such file or directory" } }',
> /checkout/src/libcore/result.rs:906:4 note: Run with `RUST_BACKTRACE=1` for
> a backtrace.
>
> Installing the llvm package which provides llvm-config was enough to fix my
> issue.
This come from here, though:
https://github.com/marco-c/grcov/blob/v0.1.31/build.rs#L6
So it should be a build-dep of your grcov package, not cargo itself.
Ciao, Luca
--
"If you build a wall, think of what you leave outside it" - Italo Calvino
signature.asc
Description: This is a digitally signed message part.
Bug#868661: RM: uzbl -- ROM; RC-buggy
Package: ftp.debian.org Severity: normal
Bug#860116: [Pkg-rust-maintainers] Bug#860116: RFH: cargo -- Rust package manager
On Thursday, April 20, 2017 8:16:00 AM UTC Ximin Luo wrote: > - cargo still embeds libgit2-sys source code, and I can see that in the > deps-tarball-filter.txt Luca was explicitly leaving it in. Is that because > they patch the source code? > > Can we just get rid of it, and link to libgit2 instead? It would be nice, but last time I tried upstream was tracking libgit2 from master: https://github.com/alexcrichton/git2-rs/pull/80 Things may have changed in the meanwhile, I did not re-assess since then. Ciao, Luca -- "If you build a wall, think of what you leave outside it" - Italo Calvino signature.asc Description: This is a digitally signed message part.
Bug#842634: [Pkg-rust-maintainers] Bug#842634: rustc: FTBFS (sys_common::net::tests::no_lookup_host_duplicates fails)
severity 842634 minor thanks On Sunday, 30 October 2016 23:09:35 UTC Santiago Vila wrote: > I wonder what exactly this test "no_lookup_host_duplicates" does. > My autobuilder do not have a FQDN, it has just this in /etc/hosts: > > public-ip skywalker1 > > Is this a bug in my autobuilder? I hope not. > > In either case, I would just forward this upstream and disable the > test which fails. I'm just lowering the severity here to unblock the migration, but I honestly believe your autobuilder is misconfigured. The "no_lookup_host_duplicates" tries to resolve localhost and verify that there aren't ipv4/ipv6 duplicates, however your host is missing an /etc/hosts line for localhost and the test panics. I don't have any reference at hand, but I'd consider the environment broken. Ciao, Luca signature.asc Description: This is a digitally signed message part.
Bug#844577: RFS: openldap/2.4.44+dfsg-1 [RC]
On Thursday, 17 November 2016 08:56:54 UTC Arturo Borrero Gonzalez wrote: > On 17 November 2016 at 04:15, Ryan Tandy wrote: > > Package: sponsorship-requests > > Severity: important > > > > Dear mentors, > > > > I am looking for a sponsor to upload an updated openldap package. The > > > package can be found on alioth: > Hi, > > ping me if Luca Bruno is not sponsoring this upload and I will sponsor > myself. Please go ahead. I'm quite short on time at the moment and I don't have anymore access to an LDAP infrastructure for testing. Ciao, Luca signature.asc Description: This is a digitally signed message part.
Bug#835360: rkt: FTBFS on several architectures
On Thursday, 13 October 2016 13:59:27 UTC Andreas Henriksson wrote:
> Fwiw, there's a chain of {build-,}dependencies that would need to be
> removed on ppc64el
Ah, when I wrote my previous answer I didn't realize that.
Upon further inspection, it looks like it may be just enough to cherry-pick
this fix on top of gopsutil:
https://github.com/shirou/gopsutil/pull/261
Ciao, Luca
--
«Доверяй, но проверяй»
signature.asc
Description: This is a digitally signed message part.
Bug#835360: rkt: FTBFS on several architectures
On Thursday, 13 October 2016 21:18:07 UTC Dmitry Smirnov wrote: > Rkt 1.16.0 FTBFS on ppc64el and s390x: > > https://buildd.debian.org/status/package.php?p=rkt > > Any ideas what we can do about it? s390(x) is not supported upstream for the moment, but this shouldn't be a blocker as it has never been built there before anyway. Regarding ppc64el, it looks like you hit again https://github.com/shirou/gopsutil/issues/230 Given that upstream is not planning to fix it anytime soon, I'd recommend to ask for a removal for rkt (1.9.1+dfsg-1) on ppc64el for now, so that it can transition to stretch without being blocked by that arch until some porters get to it. Cheers, Luca -- «Доверяй, но проверяй» signature.asc Description: This is a digitally signed message part.
Bug#835360: rkt: FTBFS on several architectures
1.13.0+dfsg-1 has been built without issues on i386: https://buildd.debian.org/status/fetch.php?pkg=rkt&arch=i386&ver=1.13.0%2Bdfsg-1&stamp=1472188080 ppc64 and s390x are in progress upstream and should hopefully be back in the next releases. Ciao, Luca -- «Доверяй, но проверяй» signature.asc Description: This is a digitally signed message part.
Bug#828931: llvm-toolchain-3.7: FTBFS on i386 with gcc-6 and glibc 2.23
severity 828931 important thanks Hi, are you also pulling something else from experimental (eg. gdb) or building in some slow/virtual environment? It looks like you are just hitting a timeout while pexpect-ing, so I fear that it is more easily related to your specific environment than the newer gcc/ glibc: > line 1414, in expect_loop > raise TIMEOUT (str(e) + '\n' + str(self)) > TIMEOUT: Timeout exceeded in read_nonblocking(). I'm also bringing this back to its original severity, as a test timeout in lldb-mi with mixed-in experimental stuff doesn't fit as "serious". Ciao, Luca -- «Доверяй, но проверяй» signature.asc Description: This is a digitally signed message part.
Bug#828779: Illegal instruction: me too
tag 828779 + confirmed thanks On Saturday 06 August 2016 15:44:42 Joey Hess wrote: > Package: libargon2-0 > Version: 0~20160406-2 > Severity: normal > > Both the command line program argon2 and the library fail with SIGILL on > my laptop. It seems to SIGILL on an XOP opcode: ``` Thread 2 "argon2" received signal SIGILL, Illegal instruction. [Switching to Thread 0x77419700 (LWP 4337)] 0x00406aaf in ?? () (gdb) x/i $pc => 0x7790230d : mov%rax,%rdi (gdb) x/i 0x00406aaf 0x406aaf:vprotq $0x20,%xmm1,%xmm1 ``` I guess this is leaking into final binary due to the use of -march=native for blake optimizations. Options are: 1) Build without optimizations 2) Tweak -march I'd go for 2), but I have to take a better look at what should be the correct portable -march target. DEB_TARGET_GNU_CPU perhaps? Cheers, Luca -- «Доверяй, но проверяй» signature.asc Description: This is a digitally signed message part.
Bug#823322: please build "systemd-sysusers" binary
On Thursday 16 June 2016 00:26:59 Dmitry Smirnov wrote: > Dear Michael, > > On Monday, 6 June 2016 1:53:02 PM AEST Michael Biebl wrote: > > Now, regarding my concerns: The size increase is one (which will affect > > everyone if we ship it s part of the systemd package). > > Michael, I don't know how to respond to this. It was mentioned that size > increase we are talking about is only 380k (uncompressed) which is 1/3 of a > floppy disk. Seriously? How can this be a concern these days in 2016? Recording some IRC discussion from today on #debian-systemd, it looks like the current plan is to first do some space saving changes upstream, via the PR referenced below, and then systemd-sysusers size won't be anymore a concern and can get into systemd proper: ``` pitti, fsateler, mbiebl_: is there any chance we can reach at least a stopgap solution wrt. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=823322 ? kaeso: if/once we can land fsateler's link branch, this shouldn't actually be a concern any more :) pitti: which one? (I'm probably missing some backlog/ref) kaeso: pitti I was just writing a reply referencing that branch https://github.com/systemd/systemd/pull/3516 fsateler: thanks for the ref. So the idea is that saving space on lib side will let enough room to let systemd-sysusers in? fsateler> kaeso: not only that, but the sysusers binary itself will be smaller ``` Ciao, Luca signature.asc Description: This is a digitally signed message part.
Bug#823322: please build "systemd-sysusers" binary
On Sun, 5 Jun 2016 21:58:54 +0200 Michael Biebl wrote: > Am 05.06.2016 um 17:59 schrieb Dmitry Smirnov: > > Could we introduce raw "systemd-sysusers" binary ASAP to fix "rkt" please? > > The size is a concern, and we mentioned this before. > This really is a wishlist bug, so bumping the severity is not justified. In a previous follow-up I proposed an alternative if size bloat is a concern: adding "systemd-sysusers" to the "systemd-container" binary package (possibly without enabling it). Are there other downsides wrt this approach? Ciao, Luca signature.asc Description: This is a digitally signed message part.
Bug#824453: gtk-gnutella: please make the build reproducible
On Tuesday, May 17, 2016 08:00:43 PM Chris Lamb wrote: > Hi, > > > gtk-gnutella: please make the build reproducible > > Apologies but my initial patch was incomplete. I have attached an updated > version. > > (Thanks to Reiner Herrmann for spotting this.) Thanks both for working on this! I'd like to remove myself as a middleman here: can you submit this directly to upstream to get it merged there? Ciao, Luca
Bug#823322: please build "systemd-sysusers" binary
On Sun, 15 May 2016 14:01:20 +0200 Michael Biebl wrote: > Can you clarify a bit more, why exactly rkt needs systemd-sysusers? rkt (aka stage0) supports several stage1 flavors (the component responsible for running the containerized-app/stage2). Debian package currently defaults to the "host" stage1 flavor, which will just re-use systemd components from the host instead of rebuilding everything from scratch. > Fwiw, I share the same concerns as Felipe about increasing the footprint > about ~308 kB for everyone, especially since sysusers isn't used > anywhere else atm. > Splitting it out is something I'm not keen about either. If you are concerned about size and don't plan to use systemd-sysusers in the near future, what about putting it in the "systemd-container" binary package? That way it will not clutter minimal setup, but it will be available for other consumers (sysusers.d may be skipped for the moment, if nothing else need it). If at some point you decide to start using it, you can just move it to the main binary and activate the service unit. Cheers, Luca signature.asc Description: This is a digitally signed message part.
Bug#820501: libseccomp FTBFS on hppa (with patch)
forwarded 820501 https://github.com/seccomp/libseccomp/issues/28 tags 820501 + upstream thanks On Sat, 9 Apr 2016 10:03:31 +0200 Helge Deller wrote: > Nevertheless, until the patch gets applied upstream, can you please > apply it to the next upload of libseccomp? For reference: - Upstream tracking bug: https://github.com/seccomp/libseccomp/issues/28 - Upstream patch review: https://groups.google.com/forum/#!topic/libseccomp/6O28XC3urtY I would personally prefer to wait for upstream final review and merge, and then just cherry-pick that patch revision. Ciao, Luca signature.asc Description: This is a digitally signed message part.
Bug#822325: [Pkg-rust-maintainers] Bug#822325: rustc: FTBFS in testing: test fail
forwarded 822325 https://github.com/rust-lang/rust/pull/33640 thanks On Saturday, May 14, 2016 02:52:55 PM Santiago Vila wrote: > > In both cases the problem went away by setting > DefaultTasksMax=infinity in /etc/systemd/system.conf. Good catch! I was aware of it, but didn't come to my mind in this context. > So I tried doing that with rustc and the problem went away as well. > > For reference, this was the setting in systemd which most likely was > to blame for this: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=823530 > > This setting has been changed in systemd yesterday and it will reach > testing in four days, so if you still want to reproduce this in rustc > in testing (using the kernel in testing), maybe you could. I was not able to reproduce it as I was building from a user session, while you are probably outside of it (system service or a naked shell). I just reproduced it via `systemd-run --scope -p TasksMax=512 ./tcp-stress`. Part of it is due to the tcp-stress test not checking for spawned thread, I've just submitted a PR to make that failure explicit: https://github.com/rust-lang/rust/pull/33640 If your sbuild is running as a daemon or in any other dedicated way, I think you should ask for its TasksMax setting to be increased. Ciao, Luca signature.asc Description: This is a digitally signed message part.
Bug#822325: rustc: FTBFS in testing: test fail
severity 822325 minor tags 822325 + moreinfo thanks On Sat, 23 Apr 2016 14:33:48 +0200 (CEST) Santiago Vila wrote: > This package currently fails to build from source in stretch. > > -- > executing x86_64-unknown-linux-gnu/test/run-pass/tcp-stress.stage2-x86_64- > unknown-linux-gnu > --stdout-- > > --stderr-- > thread '' panicked at 'called `Result::unwrap()` on an `Err` value: > RecvError', src/libcore/result.rs:746 > > -- > > The build was made on two different QEMU virtual machines with 4GB RAM > and 4GB swap, running stretch, using sbuild. This looks like an artifact due to your build environment, as I just tried building on a physical stretch amd64 machine and all tests pass: """ summary of 50 test runs: 10108 passed; 0 failed; 88 ignored; 0 measured """ A couple of ideas regarding this test: * it is heavily threaded, it may trigger some data races in qemu * it may be slow to run and thus timing out. Can you try increasing the timeout at the top of src/test/run-pass/tcp-stress.rs? * It may be dropping the sender to early. Can you try moving the `drop(tx)` just before `process::exit(0)`? Anyway, this looks like just some test instability on an emulated environment, and not a real regression. Thus I'm downgrading it. Can you please try the small changes I suggested above? If so, it may be worth reporting it directly to upstream. Ciao, Luca
Bug#819282: wheezy-pu: package openldap/2.4.31-2+deb7u2
On Tuesday, May 03, 2016 07:31:29 AM Ryan Tandy wrote: > On Sun, May 01, 2016 at 03:07:38PM -0700, Ryan Tandy wrote: > >On Sun, May 01, 2016 at 10:27:12PM +0100, Adam D. Barratt wrote: > >>Any news on the upload? > > > >None from me. Awaiting a response from my sponsor (CCed). > > The package has been uploaded now. Thanks, Luca! This was sitting in my pending queue for some time, sorry for the delay :( Ciao, Luca -- .''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso) : :' : The Universal O.S.| lucab (AT) debian.org `. `'` | GPG: 0xBB1A3A854F3BBEBF `- http://www.debian.org | Debian GNU/Linux Developer signature.asc Description: This is a digitally signed message part.
Bug#821128: rkt: FTBFS on ppc64el: undefined: SYS_SYNCFS
tags 821128 + patch thanks On Fri, 15 Apr 2016 15:52:19 -0400 "Aaron M. Ucko" wrote: > Please either add an appropriate sys_linux_*.go file supplying this > definition or restrict the Architecture: field to reflect reality. Patch with the additional constant definition sent upstream: https://patch-diff.githubusercontent.com/raw/coreos/rkt/pull/2443.patch Tested on ppc64 and ppc64le. However, ppc64 (BE) still has some trouble and compilation fails in another place: """ /usr/bin/make -C _build/src/github.com/coreos/rkt BUILDDIR="/home/lucab/rkt-1.3.0+dfsg"/_build GOPATH="/home/lucab/rkt-1.3.0+dfsg"/_build/src2 make[2]: Entering directory '/home/lucab/rkt-1.3.0+dfsg/_build/src/github.com/coreos/rkt' GO github.com/coreos/rkt/rkt ../../../../src2/src/github.com/appc/spec/pkg/tarheader/pop_posix.go:24:2: no buildable Go source files in /home/lucab/rkt-1.3.0+dfsg/_build/src2/src/github.com/appc/spec/pkg/device makelib/build_go_bin.mk:47: recipe for target '/home/lucab/rkt-1.3.0+dfsg/_build/bin/rkt' failed """ (at the moment ppc64 BE is not a release architecture, though) Ciao, Luca signature.asc Description: This is a digitally signed message part.
Bug#821166: [nemiver] Wrong Vcs-* headers
tags + 821166 pending thanks On Saturday, April 16, 2016 10:23:27 AM Giovanni Mascellani wrote: > Package: nemiver > Version: 0.9.6-1+b1 > Severity: normal > > debian/rules in nemiver contains: > > Vcs-Git: git://anonscm.debian.org/collab-maint/ipv6calc.git > > Vcs-Browser: https://anonscm.debian.org/cgit/collab-maint/ipv6calc.git > > They do not really seem to be the right thing... You are right, my copy-paste mistake when adding them. I've just updated them in current git repository, which FYI is at: Vcs-Git: https://anonscm.debian.org/git/collab-maint/nemiver.git Vcs-Browser: https://anonscm.debian.org/git/collab-maint/nemiver.git Ciao, Luca -- .''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso) : :' : The Universal O.S.| lucab (AT) debian.org `. `'` | GPG: 0xBB1A3A854F3BBEBF `- http://www.debian.org | Debian GNU/Linux Developer signature.asc Description: This is a digitally signed message part.
Bug#820994: argon2: Section should be “utils”
On Thursday, April 14, 2016 10:18:12 PM Ben Finney wrote: > The package ‘argon2’ installs primarily an application, of interest > because it installs a complete program. It should not be in the “libs” > section. > By the section descriptions, this package belongs in section “utils”. You are definitely right, I made a mistake when adding the binary package stanza. > Then mark this bug report as blocked by that new one, and be sure not > to close this one until that new one is completed. Will proceed with both asking ftp for adjustment and with a new revision with proper section. Just for the sake of a clarity: is there a preferred order of actions or both are fine (upload-then-bug-ftp or viceversa)? Cheers, Luca -- .''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso) : :' : The Universal O.S.| lucab (AT) debian.org `. `'` | GPG: 0xBB1A3A854F3BBEBF `- http://www.debian.org | Debian GNU/Linux Developer signature.asc Description: This is a digitally signed message part.
Bug#820491: argon2: missing man page for argon2
On Friday, April 08, 2016 10:39:04 PM Daniel Kahn Gillmor wrote: > argon2 is missing a manpage, and it doesn't respond well to the usual > -h or --help (it treats those as an attempted salt). Usage is printed when no arguments are passed. I agree this is not very intuitive, will propose upstream if they are ok with using -h for help and moving hash length to -l. > The attached patch (which i'll push to collab-maint shortly) fixes the > problem. I'd be happy if they want to adopt this upstream, but i am > not in touch with upstream. Feel free to forward it to them! I've see all your commits, thanks for it (and for sticking to CC0). I'll forward the manpage and a couple of other bits to upstream. A new upload will follow soon, I've just have another small change to land before that. Cheers, Luca -- .''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso) : :' : The Universal O.S.| lucab (AT) debian.org `. `'` | GPG: 0xBB1A3A854F3BBEBF `- http://www.debian.org | Debian GNU/Linux Developer signature.asc Description: This is a digitally signed message part.
Bug#820859: libuv1: Temporarily block testing migration, phase-locking it to nodejs LTS
Package: libuv1 Version: 1.9.0-1 Severity: normal We still need to clear up whether nodejs LTS are locked to spcific libuv1 minor versions or not. For the moment, we block 1.9.0 here and wait for clarification before letting it in testing. Discussion is up at https://lists.debian.org/debian-release/2016/04/msg00280.html
Bug#819831: [Pkg-rust-maintainers] Bug#819831: Bug#819831: cargo: FTBFS: unable to satisfy build-depends
On Monday, April 04, 2016 11:14:00 PM Luca BRUNO wrote: > I think we may align cargo on that and just build with libcurl4-gnutls-dev > instead. Upstream prefers building with libcurl+openssl, > but I guess switching to gnutls shouldn't cause any issue here. I've just uploaded 0.8.0-2 with this change, with a low urgency (just to be sure it didn't break anything). Cheers, Luca -- .''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso) : :' : The Universal O.S.| lucab (AT) debian.org `. `'` | GPG: 0xBB1A3A854F3BBEBF `- http://www.debian.org | Debian GNU/Linux Developer signature.asc Description: This is a digitally signed message part.
Bug#819831: [Pkg-rust-maintainers] Bug#819831: cargo: FTBFS: unable to satisfy build-depends
On Saturday, April 02, 2016 11:05:05 PM Santiago Vila wrote: > and in fact this may not be solved by hand, because: > > * Installing libgit2-dev removes libcurl4-openssl-dev. > * Installing libcurl4-openssl-dev removes libgit2-dev. This seems to be due to libgit2-dev moving to gnutls, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798421 > Sorry not to have a fix, but certainly this is RC for stretch, as > packages in testing should be buildable in testing. I think we may align cargo on that and just build with libcurl4-gnutls-dev instead. Upstream prefers building with libcurl+openssl, but I guess switching to gnutls shouldn't cause any issue here. Cheers, Luca -- .''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso) : :' : The Universal O.S.| lucab (AT) debian.org `. `'` | GPG: 0xBB1A3A854F3BBEBF `- http://www.debian.org | Debian GNU/Linux Developer signature.asc Description: This is a digitally signed message part.
Bug#815364: OpenSLP 1.2 should not be part of stretch
severity 815364 important tags + 815364 pending thanks On Thu, 13 Aug 2015 23:55:59 +0200 Moritz Muehlenhoff wrote: > The last maintainer upload of openslp happened in 2007 > and it's orphaned for 5.5 years now. The 1.2 branch is > completely abandoned upstream. Thanks for the report. We already discussed dropping OpenSLP support from OpenLDAP and it is a planned change: http://lists.alioth.debian.org/pipermail/pkg-openldap-devel/2016-January/006598.html Our git trunk is currently entangled in a larger new upstream change, so we'll queue this for later. Cheers, Luca -- .''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso) : :' : The Universal O.S.| lucab (AT) debian.org `. `'` | GPG: 0xBB1A3A854F3BBEBF `- http://www.debian.org | Debian GNU/Linux Developer signature.asc Description: This is a digitally signed message part.
Bug#816739: rsyslog-gnutls: imtcp/TLS hangs on dropped packages
On Wednesday, March 09, 2016 09:09:42 PM you wrote: > I don't have the setup to test this. So if you want to see this fixed in > stable, it would be great if you can apply the upstream fix on top of > 8.4.2 and test whether it actually fixes the issue. I have this running live in a log aggregation center, but unfortunately reproducing this is somehow non-deterministic (it randomly happens from time to time, after several weeks that it is running under moderate load, without simple triggers). I have now applied this patch on top of 8.4.2-1+deb8u2, and I'll let it run for some time in the environment above to check if it still deadlocks (however I can't exclude false negatives if the bug doesn't trigger). Ciao, Luca -- .''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso) : :' : The Universal O.S.| lucab (AT) debian.org `. `'` | GPG: 0xBB1A3A854F3BBEBF `- http://www.debian.org | Debian GNU/Linux Developer signature.asc Description: This is a digitally signed message part.
Bug#816739: rsyslog-gnutls: imtcp/TLS hangs on dropped packages
Package: rsyslog-gnutls Version: 8.4.2-1+deb8u2 Severity: grave Tags: patch upstream Justification: causes non-serious data loss I have a log-aggregating server using rsyslog to receive multiple streams (both UDP and TCP), including some remote logs via TLS. I'm experiencing a lock of the TLS receiver under normal usage, and consequently the TLS-receiving thread of rsyslog using 100% CPU. After some initial debugging, this seems to be the same upstream bug as reported here: https://github.com/rsyslog/rsyslog/issues/318 This has been fixed in the latest upstream version: https://github.com/rsyslog/rsyslog/pull/494 I think this basically affects all setups where rsyslog is used as a TLS receiver, and results in losing logs on the receiving side (and increased buffer pressure on senders). Thus I'm reporting this at severity grave. It would be great if this could be fixed for current stable version, as rsyslog-gnutls is too buggy for production usage at the moment. -- System Information: Debian Release: 8.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.3.0-0.bpo.1-amd64 (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 rsyslog-gnutls depends on: ii libc6 2.19-18+deb8u3 ii libgnutls-deb0-28 3.3.8-6+deb8u3 ii libjson-c2 0.11-4 ii rsyslog8.4.2-1+deb8u2 rsyslog-gnutls recommends no packages. Versions of packages rsyslog-gnutls suggests: ii gnutls-bin 3.3.8-6+deb8u3 -- no debconf information
Bug#812488: Alternative chain verification failure after 1024b root CAs removal
retitle 812488 Alternative chain verification failure after 1024b root CAs removal severity 812488 grave thanks On Thu, 25 Feb 2016 09:14:19 -0600 Michael Shuler wrote: > On 02/22/2016 04:12 AM, Christian Beer wrote: > > It seems that the openssl update is not happening soon. Can you please > > include the 1024bit certificates again to solve this regression? > > Yeah, I have a work in progress branch that re-includes the 1024-bit > CAs. Ran back into #743339 on upgrade, so needs some additional testing.. After a jessie upgrade today, I got the same regression and spent some time debugging it (before finding this report) and got to the same conclusion as other here: side effect of removing 1024b root CAs is that OpenSSL 1.0.1 fails to verify alternative chains (where a server-sent intermediate CA is a locally trusted root one). I'm re-titling an raising the severity here, hoping it will help other people noticing the regression in the meanwhile. Cheers, Luca -- .''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso) : :' : The Universal O.S.| lucab (AT) debian.org `. `'` | GPG: 0xBB1A3A854F3BBEBF `- http://www.debian.org | Debian GNU/Linux Developer signature.asc Description: This is a digitally signed message part.
Bug#797623: opensaml2: transition needed for g++-5 ABIs
> On Tue, 01 Sep 2015 10:48:28 +0200 Ferenc Wagner wrote: > > I'll package new upstream versions of the whole Shibboleth stack to > > fix the outstanding OpenSAML security bug in unstable. > > This will change the SO version of xml-security-c and > > probably all other library packages in the stack. Does this change the > > big picture somehow? I don't understand the interdependencies of this > > transition. I had a quick look at this, and I think that libsaml is not getting any soname bump in latest upstream version: https://git.shibboleth.net/view/?p=cpp-opensaml.git;a=commitdiff;h=390147dc17687e900bf6a50f3577ccc611a0a7cd;hp=ec145bf31d59d23bbf63cdc39ffeb172ed29d67d As such, I think we can just proceed with a NMU introducing libsaml8v5. This will also remove the last blocker for libshibsp. Cheers, Luca -- .''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso) : :' : The Universal O.S.| lucab (AT) debian.org `. `'` | GPG: 0xBB1A3A854F3BBEBF `- http://www.debian.org | Debian GNU/Linux Developer signature.asc Description: This is a digitally signed message part.
Bug#810602: ITP: argon2 -- memory-hard hashing function
On Monday, January 11, 2016 08:57:23 AM Paul Wise wrote: > On Sun, Jan 10, 2016 at 8:03 PM, Luca Bruno wrote: > > Argon2 is a password-hashing function that can be used to hash passwords > > for credential storage, key derivation, or other applications. > > It might be better to move to client-side SSL certificates than keep > using passwords :) The description should probably be reworded a bit to stress that this is the outcome of the https://password-hashing.net/ competition. Cheers, Luca -- .''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso) : :' : The Universal O.S.| lucab (AT) debian.org `. `'` | GPG: 0xBB1A3A854F3BBEBF `- http://www.debian.org | Debian GNU/Linux Developer signature.asc Description: This is a digitally signed message part.
Bug#810602: ITP: argon2 -- memory-hard hashing function
Package: wnpp Severity: wishlist Owner: Luca Bruno * Package name: argon2 Version : 0~20151206-1 Upstream Author : D. Dinu, D. Khovratovich et al. * URL : https://github.com/P-H-C/phc-winner-argon2 * License : CC0 Programming Lang: C Description : memory-hard hashing function Argon2 is a password-hashing function that can be used to hash passwords for credential storage, key derivation, or other applications. . There are two main versions of Argon2: Argon2i and Argon2d. Argon2i is the safest against side-channel attacks, while Argon2d provides the highest resistance against GPU cracking attacks. . Argon2i and Argon2d are parametrized by: * A time cost, which defines the amount of computation realized and therefore the execution time, given in number of iterations * A memory cost, which defines the memory usage, given in kibibytes * A parallelism degree, which defines the number of parallel threads
Bug#809316: [Pkg-rust-maintainers] Bug#809316: rustc: Support of arm archs
On Tuesday, December 29, 2015 10:35:14 AM Sylvestre Ledru wrote: > Package: rustc > A contributor provides arm binaries: > https://github.com/warricksothr/RustBuild > We might be able to boostrap rust using it. Upstream is documenting quite well the maturity of each OS/arch they target: https://doc.rust-lang.org/nightly/book/getting-started.html arm (32,64) is currently at Tier2, same as mips (LE,BE). ppc is a Tier3, instead. Before providing binaries for non-Tier1 arches, I would discuss this with upstream, as we have several drawbacks: * we need an external/custom stage0 * no CI/testing before release * stability and support is not guaranteed IMHO, a better option would be to voice for promotion of some arches. armhf and arm64 looks like good candidates to me, and I guess the main blocker at the moment is lack of upstream CI infrastructure. Cheers, Luca -- .''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso) : :' : The Universal O.S.| lucab (AT) debian.org `. `'` | GPG: 0xBB1A3A854F3BBEBF `- http://www.debian.org | Debian GNU/Linux Developer signature.asc Description: This is a digitally signed message part.
Bug#809283: libuv: FTBFS: dh_install: cp: cannot stat 'debian/tmp/debian/tmp/dh-exec.AUyQ2PO5/usr/lib/x86_64-linux-gnu/libuv.so.0.10': No such file or directory
On Mon, 28 Dec 2015 23:14:03 + Chris Lamb wrote:
> Source: libuv
> Version: 0.10.36-3
> Usertags: ftbfs
> libuv fails to build from source in unstable/amd64:
The same package builds fine on jessie, and has been built fine in sid in July
2015, so this seems to be a regression somewhere else in the toolchain (or a
previous misuse on my side).
> [..]
> dh_install
> cp: cannot stat 'debian/tmp/debian/tmp/dh-exec.AUyQ2PO5/usr/lib/x86_64-
linux-gnu/libuv.so.0.10': No such file or directory
> dh_install: cp --reflink=auto -a debian/tmp/debian/tmp/dh-
exec.AUyQ2PO5/usr/lib/x86_64-linux-gnu/libuv.so.0.10
debian/libuv0.10/usr/lib/x86_64-linux-gnu// returned exit code 1
> [..]
The double "debian/tmp/" looks a bit fishy there.
I guess either debhelper or dh-exec are over-substituting ${DESTDIR}, or
started prepending one time too much.
Ciao, Luca
--
.''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso)
: :' : The Universal O.S.| lucab (AT) debian.org
`. `'` | GPG: 0xBB1A3A854F3BBEBF
`- http://www.debian.org | Debian GNU/Linux Developer
signature.asc
Description: This is a digitally signed message part.
Bug#808576: [Pkg-rust-maintainers] Bug#808576: rustc cannot compile programs: "unrecognized relocation in section"
On Monday 21 December 2015 12:27:47 Luca Bruno wrote: > For reference, current working sid toolchain is ld 2.25.90.20151209 and gcc > 5.3.1-4. Similarly, I tried in a fresh stretch environment and it works fine. The toolchain there is ld 2.25.90.20151209 and gcc 5.3.1-3. I think we are going to close this as it doesn't affect proper/fresh setups, but still it would be nice to know which mix of compilers/linker/runtime is causing this. Do you also have LLVM somewhere in your pipeline? Cheers, Luca -- .''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso) : :' : The Universal O.S.| lucab (AT) debian.org `. `'` | GPG: 0xBB1A3A854F3BBEBF `- http://www.debian.org | Debian GNU/Linux Developer signature.asc Description: This is a digitally signed message part.
Bug#808576: [Pkg-rust-maintainers] Bug#808576: rustc cannot compile programs: "unrecognized relocation in section"
tags 808576 + moreinfo unreproducible thanks On Monday 21 December 2015 01:09:46 Robbie Harwood wrote: > note: /usr/bin/ld: > /usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc_jemalloc-35c36e89.rl > ib(jemalloc.pic.o): unrecognized relocation (0x2a) in section > `.text.malloc_conf_init' /usr/bin/ld: final link failed: Bad value > collect2: error: ld returned 1 exit status I just tried on a fresh sid docker with rustc-1.5.0 and cannot reproduce. However I've already seen reports of similar symptoms unrelated to rust, so I think it is some kind of toolchain incompatibilities. I see you have a dirty environment mixing stable/testing/sid/experimental, and I guess the bug can be somehow due to that. Can you please provide the output of: * ld -V * cc -v Also, can you please check if any part of the toolchain can be upgraded? For reference, current working sid toolchain is ld 2.25.90.20151209 and gcc 5.3.1-4. Cheers, Luca -- .''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso) : :' : The Universal O.S.| lucab (AT) debian.org `. `'` | GPG: 0xBB1A3A854F3BBEBF `- http://www.debian.org | Debian GNU/Linux Developer signature.asc Description: This is a digitally signed message part.
Bug#786836: [Pkg-rust-maintainers] Bug#786836: packaging not yet ready for mass/stable usage
On Thursday 10 December 2015 10:58:28 Sylvestre Ledru wrote: > >> Even though Rust recently reached the 1.0 milestone, compiler and > >> ecosystem packaging still has to reach a "ready for the masses" > >> status. > > > > What needs to happen to resolve this bug? > > Myself, I am happy to let rust migrate to testing. Using the Debian rust > packages to build Firefox is a proof that it is ready for production. We had an informal discussion on IRC a bunch of days ago, and we now feel confident enough to let rustc+cargo into testing. rustc 1.5.0 has been tagged today, and together with cargo 0.6.0 we plan to let them migrate to testing. On the other hand, we are still a bit unsure on the rest of the ecosystem (for which we'll probably need a dh helper), so we still plan to keep on hold third-party libraries and apps packaging. I'll take care of closing this bug in a few days, assuming rustc+cargo are fine. Ciao, Luca -- .''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso) : :' : The Universal O.S.| lucab (AT) debian.org `. `'` | GPG: 0xBB1A3A854F3BBEBF `- http://www.debian.org | Debian GNU/Linux Developer signature.asc Description: This is a digitally signed message part.
Bug#806919: New upstream version (0.06) needed for TOML 0.4.0
Package: libtoml-parser-perl Version: 0.05-1 Severity: wishlist Tags: upstream A new upstream version (0.06) has been recently released, which introduces support for TOML 0.4.0. Given that the new 0.4.0 spec are now widely adopted (and that we will probably need this feature in a custom deb-helper), can you please update the package to 0.06? Thanks a lot, Luca
Bug#805916: RM: ksplice -- ROM; FTBFS; obsolete
Package: ftp.debian.org Severity: normal
Bug#805669: ksplice: FTBFS: x86_64-linux-gnu-gcc: error: /usr/lib/libbfd.a: No such file or directory
On Friday 20 November 2015 20:31:03 Chris West wrote: > The package fails to build: Even though this build failure could probably be adjusted by patching search paths, it is now clear that (the open part of) ksplice has been abandoned and the effort is shifting toward kpatch/kgraft. As such, I will proceed asking for the removal of ksplice. Cheers, Luca -- .''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso) : :' : The Universal O.S.| lucab (AT) debian.org `. `'` | GPG: 0xBB1A3A854F3BBEBF `- http://www.debian.org | Debian GNU/Linux Developer signature.asc Description: This is a digitally signed message part.
Bug#805817: Should instanbul be removed?
On Sunday 22 November 2015 20:30:14 Moritz Muehlenhoff wrote: > should instanbul be removed? Yes, I think so. I'll proceed asking for its removal. > - Alternatives exist For documentation purposes: Last time I tried, both byzanz and recordmydesktop worked fine as alternatives in GTK world. Gnome now should also come with integrated screen recording, but I never tried it. Cheers, Luca -- .''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso) : :' : The Universal O.S.| lucab (AT) debian.org `. `'` | GPG: 0xBB1A3A854F3BBEBF `- http://www.debian.org | Debian GNU/Linux Developer signature.asc Description: This is a digitally signed message part.
Bug#733295: gnutls-bin: please compile GnuTLS with DANE support
On Tue, 24 Mar 2015 23:11:51 +0100 Cyril Brulebois wrote: > > > 3. Yet another way might be to teach unbound to support GnuTLS in > > > addition to OpenSSL and NSS, so that one can build a GnuTLS variant > > > instead of an NSS one. > > option 3 would require probably using nettle as well as gnutls (for the > > dnssec client verification) -- i'm not sure what sort of twisty maze of > > dependencies or build-dependencies this creates, though :) > > Oh, nettle is an old friend (we use it as a sha1 implementation in > xserver-xorg-core-udeb). > > libunbound should only depend on libssl for the purposes of outbound > > DNS-over-TLS-over-TCP connections, right? the DNSSEC verification work > > only needs to use libcrypto (or nettle, if we were to port it, which > > would avoid the circularity). > > I really don't know. You can pretend somebody jumped on me asking > whether I was part of Debian and mentioned this issue that has been > tagged wontfix. That wouldn't be very far from what happened. ;) > > I can add nettlifying unbound to my ever growing to-do list, and see > what codepaths are involved there. Maybe someone even did that work > upstream already, I didn't check yet. I went ahead and coded the "nettlify libunbound" part, which is basically option 3 proposed above. I run this through upstream and they merged it today: https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=594 This changes only touch libunbound (and the testcases) to build with nettle, while the rest of unbound still needs openssl or NSS (mostly for TLS). Cheers, Luca -- .''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso) : :' : The Universal O.S.| lucab (AT) debian.org `. `'` | GPG: 0xBB1A3A854F3BBEBF `- http://www.debian.org | Debian GNU/Linux Developer signature.asc Description: This is a digitally signed message part.
Bug#803373: systemd: fail to enable/disable services that have no LSB init script
On 29/10/2015 14:05, Martin Pitt wrote: > Control: tag -1 moreinfo unreproducible > > Hello Luca, > > Luca Bruno [2015-10-29 12:29 +0100]: >> I've put a simple service in /lib/systemd/system. Doing systemctl >> start/stop on this service works correctly, however enable/disable >> doesn't work: "Failed to execute operation: No such file or directory". > Did you systemctl daemon-reload after placing the file there? What's > the exact file name you are adding and which command do you run? Does > this involve Alias= or templates? Does your file perhaps refer to a > nonexisting WantedBy= or RequiredBy=? > > I tried to reproduce this here: > > # cat << EOF > /lib/systemd/system/foo.service > [Unit] > Description=test > [Service] > Type=oneshot > ExecStart=/bin/echo hello > [Install] > WantedBy=multi-user.target > EOF > # systemctl daemon-reload > # systemctl enable foo.service > Created symlink from /etc/systemd/system/multi-user.target.wants/foo.service > to /lib/systemd/system/foo.service. > > So all as expected. I'm afraid we need a more detailled reproducer. > >> The reason is that my systemd service has no LSB init script. > That should be fine. We do call update-rc.d *if* there is an LSB init > script, but we have plenty of units even in a default install which > don't have one (e. g. hwclock-save.service). > >> By doing a touch /etc/init.d/servicename then enable/disable works, >> though update-rc.d will spit out some warning. > Interesting. So somehow your new unit thinks there is a SysV init > script and tries to call update-rc.d. > >> I can see this behaviour only on debian, so pretty sure it must caused >> by one of the 200+ patches. > The vast majority of them are actually ones from 215-stable and > cherry-picked ones from newer upstream versions, it's not actually > that bad. > > Do you have a chance to try this under testing/unstable? The whole > SysV init script handling got dramatically simplified there. > > Thanks, > > Martin > I installed a new service on a new jessie and didn't happen. I think it this bug can be closed for now, I guess it must have been something weird on my side... Thanks. Best regards,
Bug#803373: systemd: fail to enable/disable services that have no LSB init script
On 29/10/2015 14:05, Martin Pitt wrote: > Control: tag -1 moreinfo unreproducible > > Hello Luca, > > Luca Bruno [2015-10-29 12:29 +0100]: >> I've put a simple service in /lib/systemd/system. Doing systemctl >> start/stop on this service works correctly, however enable/disable >> doesn't work: "Failed to execute operation: No such file or directory". > Did you systemctl daemon-reload after placing the file there? What's > the exact file name you are adding and which command do you run? Does > this involve Alias= or templates? Does your file perhaps refer to a > nonexisting WantedBy= or RequiredBy=? > > I tried to reproduce this here: > > # cat << EOF > /lib/systemd/system/foo.service > [Unit] > Description=test > [Service] > Type=oneshot > ExecStart=/bin/echo hello > [Install] > WantedBy=multi-user.target > EOF > # systemctl daemon-reload > # systemctl enable foo.service > Created symlink from /etc/systemd/system/multi-user.target.wants/foo.service > to /lib/systemd/system/foo.service. > > So all as expected. I'm afraid we need a more detailled reproducer. Thanks for the quick reply. I did exactly your steps and I get the error above. WantedBy only, no Alias. Yes I did daemon-reload of course, start/stop works. > Do you have a chance to try this under testing/unstable? The whole > SysV init script handling got dramatically simplified there. Thanks, > Martin I can try in some virtual machine I guess. So I fear this is only related to jessie at the moment, if it works for you on sid. Best regards,
Bug#803373: systemd: fail to enable/disable services that have no LSB init script
Package: systemd Version: 215-17+deb8u2 Hello, using systemd 215-17+deb8u2 on jessie. I've put a simple service in /lib/systemd/system. Doing systemctl start/stop on this service works correctly, however enable/disable doesn't work: "Failed to execute operation: No such file or directory". The reason is that my systemd service has no LSB init script. By doing a touch /etc/init.d/servicename then enable/disable works, though update-rc.d will spit out some warning. But I DON'T want an LSB init script for my service, only the systemd service. I can see this behaviour only on debian, so pretty sure it must caused by one of the 200+ patches. Is there a way to properly workaround the issue? Is creating an empty LSB script ok or not? Because I don't know the consequences. Best regards,
Bug#746779: gtk-gnutella: situation prevails in Jessie more than a year after original bug report
On Saturday 19 September 2015 21:31:47 Axel wrote: > Package: gtk-gnutella > Version: 1.1.1-1 > Followup-For: Bug #746779 > > Dear Maintainer, > > I am trying out GTK Gnutella but it seems useless in this state − no search > results, no reaction to port forwarding, &c., so this bug report should be > moved up to “important”. A recent/working gtk-gnutella is available through jessie-backports. Unfortunately this is a time-based issue which doesn't fit well within the frame of Debian release. The package works perfectly at the time of release, but due to a time-bomb mechanism it may/will become useless at some point in future. Raising severity won't help here (maybe removing from further sub-releases will). Cheers, Luca -- .''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso) : :' : The Universal O.S.| lucab (AT) debian.org `. `'` | GPG: 0xBB1A3A854F3BBEBF `- http://www.debian.org | Debian GNU/Linux Developer signature.asc Description: This is a digitally signed message part.
Bug#796256: [Pkg-rust-maintainers] Bug#796256: Bug#796256: Please consider packaging a Rust version that allows #![feature(...)]
On Wednesday 02 September 2015 16:53:27 Ximin Luo wrote: > 1.4.0~~nightly.20150901+dfsg1-1 built for amd64, all tests passing, uploaded > here in experimental: > > https://people.torproject.org/~infinity0/apt/ > If people like it, I can upload a version to Debian experimental tomorrow. > I also made a beta version here, but haven't yet had time to build it: > > http://mentors.debian.net/debian/pool/main/r/rustc/rustc_1.3.0~beta.3.201508 > 12+dfsg1-1.dsc I have to agree with Angus here, I think that having nightlies in the archive is really a bad idea, even if just in experimental. Features are gated for a reason (still being discussed, to be soon removed, etc.) and it is counterproductive to easily provide them to the wide audience. Moreover, due to soname versioning, this means multiple trips through NEW every release cycle (6 weeks), and I honestly think it's a waste of project's resources. However, I fully see the benefits of building beta channel in order to catch regressions/bugs earlier (but that one too doesn't expose unstable features IIRC), and if we have some time we'd better coordinate the efforts for that. Regarding the specific initial issue (gated libc), doc explicitly tells to use the external "libc" crate instead. Even with nightly channel, the other project would still need to be patched. Cheers, Luca -- .''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso) : :' : The Universal O.S.| lucab (AT) debian.org `. `'` | GPG: 0xBB1A3A854F3BBEBF `- http://www.debian.org | Debian GNU/Linux Developer signature.asc Description: This is a digitally signed message part.
Bug#777601: systemd: Loosing LXC memory cgroups after service install
On Tue, 25 Aug 2015 19:10:50 +0200 Michael Biebl wrote: > Am 25.08.2015 um 18:41 schrieb Luca Bruno: > > > I've tried this patch and looks like adding another bug to me. Please > > confirm what I'm experiencing. It's true, it does not remove cgroups > > created by systemd, but then it doesn't cleanup cgroups that systemd > > created either. > > > > Example: > > > > 1) set MemoryLimit to a service, the memory limit will appear in the cgroups > > 2) unset MemoryLimit to the same service, reload daemon, restart, > > disable, re-enable, whatever... but the memory limit will NOT disappear > > from the cgroups > > > > Seems wrong and possibly worse to me. > > Please raise your issue upstream The issue I've mentioned is caused by the patch applied in the debian package. It fixes an issue, and introduces another one. It's not an upstream issue.
Bug#777601: systemd: Loosing LXC memory cgroups after service install
On Tue, 25 Aug 2015 18:41:59 +0200 Luca Bruno wrote: > I've tried this patch and looks like adding another bug to me. Please > confirm what I'm experiencing. It's true, it does not remove cgroups > created by systemd, but then it doesn't cleanup cgroups that systemd > created either. Correction, sorry for the confusing wording: "It's true, it does not remove cgroups *not* created by systemd, but then it doesn't cleanup cgroups that systemd created either."
Bug#777601: systemd: Loosing LXC memory cgroups after service install
Control: unarchive -1 On Thu, 12 Feb 2015 15:43:30 +0100 Martin Pitt wrote: > Hello again, > > so the patch that got proposed at > > http://lists.freedesktop.org/archives/systemd-devel/2014-September/023276.html > > actually makes a lot of sense: This makes systemd only clean up > cgroups that it created by itself, and thus won't clean up empty ones > in other controllers that LXC created. I tested this and committed > this for the experimental branch for now: > > http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=experimental&id=286ef78fd > > I'd like to see this out in the wild for some time before applying it > to jessie, though. I'm also still interested in what the actual impact > of that is -- critical seems rather inflated? Losing empty cgroups > doesn't sound that dangerous after all, aside from the LXC warnings > when shutting down a container? > > Thanks, I've tried this patch and looks like adding another bug to me. Please confirm what I'm experiencing. It's true, it does not remove cgroups created by systemd, but then it doesn't cleanup cgroups that systemd created either. Example: 1) set MemoryLimit to a service, the memory limit will appear in the cgroups 2) unset MemoryLimit to the same service, reload daemon, restart, disable, re-enable, whatever... but the memory limit will NOT disappear from the cgroups Seems wrong and possibly worse to me. Best regards,
Bug#795988: RFP: libtoml-perl -- Perl module for reading and writing TOML files
Package: wnpp Severity: wishlist * Package name: libtoml-perl Version : 0.96 Upstream Author : Darren Chamberlain et al. * URL : https://metacpan.org/pod/TOML * License : GPLv2 Programming Lang: Perl Description : Perl module for reading and writing TOML files TOML implements a parser for Tom's Obvious, Minimal Language, as defined at https://github.com/mojombo/toml. . TOML aims to be a minimal configuration file format that is easy to read due to obvious semantics. It is designed to map unambiguously to a hash table and it is easy to parse into data structures in a wide variety of languages.
Bug#795492: New upstream series (soname 2.5), please package it
Source: http-parser Severity: wishlist Hi, since the last upload of http-parser package, upstream had several intermediate releases and soname bumps. The current one is 2.5 and it is the current target for the next nodejs/iojs release cycle. Can you please update the package to latest version and bump the soname? Moreover, it looks like many packages are directly embedding http-parser as it is extremely small; it may be worth providing a -source binary package for them to use. If nobody has time for this, just let us know. I'll be happy to take this over inside the JS packaging team. Cheers, Luca
Bug#793855: DoS, Shibboleth SP software crashes on well-formed but invalid XML (CVE-2015-0851)
On Tuesday 28 July 2015 12:15:43 Ferenc Wagner wrote:
> We're already working on this with the Security Team. I wonder if I
> should prepare new packages (for {wheezy,jessie}-security) with the
> changelogs closing this bug. Or should it be closed by the unstable
> upload of 1.5.5? The proposed security uploads can be found at
> http://apt.niif.hu/CVE-2015-0851/.
Ok, just follow up with the Security Team then, they'll point you through the
correct path.
I just filed this bug today as I realized the issue has been initially labeled
with a wrong CVE and seemed to be untracked.
Cheers, Luca
--
.''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso)
: :' : The Universal O.S.| lucab (AT) debian.org
`. `'` | GPG: 0xBB1A3A854F3BBEBF
`- http://www.debian.org | Debian GNU/Linux Developer
signature.asc
Description: This is a digitally signed message part.
Bug#793759: ITP: pytoml -- A Python parser for TOML
On Monday 27 July 2015 11:06:39 Jonas Smedegaard wrote: > Quoting Luca Bruno (2015-07-27 10:17:50) > > > * Package name: pytoml > > > This project aims at being a specs-conforming and strict > > parser and writer for TOML files. > > . > > The library currently supports version 0.4.0 of the specs > > and runs with Python 2.7 and 3.4+. > > According to Debian Policy §3.4 describes how description should be > adequate for someone "who has never met it before". > > Please therefore include in long description a sentence on what that > "TOML" format is. I've expanded the long description for those packages. Source is currently sitting in NEW: https://ftp-master.debian.org/new/pytoml_0.1.2-1.html Cheers, Luca -- .''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso) : :' : The Universal O.S.| lucab (AT) debian.org `. `'` | GPG: 0xBB1A3A854F3BBEBF `- http://www.debian.org | Debian GNU/Linux Developer signature.asc Description: This is a digitally signed message part.
Bug#793855: DoS, Shibboleth SP software crashes on well-formed but invalid XML (CVE-2015-0851)
Source: xmltooling Version: 1.3.3-2 Severity: serious Tags: security patch upstream Shibboleth Service Provider software contains a code path with an uncaught exception that can be triggered by an unauthenticated attacker by supplying well-formed but schema-invalid XML in the form of SAML metadata or SAML protocol messages. The result is a crash and so causes a denial of service. Updated versions of OpenSAML-C (V2.5.5) and XMLTooling-C (V1.5.5) are available that correct this bug. This vulnerability has been assigned CVE-2015-0851. Please mention the CVE ID in changelog when fixing this issue. References: * Bulletin http://shibboleth.net/community/advisories/secadv_20150721.txt * Fixing commit (xmltooling) https://git.shibboleth.net/view/?p=cpp-xmltooling.git;a=commitdiff;h=2d795c731e6729309044607154978696a87fd900 Cheers, Luca -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#793770: Cookie parsing bug may lead to 'HttpOnly' cookie bypass (CVE-2015-2156)
Source: netty-3.9 Version: 3.9.0.Final-1 Severity: important Tags: security upstream patch LinkedIn Security Team discovered a "Cookie" header parsing bug in Netty that could lead to universal bypass of the HttpOnly flag on cookies. If the HttpOnly flag is included in the HTTP Set-Cookie response header, the cookie cannot usually be accessed through client-side script. This bug can be however leveraged to leak the cookie's name-value in the DOM, where a malicious script can access the content without any restriction. CVE-2015-2156 has been assigned for this issue, which has been fixed upstream in release 3.9.8.Final and 3.10.3.Final. Please mention the CVE ID in the changelog when fixing this issue. References: * Security update http://netty.io/news/2015/05/08/3-9-8-Final-and-3.html * Issue technical details / PoC http://engineering.linkedin.com/security/look-netty%E2%80%99s-recent-security-update-cve%C2%AD-2015%C2%AD-2156 * Fixing commit https://github.com/slandelle/netty/commit/800555417e77029dcf8a31d7de44f27b5a8f79b8 Cheers, Luca -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#793759: ITP: pytoml -- A Python parser for TOML
Package: wnpp Severity: wishlist Owner: Luca Bruno * Package name: pytoml Version : 0.1.2 Upstream Author : Martin Vejnár * URL : https://github.com/avakar/pytoml * License : MIT Programming Lang: Python Description : A TOML parser and emitter for Python This project aims at being a specs-conforming and strict parser and writer for TOML files. . The library currently supports version 0.4.0 of the specs and runs with Python 2.7 and 3.4+. This package will be maintained under the Debian Python Modules Team umbrella. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#793491: RFP: rocksdb -- A persistent key-value store for fast storage environments
Package: wnpp Severity: wishlist * Package name: rocksdb Version : 3.11.2 Upstream Author : Facebook, Inc. * URL : http://rocksdb.org/ * License : BSD-3 Programming Lang: C++ Description : A persistent key-value store for fast storage environments RocksDB is an embeddable persistent key-value store for fast storage. It can also be the foundation for a client-server database but the current focus is on embedded workloads. RocksDB can be used by applications that need low latency database accesses. This is needed as a dependency for osquery. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#793465: DoS and privilege escalation by local users (CVE-2015-3245 and CVE-2015-3246)
Source: libuser Version: 1:0.56.9.dfsg.1-1.2 Severity: grave Tags: security upstream patch During a code audit by Qualys, multiple libuser-related vulnerabilities were discovered that can allow local users to perform denial-of-service and privilege-escalation attacks: - Race condition in password file update (CVE-2015-3246, Important) A flaw was found in the way the libuser library handled the /etc/passwd file. Even though traditional programs like passwd, chfn, and chsh work on a temporary copy of /etc/passwd and eventually use the rename() function to rename the temporary copy, libuser modified /etc/passwd directly. Unfortunately, if anything went wrong during these modifications, libuser may have left/etc/passwd in an inconsistent state. This behavior could result in a local denial-of-service attack; in addition, when combined with a second vulnerability (CVE-2015-3245, described below), it could result in the escalation of privileges to the root user. - Lack of validation of GECOS field contents (CVE-2015-3245, Moderate) It was found that the chfn function of the userhelper utility did not properly filter out newline characters. The chfn function implemented by the userhelper utility verified that the fields it was given on the command line were valid (that is, contain no forbidden characters). Unfortunately, these forbidden characters (:,=) did not include the \n character and allowed local attackers to inject newline characters into the /etc/passwd file and alter this file in unexpected ways. A local attacker could use this flaw to corrupt the /etc/passwd file, which could result in a denial-of-service attack on the system. Both issues have been fixed upstream, and shipped in relase 0.62. Please mention the CVE numbers in the changelog when fixing the issue. References: * RedHat security bulletin https://access.redhat.com/articles/1537873 * PoC http://www.openwall.com/lists/oss-security/2015/07/23/16 * libuser 0.62 changelog https://fedorahosted.org/libuser/browser/NEWS?rev=libuser-0.62 * Fixing commit https://fedorahosted.org/libuser/changeset/d73aa2a5a9ce5bdd349dff46e3e4885f2b194a95/ Cheers, Luca -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#793398: Remote execution of untrusted code, DoS (CVE-2015-3253)
Package: groovy2 Version: 2.2.2+dfsg-3 Severity: grave Tags: security upstream cpnrodzc7, working with HP's Zero Day Initiative, discovered that Java applications using standard Java serialization mechanisms to decode untrusted data, and that have Groovy on their classpath, can be passed a serialized object that will cause the application to execute arbitrary code. This is issue has been marked as fixed in Groovy 2.4.4 and a standalone security patch has been made available. CVE-2015-3253 has been assigned to this issue. Please mention it in the changelog when fixing the issue. References: * Bulletin http://seclists.org/bugtraq/2015/Jul/78 * Security update http://groovy-lang.org/security.html * Fixing commit https://github.com/apache/incubator-groovy/commit/09e9778e8a33052d8c27105aee5310649637233d Cheers, Luca -- System Information: Debian Release: 8.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (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) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#793397: Remote execution of untrusted code, DoS (CVE-2015-3253)
Package: groovy Version: 1.8.6-1 Severity: grave Tags: security upstream cpnrodzc7, working with HP's Zero Day Initiative, discovered that Java applications using standard Java serialization mechanisms to decode untrusted data, and that have Groovy on their classpath, can be passed a serialized object that will cause the application to execute arbitrary code. This is issue has been marked as fixed in Groovy 2.4.4 and a standalone security patch has been made available. CVE-2015-3253 has been assigned to this issue. Please mention it in the changelog when fixing the issue. References: * Bulletin http://seclists.org/bugtraq/2015/Jul/78 * Security update http://groovy-lang.org/security.html * Fixing commit (on 2.4.x branch) https://github.com/apache/incubator-groovy/commit/09e9778e8a33052d8c27105aee5310649637233d -- System Information: Debian Release: 8.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (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) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#792064: [Pkg-javascript-devel] Bug#792064: FTBFS: tests fail with CAP_DAC_OVERRIDE and without networking
tags 792064 + fixed-upstream pending forwarded 792064 https://github.com/libuv/libuv/pull/441 thanks On Sun, 12 Jul 2015 20:02:24 +0100 solo-debianb...@goeswhere.com wrote: > > However, as this seems to be part of repro-build (which I do care about), > > you can find a patch here that should fix it. Let me know if it works. > > Woo, thanks! FYI, this has been merged upstream (both v0.10 and v1.x): https://github.com/libuv/libuv/pull/441 > > > If you have CAP_DAC_OVERRIDE (e.g. you're running the build as root), > > > > Isn't this an incredibly bad practice? > > That builder (one I'm in the middle of writing!) runs stuff as "uid 0" > inside an unprivileged LXC (i.e. in a new uid/pid/mount/... namespace), > which is (I believe) supported for security, i.e. it should be safe. > It's easy enough to flip the builder over to using a normal user > inside the container, in the future. Given the sheer number of namespace escape bugs we saw every month, I would recommend against running as uid=0 inside LXC where not strictly needed. IMHO it is still far too easy to escape to host, and builds usually do not require it. Principle of least privilege, as always. > I was under the impression that there was a policy entry requiring stuff > to be buildable as root, so I thought I'd let it run as root for now. > Otoh, I can't actually find said policy entry, nor one for requiring > packages to build without networking; perhaps the latter covered simply > by the requirement that there's no dependency on anything outside of > main. I don't have policy reference at hand, but I remember that as "never retrieve stuff from the internet". I think nowhere we mandate "build without any network interface/route". Personally, I think this one is a sensible environment to support, though. Cheers, Luca -- .''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso) : :' : The Universal O.S.| lucab (AT) debian.org `. `'` | GPG: 0xBB1A3A854F3BBEBF `- http://www.debian.org | Debian GNU/Linux Developer signature.asc Description: This is a digitally signed message part.
Bug#792064: [Pkg-javascript-devel] Bug#792064: FTBFS: tests fail with CAP_DAC_OVERRIDE and without networking
control 792064 + patch thanks On Friday 10 July 2015 20:44:25 Chris West wrote: > The package fails to build under various conditions, > including on both of the builders I care about. In general, I would say that it is not a package's fault: you can come up with many different ways to have very weird build environments, and I would go crazy trying to support them all. However, as this seems to be part of repro-build (which I do care about), you can find a patch here that should fix it. Let me know if it works. If so, I will adapt something similar to libuv1 too and send both to upstream. > If you have CAP_DAC_OVERRIDE (e.g. you're running the build as root), Isn't this an incredibly bad practice? Cheers, Luca -- .''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso) : :' : The Universal O.S.| lucab (AT) debian.org `. `'` | GPG: 0xBB1A3A854F3BBEBF `- http://www.debian.org | Debian GNU/Linux Developer signature.asc Description: This is a digitally signed message part.
Bug#791751: Please give back openldap (2.4.40+dfsg-2) on mipsel
Dear wb-team, latest openldap upload (2.4.40+dfsg-2) saw a spurious failure in its testsuite on mipsel. As diff with previous version is quite limited and failure unrelated, we suspect this was a momentary glitch somewhere. Can we please give it a second try there? gb openldap_2.4.40+dfsg-2 . mipsel Ciao, Luca -- .''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso) : :' : The Universal O.S.| lucab (AT) debian.org `. `'` | GPG: 0xBB1A3A854F3BBEBF `- http://www.debian.org | Debian GNU/Linux Developer signature.asc Description: This is a digitally signed message part.
Bug#791751: [Pkg-openldap-devel] Bug#791751: openldap: Fails to build on mipsel
On Wednesday 08 July 2015 07:45:07 Gustavo Prado Alkmim wrote: > Package is failing to build on buildd. > > Build Log tail: > > slapd-bind PID=1105: ldap_sasl_bind_s: Invalid credentials (49) > make: *** wait: No child processes. Stop. > make[3]: *** Waiting for unfinished jobs > make[3]: *** wait: No child processes. Stop. > make[2]: *** [test] Error 2 > Makefile:282: recipe for target 'test' failed > Build killed with signal TERM after 150 minutes of inactivity > I'm working on a fix and I will attach it as soon as possible. I think something glitched on the build machine. While it isn't nice, it happened once already (but on a different builder) and just giving back the package solved it. I suspect the same will apply here. Cheers, Luca -- .''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso) : :' : The Universal O.S.| lucab (AT) debian.org `. `'` | GPG: 0xBB1A3A854F3BBEBF `- http://www.debian.org | Debian GNU/Linux Developer signature.asc Description: This is a digitally signed message part.
Bug#788795: [Pkg-javascript-devel] Bug#788795: libuv: FTBFS on mipsel. Tests failed.
On Monday 15 June 2015 09:16:13 Arturo Borrero Gonzalez wrote: > As you can see on buildd [0], libuv FTBFS on mipsel due to some failed > tests. There seem to be a patch upstream to address the issue [1]. Thanks for re-sending back my own patch :) Unfortunately, as you can read in [0], [1] and [2], upstream rejected the patch and is working on something more general. As this is now taking a bit too much time, I'm inclined to add it to the debian package, as it fixes that specific regression without other failures. [0] https://github.com/libuv/libuv/issues/335 [1] https://github.com/libuv/libuv/pull/351 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787751 Cheers, Luca -- .''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso) : :' : The Universal O.S.| lucab (AT) debian.org `. `'` | GPG Key ID: 0x4F3BBEBF `- http://www.debian.org | Debian GNU/Linux Developer signature.asc Description: This is a digitally signed message part.
Bug#787751: libuv1: FTBFS - tests fail (mainly pipe_set_non_blocking)
retitle 787751 uv_loop_configure testsuite failure on mips/mipsel tags 787751 + pending upstream sid forwarded 787751 https://github.com/libuv/libuv/issues/335 severity 787751 important thanks On Friday 05 June 2015 10:53:51 Luca Bruno wrote: > Just to summarize, all build failures are known upstream and fixed except > for the mips one. Next upload should make the buildd matrix mostly green. 1.6.1-1 builds fine everywhere else, so I'm retitling this bug to track the upstream mips issue. I'm also downgrading severity, as all the other arch are green and libuv1 has never been built on mips anyway. Cheers, Luca -- .''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso) : :' : The Universal O.S.| lucab (AT) debian.org `. `'` | GPG Key ID: 0x4F3BBEBF `- http://www.debian.org | Debian GNU/Linux Developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#787751: [Pkg-javascript-devel] Bug#787751: libuv1: FTBFS - tests fail (mainly pipe_set_non_blocking)
On Friday 05 June 2015 10:43:19 Luca Bruno wrote: > > For some reason, pipe_set_non_blocking failed everywhere: > > `pipe_set_non_blocking` failed: exit code 6 > > Output from process `pipe_set_non_blocking`: > > Assertion failed in test/test-pipe-set-non-blocking.c on line 51: n == 0 > > This is new to me, instead. It was not failing on my pbuilder one month ago, > but I will retry now. We are now also lagging a couple of versions behind, > so it may have been fixed/reported in the meanwhile. > > I'll try to dig a bit in the history and see if 1.5.0/1.6.0 fail too. Confirmed, this is upstream #248 and has been fixed in 1.50: https://github.com/libuv/libuv/issues/248 Just to summarize, all build failures are known upstream and fixed except for the mips one. Next upload should make the buildd matrix mostly green. Cheers, Luca -- .''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso) : :' : The Universal O.S.| lucab (AT) debian.org `. `'` | GPG Key ID: 0x4F3BBEBF `- http://www.debian.org | Debian GNU/Linux Developer signature.asc Description: This is a digitally signed message part.
Bug#787751: [Pkg-javascript-devel] Bug#787751: libuv1: FTBFS - tests fail (mainly pipe_set_non_blocking)
On Thursday 04 June 2015 13:25:49 Aaron M. Ucko wrote: > The automated builds of libuv1 all failed with test suite errors. Thanks for the detailed report. > In addition, loop_configure failed with no explanation on mips and mipsel: > > `loop_configure` failed: exit code 6 > Output from process `loop_configure`: (no output) This is upstream #335, I tracked down the origin of this (bad parameter to epoll_pwait) and had a minimal patch, but upstream prefers to go for full fix/rewrite, so we are still waiting for the final commit: https://github.com/libuv/libuv/issues/335 > Worse yet, most tests failed on arm64, in many cases reporting > timeouts: This is upstream #334, patched in github for both v0.10 and v1: https://github.com/libuv/libuv/issues/334 > For some reason, pipe_set_non_blocking failed everywhere: > > `pipe_set_non_blocking` failed: exit code 6 > Output from process `pipe_set_non_blocking`: > Assertion failed in test/test-pipe-set-non-blocking.c on line 51: n == 0 This is new to me, instead. It was not failing on my pbuilder one month ago, but I will retry now. We are now also lagging a couple of versions behind, so it may have been fixed/reported in the meanwhile. I'll try to dig a bit in the history and see if 1.5.0/1.6.0 fail too. Regards, Luca -- .''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso) : :' : The Universal O.S.| lucab (AT) debian.org `. `'` | GPG Key ID: 0x4F3BBEBF `- http://www.debian.org | Debian GNU/Linux Developer signature.asc Description: This is a digitally signed message part.
Bug#786836: packaging not yet ready for mass/stable usage
Source: rustc Version: 1.0.0+dfsg1-1 Severity: serious Even though Rust recently reached the 1.0 milestone, compiler and ecosystem packaging still has to reach a "ready for the masses" status. As some bits are still missing (cargo, external libs) and other still under discussion (dynlibs, lang-extensions), this bug is left open in order to avoid a premature migration to testing. -- System Information: Debian Release: 8.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (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) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#784692: release-notes: package maradns is not updated, it has been removed
On Thu, 7 May 2015 21:53:34 +0200 Christian Garbs wrote: > I have not yet found out why maradns has been removed and I don't know > if it could perhaps show up again with the next point release, but for > now the listing of maradns in the table of the updated packages should > be removed. I'm in no way involved in this, but just for the sake of information it was autoremoved on 07/02/2015 due to RC bug #774874, see https://packages.qa.debian.org/m/maradns/news/20150207T163914Z.html It surely won't show up in further jessie point releases, but if you need it you can ask the maintainer (Dariusz CCed here) to upload 2.0.09-4 into jessie-backports. Cheers, Luca -- .''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso) : :' : The Universal O.S.| lucab (AT) debian.org `. `'` | GPG Key ID: 0x4F3BBEBF `- http://www.debian.org | Debian GNU/Linux Developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#758310: libuv-dev: Current debian libuv version makes NeoVim compilation fail
tags 758310 + pending thanks On Mon, 20 Apr 2015 13:20:09 -0400 James McCoy wrote: > As Luca points out, this is due to NeoVim requiring a newer version of > libuv, so I'm going to change this bug accordingly to request updating > to the current stable upstream release. libuv upstream decided to maintain two active branches alive at the same time. Given the soname bump (libuv0.10 -> libuv1), it is my understanding that neovim wants libuv1. libuv1 has just been uploaded to sid, but given the length of the NEW queue at this moment, it may take some time before hitting the archive: https://ftp-master.debian.org/new/libuv1_1.4.2-1.html If you want to start building/testing your neovim package, you can build yourself current libuv1 (1.4.2-1) from git: http://anonscm.debian.org/cgit/pkg-javascript/libuv1.git Cheers, Luca -- .''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso) : :' : The Universal O.S.| lucab (AT) debian.org `. `'` | GPG Key ID: 0x4F3BBEBF `- http://www.debian.org | Debian GNU/Linux Developer signature.asc Description: This is a digitally signed message part.
Bug#779840: [Pkg-haproxy-maintainers] Bug#779840: Include patch against rand()
On 05/03/2015 14:51, Vincent Bernat wrote: > Unfortunately, to be backported to Wheezy, the patch should be in > Jessie. And to be in Jessie, we need a freeze exception which is > granted only for serious bugs (since January 5th). I think that such a > patch is quite unlikely to satisfy the current criteria and would be > rejected by the release team. Ok right didn't think about the jessie freeze. It could be applied to unstable thought right? Best regards, -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#779840: Include patch against rand()
Package: haproxy Version: 1.5.8 I'd like to request this upstream commit [0] to be included in debian haproxy and hopefully be backported to wheezy. The rand() function in the config is otherwise completely broken. The rand() function [1] is supposed to give random numbers between 0 and . Without this patch, it gives random numbers between 0 and /2. For example, rand(1000) will never give numbers above 500, hence rand(2) will always give 0. I've locally built haproxy from the debian package with this patch as last in the quilt series, it applies cleanly and works as expected. Best regards, [0] https://github.com/haproxy/haproxy/commit/1228dc0e7ae4a6b16c0c7f74a28f8e84601b526c [1] http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#7.3.2-rand
Bug#779266: unblock: libuv/0.10.28-6
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package libuv
Latest upload (0.10.28-6) is a minimal update fixing security
bug #779173 (CVE-2015-0278).
Debdiff attached.
unblock libuv/0.10.28-6
-- System Information:
Debian Release: 8.0
APT prefers testing
APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (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)
diff -Nru libuv-0.10.28/debian/changelog libuv-0.10.28/debian/changelog
--- libuv-0.10.28/debian/changelog 2014-09-21 14:52:46.0 +0200
+++ libuv-0.10.28/debian/changelog 2015-02-25 11:03:04.0 +0100
@@ -1,3 +1,10 @@
+libuv (0.10.28-6) unstable; urgency=high
+
+ * Backported: call setgroups before calling setuid/setgid
+(Closes: #779173 - CVE-2015-0278)
+
+ -- Luca Bruno Wed, 25 Feb 2015 10:50:58 +0100
+
libuv (0.10.28-5) unstable; urgency=medium
* Too early for versioned provides, reverted
diff -Nru libuv-0.10.28/debian/patches/series libuv-0.10.28/debian/patches/series
--- libuv-0.10.28/debian/patches/series 2014-09-20 23:24:57.0 +0200
+++ libuv-0.10.28/debian/patches/series 2015-02-25 10:41:19.0 +0100
@@ -2,3 +2,4 @@
make-clean.diff
test_runner.diff
arm64-epoll-ftbfs.diff
+setgroups_CVE-2015-0278.diff
diff -Nru libuv-0.10.28/debian/patches/setgroups_CVE-2015-0278.diff libuv-0.10.28/debian/patches/setgroups_CVE-2015-0278.diff
--- libuv-0.10.28/debian/patches/setgroups_CVE-2015-0278.diff 1970-01-01 01:00:00.0 +0100
+++ libuv-0.10.28/debian/patches/setgroups_CVE-2015-0278.diff 2015-02-25 10:40:02.0 +0100
@@ -0,0 +1,46 @@
+From 2773e1181dfb1e10fc2e3bfd3ffd83c71b730408 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Sa=C3=BAl=20Ibarra=20Corretg=C3=A9?=
+Date: Mon, 10 Feb 2014 17:41:51 +0100
+Subject: [PATCH] unix: call setgoups before calling setuid/setgid
+
+Backported from v1.x (66ab389)
+
+PR-URL: https://github.com/libuv/libuv/pull/215
+Reviewed-By: Ben Noordhuis
+---
+ src/unix/process.c | 15 +++
+ 1 file changed, 15 insertions(+)
+
+diff --git a/src/unix/process.c b/src/unix/process.c
+index 19686a2..d1f9440 100644
+--- a/src/unix/process.c
b/src/unix/process.c
+@@ -40,6 +40,10 @@
+ extern char **environ;
+ #endif
+
++#ifdef __linux__
++# include
++#endif
++
+
+ static ngx_queue_t* uv__process_queue(uv_loop_t* loop, int pid) {
+ assert(pid > 0);
+@@ -331,6 +335,17 @@ static void uv__process_child_init(uv_process_options_t options,
+ _exit(127);
+ }
+
++ if (options.flags & (UV_PROCESS_SETUID | UV_PROCESS_SETGID)) {
++/* When dropping privileges from root, the `setgroups` call will
++ * remove any extraneous groups. If we don't call this, then
++ * even though our uid has dropped, we may still have groups
++ * that enable us to do super-user things. This will fail if we
++ * aren't root, so don't bother checking the return value, this
++ * is just done as an optimistic privilege dropping function.
++ */
++SAVE_ERRNO(setgroups(0, NULL));
++ }
++
+ if ((options.flags & UV_PROCESS_SETGID) && setgid(options.gid)) {
+ uv__write_int(error_fd, errno);
+ _exit(127);
Bug#776991: slapd: crash in valueReturnFilter cleanup
On Tue, 3 Feb 2015 12:38:39 -0800 Ryan Tandy wrote: > Bill MacAllister discovered that certain queries cause slapd to crash > while freeing operation controls. Details to follow. I've some problems in understanding this comment from upstream bug report: > The system exhibiting this problem was running a beta release of > 2.4.40. When I installed from a build of the current stable the > problem disappeared. Apologies for the bother, I didn't realize > the system had not been updated. > > I think that documenting the query would be useful anyway, but I > want to hold off on that because I know the problem exists in the > build that is in debian backports. I would like to give Ryan a > chance to fix it before I publish it. I was able to reproduce the > problem with ldapsearch and it is a trival and very effective > denial of service attack. Is it something that we introduced with our patching? Where did he get a beta release of 2.4.40? Does "a build of current stable" mean 2.4.31-1+nmu2 from wheezy or some upstream version he built? In the last paragraph, is he implying that he is unable to reproduce the bug with vanilla openldap? Cheers, Luca -- .''`. | ~<[ Luca BRUNO ~ (kaeso) ]>~ : :' : | Email: lucab (AT) debian.org ~ Debian Developer `. `'` | GPG Key ID: 0x3BFB9FB3 ~ Free Software supporter `-| HAM-radio callsign: IZ1WGT ~ Networking sorcerer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#776311: nginx: Please add nginx-http-shibboleth to nginx-extras
Source: nginx Severity: wishlist Tags: patch Hi, we recently did some work to make shibboleth being independent of apache. Current shibboleth package can be used to authenticate whatever server, over a fastcgi socket. The other half missing is some support into nginx. Unfortunately upstream nginx does not support fastcgi authorizers, and shibboleth has some quirks by itself so there is an external dedicated module for this at: https://github.com/nginx-shib/nginx-http-shibboleth Can you please add it to nginx-extras? Attached is a patch against current debian packaging to include and build the module, update the copyright and the modules README. I'd be happy to see this reaching debian once we un-freeze post-jessie. Cheers, Luca -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (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) commit 57212a99e9363e95e420542c4bd2e7645189d30e Author: Luca Bruno Date: Mon Jan 26 12:13:42 2015 +0100 nginx-extras: add nginx-http-shibboleth module diff --git a/debian/changelog b/debian/changelog index e5efd5b..6cd36fe 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,6 +1,6 @@ nginx (1.6.2-6) UNRELEASED; urgency=medium - [Michael Lustfield] + [ Michael Lustfield ] * debian/conf/sites-available/default: + Add comment about disabling gzip in HTTPS. (Closes: #773332) + Add comment about checking ssl_ciphers. (Closes: #765782) @@ -17,6 +17,10 @@ nginx (1.6.2-6) UNRELEASED; urgency=medium * debian/ngx-conf/* + Added configuration utility. (Closes: #652108) + [ Luca Bruno ] + * debian/rules: ++ Added shibboleth authorizer module to nginx-extras. + -- Michael Lustfield Sun, 11 Jan 2015 14:49:36 -0600 nginx (1.6.2-5) unstable; urgency=medium diff --git a/debian/copyright b/debian/copyright index 9b123d1..c454376 100644 --- a/debian/copyright +++ b/debian/copyright @@ -89,6 +89,13 @@ Files: debian/modules/ngx_http_substitutions_filter_module/* Copyright: Copyright (C) 2014 by Weibin Yao License: BSD-2-clause +Files: debian/modules/nginx-http-shibboleth/* +Copyright: 2013, Maxim Dounin + 2013, Nginx, Inc. + 2013-2015, David Beitey (davidjb) + 2014-2015, Luca Bruno +License: BSD-2-clause + Files: debian/* Copyright: 2007-2009, Fabio Tranchitella 2008, Jose Parrella diff --git a/debian/modules/README.Modules-versions b/debian/modules/README.Modules-versions index d4bd95c..4b7a7f2 100644 --- a/debian/modules/README.Modules-versions +++ b/debian/modules/README.Modules-versions @@ -55,3 +55,7 @@ README for Modules versions ngx_http_substitutions_filter_module Homepage: https://github.com/yaoweibin/ngx_http_substitutions_filter_module Version: v0.6.4 + + nginx-http-shibboleth + Homepage: https://github.com/nginx-shib/nginx-http-shibboleth + Version: v20150121 diff --git a/debian/modules/nginx-http-shibboleth/CONFIG.rst b/debian/modules/nginx-http-shibboleth/CONFIG.rst new file mode 100644 index 000..c87020e --- /dev/null +++ b/debian/modules/nginx-http-shibboleth/CONFIG.rst @@ -0,0 +1,329 @@ +Configuration += + +.. contents:: + :local: + :backlinks: none + +Steps +- + +#. Obtain/rebuild Shibboleth SP with FastCGI support. +#. Recompile Nginx with the ``nginx-http-shibboleth`` custom module. +#. Configure Shibboleth FastCGI authorizer and reponsder applicatons to run. +#. Configure Nginx to talk to both FastCGI authorizer and responder. +#. Configure your Nginx application ``location`` block with ``shib_request + on``. +#. Configure Shibboleth's ``shibboleth2.xml`` so the authorizer and responder are + aware of which paths to protect. +#. Ensure your application code accepts the relevant incoming headers for + authN/authZ. + +Background +-- + +Shibboleth supports Apache and IIS by default, but not Nginx. The closest one +gets to support is via FastCGI, which Shibboleth `does have +<https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPFastCGIConfig>`_ +but the default distribution needs to be rebuilt to support it. Nginx has +support for FastCGI responders, but not for `FastCGI authorizers +<http://www.fastcgi.com/drupal/node/22#S6.3>`_. This current module, +``nginx-http-shibboleth``, bridges this gap using sub-requests within Nginx. + +The design of Nginx is such that when handling sub-requests, it currently +cannot forward the original request body, and likewise, cannot pass a +sub-request response back to the client. As such, this module does not fully +comply with the FastCGI authorizer specification. However, for Shibboleth, +these two factors are inconsequential as only HTTP redirections and HTTP +headers (cooki
Bug#775559: gnupg2: New default hashing (SHA256) signing fails with cryptostick/nitrokey (storage version)
Package: gnupg2 Version: 2.0.26-4 Severity: important With the latest gnupg2 package targeted for the Jessie, defaulting hashing algorithm has been changed to SHA256. This broke my smartcard setup using a cryptostick/nitrokey (storage version, latest 0.18 firmware) as signing now fails with: $ gpg --armor -s pippo.txt gpg: sending command `SCD PKSIGN' to agent failed: ec=6.32817 gpg: signing failed: general error gpg: signing failed: general error After that, scdaemon and/or gpg-agent got really confused and I have to replug the dongle to get it working again. I saw that switching back the default hashing algorithm to SHA1 works, so for the time being I have to use the following line in my gpg.conf: personal-digest-preferences SHA1 I'm not sure if it is a firmware or gnupg2 bug, as such I'm also CC:ing nitrokey makers (Jan and George) here. My current setup is with 3x4096 keys on the dongle, and I'm experiencing this failure both with scdaemon and pcscd. When signing fails, I see the following in my scdaemon debug log: scdaemon[7609]: chan_10 -> OK GNU Privacy Guard's Smartcard server ready scdaemon[7609]: chan_7 <- SETDATA D4C076C2A0E30219D4631EDF85E8844C41EA950A8549D0B3A7BD4D18D550CD8A scdaemon[7609]: chan_7 -> OK scdaemon[7609]: chan_10 <- SERIALNO scdaemon[7609]: chan_10 -> S SERIALNO 0 scdaemon[7609]: chan_10 -> OK scdaemon[7609]: chan_7 <- PKSIGN --hash=sha256 / 2015-01-17 12:21:02 scdaemon[7609] DBG: send apdu: c=00 i=CA p1=00 p2=6E lc=-1 le=256 em=0 2015-01-17 12:21:02 scdaemon[7609] DBG: response: sw=9000 datalen=217 2015-01-17 12:21:02 scdaemon[7609] DBG: send apdu: c=00 i=CA p1=00 p2=7A lc=-1 le=256 em=0 2015-01-17 12:21:02 scdaemon[7609] DBG: response: sw=9000 datalen=5 2015-01-17 12:21:02 scdaemon[7609] signatures created so far: 261 2015-01-17 12:21:02 scdaemon[7609] DBG: asking for PIN '||Please enter the PIN%0A[sigs done: 261]' scdaemon[7609]: chan_7 -> INQUIRE NEEDPIN ||Please enter the PIN%0A[sigs done: 261] scdaemon[7609]: chan_10 <- GETATTR APPTYPE scdaemon[7609]: chan_10 -> S APPTYPE OPENPGP scdaemon[7609]: chan_10 -> OK scdaemon[7609]: chan_7 <- [ XX XX XX ...(76 byte(s) skipped) ] scdaemon[7609]: chan_7 <- END 2015-01-17 12:21:07 scdaemon[7609] DBG: send apdu: c=00 i=20 p1=00 p2=81 lc=6 le=-1 em=0 2015-01-17 12:21:07 scdaemon[7609] DBG: raw apdu: 00 20 00 81 06 31 34 30 37 32 32 2015-01-17 12:21:07 scdaemon[7609] DBG: response: sw=9000 datalen=0 2015-01-17 12:21:07 scdaemon[7609] DBG: dump: 2015-01-17 12:21:07 scdaemon[7609] DBG: send apdu: c=00 i=2A p1=9E p2=9A lc=51 le=2048 em=1 2015-01-17 12:21:30 scdaemon[7609] ccid_transceive failed: (0x1000a) 2015-01-17 12:21:30 scdaemon[7609] apdu_send_simple(0) failed: card I/O error 2015-01-17 12:21:30 scdaemon[7609] operation sign result: Input/output error 2015-01-17 12:21:30 scdaemon[7609] app_sign failed: Input/output error scdaemon[7609]: chan_7 -> ERR 100696113 Input/output error (I removed some raw apdu data dumps, as I'm not sure about leaking data). Some comments: * Looking at the timestamp, once can see a few seconds gap and then the scdaemon declaring I/O error; in that meanwhile, I see the activity led on the dongle staying "fixed on red" and turning off only few seconds after. Some timeout too short? * I see a response with datalen=0, but I don't know the protocol. Maybe something went wrong there? * Using SHA1, operation succeeds and the dongle response apdu is "response: sw=9000 datalen=511" I'm filing this here as cryptostick/nitrokey users may find it non-working out of the box in Debian Jessie, while for it was ok until the last week. Just to be clear, above workaround works and I'm not suggesting to revert the default. However, I would like to see this properly fixed. @Jan, George: can you reproduce this? If not, I'm currently based in Berlin and I'll be glad to meet to help inspecting this. Cheers, Luca -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (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 gnupg2 depends on: ii dpkg 1.17.23 ii gnupg-agent 2.0.26-4 ii install-info 5.2.0.dfsg.1-6 ii libassuan0 2.1.2-2 ii libbz2-1.0 1.0.6-7+b2 ii libc62.19-13 ii libcurl3-gnutls 7.38.0-4 ii libgcrypt20 1.6.2-4+b1 ii libgpg-error01.17-3 ii libksba8 1.3.2-1 ii libreadline6 6.3-8+b3 ii zlib1g 1:1.2.8.dfsg-2+b1 Versions of packages gnupg2 recommends: ii libldap-2.4-2 2.4.40-3 Versions of packages gnupg2 suggests: pn gnupg-doc pn parcimonie pn xloadimage -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas..
Bug#773341: [Pkg-javascript-devel] Bug#773341: libuv: link against -pthread to fix underlinking issues
On Wednesday 17 December 2014 02:54:05 Logan Rosen wrote: > Although this isn't causing an FTBFS in Debian, as we use different linker > flags, it is probably a good idea to apply this fix here as well in case > Debian switches to ld --as-needed in the future. Thanks a lot for your report and your patch. As it is directly touching original Makefile and as upstream is usually quite fast in reviewing/merging patches, can you please submit it directly as a PR against the v0.10 branch there? https://github.com/libuv/libuv Cheers, Luca -- .''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso) : :' : The Universal O.S.| lucab (AT) debian.org `. `'` | GPG Key ID: 0x4F3BBEBF `- http://www.debian.org | Debian GNU/Linux Developer signature.asc Description: This is a digitally signed message part.
Bug#614569: [Pkg-openldap-devel] Bug#614569: RFS: Bug#614569: slapd fails to dump/reload partial replica -- NMU sponsor needed
On Wednesday 03 December 2014 18:21:08 Ryan Tandy wrote: > On Wed, Dec 03, 2014 at 11:40:24PM +0100, Ferenc Wagner wrote: > >I got pre-approval on #771962: the upload will be unblocked, provided > >it's in unstable by Monday the 8th of December. People with upload > >rights, if you can spare a minute please review the above change and > >consider sponsoring the upload! Actually, review is welcome from > >anybody. :) > > Thanks very much for working on this, and the debdiff looks fine (but I > haven't actually built or tested it). I hope you can find a sponsor in > time. Luca, are you reading? I was following the discussion, and I have to say that I am not too comfortable in uploading this NMU at this point of the release cycle. So NACK on my side. My main concerns are: * I am not sure that I grok all the implications of that. I suspect that most of our (overly) complex pre/postinst scripts makes some assumption on schema/db consistency, at least implicitly. * We are changing the default behavior to fix a single-case situation, by removing a safety check. Mmmh... * This bug has been open since some time, never marked as RC, put on low-priority by the maintainer and upstream discouraged dropping the "-s". * This is not even the proper solution, just a quick-hack patch. Moreover, I don't consider myself an LDAP expert, but I have some comments on the issue: * I would say that requiring/checking schema integrity across upgrade is a good general measure, and we should NOT work around that. Fail early, fail loudly. * IIRC disabling schemachecking is heavily discouraged. We don't offer that option in debconf. I assume the admin are really aware of the setup, and know its quirk. * Workarounds for the specific corner case exists, but maybe are a bit undocumented. So my alternative suggestion is: let's make it explicit that we value schema integrity, and we rely on it across upgrades; let's put a point in the release notes to document how to workaround this partial replica scenario; let's try to address this better in the next point release. Cheers, Luca -- .''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso) : :' : The Universal O.S.| lucab (AT) debian.org `. `'` | GPG Key ID: 0x4F3BBEBF `- http://www.debian.org | Debian GNU/Linux Developer signature.asc Description: This is a digitally signed message part.
Bug#771067: librarian-puppet: Please upgrade to latest upstream version (2.0.0 now)
Package: librarian-puppet Severity: wishlist Hi, it looks like upstream is steadily releasing new version, both minors and majors. While I understand that it is difficult to keep up with this flow, I'd really like to use some of the new features (--puppetfile and --path). Can you please proceed with newer upstream versions? Cheers, Luca -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#758600: shibboleth-sp2-utils: postinst fails on initial installation
On Monday 10 November 2014 09:06:34 Russ wrote: > I'll try to take a look, but I no longer use Shibboleth and handed the > package maintenance off. Copying the general mailing list. Sorry then, I CC'd you explicitly as you did the backport, with additional changes over the plain jessie package, and are still listed as an Uploader. On Monday 10 November 2014 13:38:35 Sam Hartman wrote: > I'd like to better understand the severity issue. > Are you saying that there's no order I can install shibboleth and apache > in wheezy that will work? > I.E. even if I manually install the module first? No, I suspect there clearly are ways to express the dependency and some install-order to satisfy it. I've raised the severity because this package's postinst fails due to a non- declared dependency. Additionally, this package is not providing the apache module and the daemon should not require apache2 to be installed at all. So IMHO the missing/hypothetical dependency is also incorrect. While I see the benefit of autoloading the apache module, I think that this package SHOULD NOT gain a hard-dependency on apache2+mod_shib2, but opt instead for a conditional a2enmod in postinst. As I said, I'm exploring a nginx+shibboleth path, which I expect to be supported by the split-packaging setup currently in backport. Just my 2c, though, as I'm still new to the shibboleth world. Cheers, Luca -- .''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso) : :' : The Universal O.S.| lucab (AT) debian.org `. `'` | GPG Key ID: 0x4F3BBEBF `- http://www.debian.org | Debian GNU/Linux Developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#758600: shibboleth-sp2-utils: postinst fails on initial installation
severity 758600 serious thanks On Tue, 19 Aug 2014 09:58:47 +0300 Mika Tiainen wrote: > Installing libapache2-mod-shib2 from wheezy backports. shibboleth-sp2-utils > postinst fails on initial installation, because it tries to enable the > apache module, but libapache2-mod-shib2 is not yet configured so > /etc/apache2/mods-available/ contains only shib2.load.dpkg-new. It also looks like it is missing some dependencies. In short, I'm trying to use shibboleth without apache (via nginx), but the backported package assumes that apache2 is installed (thus a2enmod available). Installation then fails as follow: > apt-get install -t wheezy-backports shibboleth-sp2-common > shibboleth-sp2-utils libshibsp6 liblog4shib1 libsaml8 > opensaml2-schemas libshibsp-plugins > [...] > /var/lib/dpkg/info/shibboleth-sp2-utils.postinst: 24: > /var/lib/dpkg/info/shibboleth-sp2-utils.postinst: a2enmod: not found > dpkg: error processing shibboleth-sp2-utils (--configure): > subprocess installed post-installation script returned error exit status 127 > Errors were encountered while processing: > shibboleth-sp2-utils > E: Sub-process /usr/bin/dpkg returned an error code (1) I'm raising the severity of this, since the backported package is currently unusable in this case, due to the hard-coupled implicit dependency on Apache. Russ, can you please revert/modify your a2enmod changes for the ~bpo revision? I'd like to use the daemon part of shibboleth-sp2-utils in a standalone way, and vanilla package from jessie seems to be better in that regard. Cheers, Luca -- .''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso) : :' : The Universal O.S.| lucab (AT) debian.org `. `'` | GPG Key ID: 0x4F3BBEBF `- http://www.debian.org | Debian GNU/Linux Developer signature.asc Description: This is a digitally signed message part.
Bug#648331: additional UDEV rule to support Crypto Stick
On Thu, 10 Nov 2011 16:27:23 +0100 Crypto Stick
wrote:
> The Crypto Stick is an open source USB device which contains the
> OpenPGP Card and hence is fully compatible and tested with GnuPG.
> Currently users still need to add an UDEV rule manually to use the
> Crypto Stick with GnuPG. To make it easier for users the appropriate
> UDEV rule should be added by default to /lib/udev/rules.d/60-gnupg.rules
>
> The following rule works as a separate file but I guess it is
> sufficient to only incorporate the second last line to the gnupg rules.
>
> SUBSYSTEM!="usb", GOTO="cryptostick_rules_end"
> ACTION!="add", GOTO="cryptostick_rules_end"
> ATTR{idVendor}=="20a0", ATTR{idProduct}=="4107",
> ENV{ID_SMARTCARD_READER}="1", ENV{ID_SMARTCARD_READER_DRIVER}="gnupg"
> LABEL="cryptostick_rules_end"
This has been opened some time ago, it would be great to have it properly in
place for Jessie. Can you please upload a minor revision with the udev ruleset
for cryptostick? Do you need git-packaging patch for it?
As per newer instructions (https://www.crypto-stick.com/en/installation), the
updated ruleset is now at:
https://www.assembla.com/spaces/cryptostick/documents/dRVoF4H5yr44oXacwqEsg8/download/dRVoF4H5yr44oXacwqEsg8
Thanks, Luca
--
.''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso)
: :' : The Universal O.S.| lucab (AT) debian.org
`. `'` | GPG Key ID: 0x4F3BBEBF
`- http://www.debian.org | Debian GNU/Linux Developer
signature.asc
Description: This is a digitally signed message part.
Bug#754678: openocd: FTBFS on kfreebsd-*: configure: error: libusb-1.x is required for the MPSSE mode of FTDI based devices
On Monday 20 October 2014 17:31:48 Paul Fertser wrote: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=22;filename=openocd.log. > > gz;att=1;bug=754678> > > | Altera USB-Blaster II Compatibleyes (auto) > > I see the source of the confusion now. There're two versions of USB > Blaster, the first one is still widely available (and requires > libftdi), the second (depends onl libusb) is slowly gaining popularity > (clk frequency control is yet to be implemented, currently it might be > too high for many targets). I see. So in the end, let's keep: * libusb autodetection for kfreebsd * --enable-usb_blaster_libftdi for linux Cheers, Luca signature.asc Description: This is a digitally signed message part.
Bug#754678: openocd: FTBFS on kfreebsd-*: configure: error: libusb-1.x is required for the MPSSE mode of FTDI based devices
On Mon, 20 Oct 2014 07:26:20 +0400 Paul Fertser wrote: > On Sun, Oct 19, 2014 at 10:45:17PM +0100, Steven Chamberlain wrote: > > If you want something equivalent to Linux libusb 1.0 API, I think you > > need to Build-Depend on libusb2-dev [kfreebsd-any] rather than libusb-dev. > > Right, libusb-0.1 API is still needed for some older drivers, but it > is provided by libusb2-dev on kfreebsd, libusb-dev shouldn't be used > there. My fault, I got really confused in all this libusb* mess. I will apply your patch as-is and upload a -4. > > Dropping libftdi-dev from Build-Depends on kfreebsd-amd64, I actually > > get a successful build; how does that work? Does MPSSE mode not need > > ftdi.h any more? If so, libftdi-dev can be dropped from Build-Depends > > on linux, too. But I have no way of testing openocd. > > MPSSE mode depends only on libusb-1, however, there're three other > drivers (USB Blaster, ASIX Presto, OpenJTAG; USB Blaster being really > important here) plus legacy ft2232 implementation that need > libftdi-dev. If I'm not wrong: * usb-blaster support is autodetected * presto and openjtag should be explicitely enabled (currently aren't) * we don't currently explicitly enable any legacy ft2232 So the above patch should be ok. I'm just slightly confused about usb-blaster on kfreebsd, which seems to have been autoenabled even though libftdi-dev was missing. Cheers, Luca signature.asc Description: This is a digitally signed message part.
Bug#746727: #746727 slapd: Please include slapd-sha2 contrib module
Hi all, as a sidenote, pw-pbkdf2 currently uses openssl EVP module to perform hashing and verification (via PKCS5_PBKDF2_HMAC_SHA1). We are currently building against gnutls, so this requires an appropriate amount of #ifdef and gnutls support before it could be shipped. Cheers, Luca signature.asc Description: This is a digitally signed message part.
Bug#762300: [Pkg-javascript-devel] Bug#762300: libuv: Versioned provides not supported during upgrades
Niels Thykier ha scritto: > Your package (libuv0.10-dev) uses versioned provides. Unfortunately, > this feature is not supported by tools in stable. Accordingly, it is > not guaranteed to work during upgrades from Wheezy to Jessie. As libuv has never been part of a stable release, I quickly concluded that there wouldn't be any problems related to upgrades (as there shouldn't exist an upgrade path!). After some input by the release team, I just realized that in fact the apt-get in stable is not capable of parsing versioned provides, so the upgrade process would break as soon as receiving the new package list. I will revert ASAP back to unversioned provide, I'd just like to see the result from arm64 autobuilder (if it doesn't take too long). Sorry for causing havoc, and thanks for catching it quickly before migration. Ciao, Luca -- .''`. | ~<[ Luca BRUNO ~ (kaeso) ]>~ : :' : | Email: lucab (AT) debian.org ~ Debian Developer `. `'` | GPG Key ID: 0x3BFB9FB3 ~ Free Software supporter `-| HAM-radio callsign: IZ1WGT ~ Networking sorcerer signature.asc Description: PGP signature
Bug#759673: Forwarded upstream
tags 759673 + upstream forwarded 759673 https://github.com/joyent/libuv/issues/1442 thanks Patch forwarded upstream, thanks. If you are a github user, you may even consider to submit a PR there to speed-up the review and merging process. Cheers, Luca -- .''`. | ~<[ Luca BRUNO ~ (kaeso) ]>~ : :' : | Email: lucab (AT) debian.org ~ Debian Developer `. `'` | GPG Key ID: 0x3BFB9FB3 ~ Free Software supporter `-| HAM-radio callsign: IZ1WGT ~ Networking sorcerer signature.asc Description: PGP signature
Bug#650501: slapd headers status
Hi, I’m currently dealing with an OpenLDAP password checker, which builds as an external module. It currently needs two include files, portable.h and slap.h, which are not shipped by any package. It is my understanding that those file were once provided by a libslapd2.3-dev package, which doesn’t exist anymore. However, git history[0] didn’t tell me the reason behind its removal, and a bug is currently open to have it back (#650501). Somebody who is more knowledgeable about this, can please tell me: * why was it removed? * can we start providing again those headers? looking at the bug, there are several people needing it. * should a separate libslapd2-dev be reintroduced, or can they be shipped in private subdirectories of libldap2-dev? * is portable.h really a private header? From a quick glance, it looks like a global header inside include/, but I noticed that several files from there are not installed. [0] http://anonscm.debian.org/cgit/pkg-openldap/openldap.git/commit/debian/control?id=7a9ad38eac2a4aec87dc8b61bfec56fcd43ff9a7 Cheers, Luca signature.asc Description: Message signed with OpenPGP using GPGMail
Bug#754756: [Pkg-javascript-devel] Bug#754756: libuv: FTBFS on kfreebsd-amd64: test suite issues
Jérémy Lal ha scritto: > I suspect the problem isn't with libuv per se, rather with the tests > themselves. Either that, or something more complex in the libc/kernel path. > Can you identify a list of the tests that occasionally > fail on kfreebsd ? Some culprits in the past have been: * poll_duplex * poll_unidirectional * hrtime * fs_event_watch_file_current_dir * ipc_listen_before_write * threadpool_cancel_work However it is difficult to see a pattern, as even between minor debian revisions the results are different. > Some libuv/nodejs tests fail when the environment is slow/under high > load... I would expect to see timeouts in those cases (as opposed to hard failures), but it could as well be the case. Also some quirkiness in the host-side of the builders, which are still running kernel 9.0. In all these cases, it may make sense to avoid failing on test-suite failure on !linux. Are you ok with that? Cheers, Luca -- .''`. | ~<[ Luca BRUNO ~ (kaeso) ]>~ : :' : | Email: lucab (AT) debian.org ~ Debian Developer `. `'` | GPG Key ID: 0x3BFB9FB3 ~ Free Software supporter `-| HAM-radio callsign: IZ1WGT ~ Networking sorcerer signature.asc Description: PGP signature
Bug#757735: gtk-gnutella: Segfault at start
Package: gtk-gnutella Version: 1.1.0-1 Followup-For: Bug #757735 Oddly enough, the same (optimized) package works fine when built with clang (3.4.2-6). According to autobuilders log, the faulty gcc in use was 4.9.1-1. As a workaround, I can either: * Force building with gcc-4.8 (haven't tried yet) * Force building with clang * Drop optimization level for xmalloc.c I would be still great to pinpoint the gcc bug, if somebody has time for bin-diffing the two executable and reduce the test-case. Cheers, Luca -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gtk-gnutella depends on: ii binutils 2.24.51.20140727-1 ii libatk1.0-0 2.12.0-1 ii libc62.19-7 ii libcairo21.12.16-2 ii libdbus-1-3 1.8.6-1 ii libfontconfig1 2.11.0-5 ii libfreetype6 2.5.2-1.1 ii libgdk-pixbuf2.0-0 2.30.7-1 ii libglib2.0-0 2.40.0-4 ii libgnutls26 2.12.23-17 ii libgtk2.0-0 2.24.24-1 ii libpango-1.0-0 1.36.3-1 ii libpangocairo-1.0-0 1.36.3-1 ii libpangoft2-1.0-01.36.3-1 ii zlib1g 1:1.2.8.dfsg-1 gtk-gnutella recommends no packages. gtk-gnutella suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#758310: libuv-dev: Current debian libuv version makes NeoVim compilation fail
Package: libuv-dev Version: 0.10.28-1 Followup-For: Bug #758310 neovim should better check (maybe through pkg-config) which version of libuv it is building against. Debian is currently only shipping the stable branch 0.10, while from your report I seem to understand that neovim is instead using the 0.11 development branch. Please note that 0.11 is just a stabilizing branch for the forthcoming 0.12, and both are not API compatible with 0.10. As it involves a soname bump and a new packages through NEW, the experimental 0.11 will never be part debian. However, the 0.12 release is approaching [0] and there are plans to have both 0.10 and 0.12 versions shipped with jessie [1]. Cheers, Luca [0] https://groups.google.com/forum/#!topic/libuv/dRmWltlIDXU [1] https://groups.google.com/forum/#!topic/libuv/WgESkNMAhxc -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libuv-dev depends on: ii libuv0.10 0.10.25-1 libuv-dev recommends no packages. libuv-dev suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
