Bug#1036350: O: gcc-msp430 -- GNU C compiler (cross compiler for MSP430)

[Luca BRUNO]

> 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

[Luca BRUNO]

> 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

[Luca BRUNO]

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

[Luca BRUNO]

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

[Luca BRUNO]

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

[Luca BRUNO]

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

[Luca BRUNO]

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

[Luca BRUNO]

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

[Luca Bruno]

Package: ftp.debian.org
Severity: normal

Bug#860116: [Pkg-rust-maintainers] Bug#860116: RFH: cargo -- Rust package manager

[Luca BRUNO]

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)

[Luca BRUNO]

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]

[Luca BRUNO]

On Thursday, 17 November 2016 08:56:54 UTC Arturo Borrero Gonzalez wrote:
> On 17 November 2016 at 04:15, Ryan Tandy <r...@nardis.ca> 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

[Luca BRUNO]

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

[Luca BRUNO]

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

[Luca BRUNO]

1.13.0+dfsg-1 has been built without issues on i386:
https://buildd.debian.org/status/fetch.php?pkg=rkt=i386=1.13.0%2Bdfsg-1=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

[Luca BRUNO]

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

[Luca BRUNO]

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

[Luca BRUNO]

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

[Luca BRUNO]

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

[Luca BRUNO]

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

[Luca BRUNO]

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)

[Luca BRUNO]

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

[Luca BRUNO]

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

[Luca BRUNO]

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

[Luca BRUNO]

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

[Luca BRUNO]

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

[Luca BRUNO]

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”

[Luca BRUNO]

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

[Luca BRUNO]

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

[Luca Bruno]

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

[Luca BRUNO]

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

[Luca BRUNO]

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

[Luca BRUNO]

severity 815364 important
tags + 815364 pending
thanks

On Thu, 13 Aug 2015 23:55:59 +0200 Moritz Muehlenhoff <j...@debian.org> 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

[Luca BRUNO]

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

[Luca Bruno]

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

[Luca BRUNO]

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 <mich...@pbandjelly.org> 
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

[Luca BRUNO]

> On Tue, 01 Sep 2015 10:48:28 +0200 Ferenc Wagner <wf...@niif.hu> 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

[Luca BRUNO]

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

[Luca Bruno]

Package: wnpp
Severity: wishlist
Owner: Luca Bruno <lu...@debian.org>

* 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#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

[Luca BRUNO]

On Mon, 28 Dec 2015 23:14:03 + Chris Lamb <la...@debian.org> 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#809316: [Pkg-rust-maintainers] Bug#809316: rustc: Support of arm archs

[Luca BRUNO]

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#808576: [Pkg-rust-maintainers] Bug#808576: rustc cannot compile programs: "unrecognized relocation in section"

[Luca Bruno]

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#808576: [Pkg-rust-maintainers] Bug#808576: rustc cannot compile programs: "unrecognized relocation in section"

[Luca Bruno]

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#786836: [Pkg-rust-maintainers] Bug#786836: packaging not yet ready for mass/stable usage

[Luca Bruno]

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

[Luca Bruno]

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

[Luca Bruno]

Package: ftp.debian.org
Severity: normal

Bug#805817: Should instanbul be removed?

[Luca Bruno]

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#805669: ksplice: FTBFS: x86_64-linux-gnu-gcc: error: /usr/lib/libbfd.a: No such file or directory

[Luca Bruno]

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#733295: gnutls-bin: please compile GnuTLS with DANE support

[Luca Bruno]

On Tue, 24 Mar 2015 23:11:51 +0100 Cyril Brulebois <k...@debian.org> 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

[Luca Bruno]

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

[Luca Bruno]

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

[Luca Bruno]

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

[Luca Bruno]

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, , 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(...)]

[Luca Bruno]

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

[Luca Bruno]

On Tue, 25 Aug 2015 19:10:50 +0200 Michael Biebl <bi...@debian.org> 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

[Luca Bruno]

On Tue, 25 Aug 2015 18:41:59 +0200 Luca Bruno lethalma...@gmail.com 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

[Luca Bruno]

Control: unarchive -1

On Thu, 12 Feb 2015 15:43:30 +0100 Martin Pitt mp...@debian.org 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=experimentalid=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

[Luca Bruno]

Package: wnpp
Severity: wishlist

* Package name: libtoml-perl
  Version : 0.96
  Upstream Author : Darren Chamberlain dar...@cpan.org 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

[Luca Bruno]

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)

[Luca Bruno]

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#793759: ITP: pytoml -- A Python parser for TOML

[Luca Bruno]

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)

[Luca Bruno]

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

[Luca Bruno]

Package: wnpp
Severity: wishlist
Owner: Luca Bruno lu...@debian.org

* 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#793770: Cookie parsing bug may lead to 'HttpOnly' cookie bypass (CVE-2015-2156)

[Luca Bruno]

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#793465: DoS and privilege escalation by local users (CVE-2015-3245 and CVE-2015-3246)

[Luca Bruno]

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#793491: RFP: rocksdb -- A persistent key-value store for fast storage environments

[Luca Bruno]

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#793397: Remote execution of untrusted code, DoS (CVE-2015-3253)

[Luca Bruno]

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#793398: Remote execution of untrusted code, DoS (CVE-2015-3253)

[Luca Bruno]

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#792064: [Pkg-javascript-devel] Bug#792064: FTBFS: tests fail with CAP_DAC_OVERRIDE and without networking

[Luca Bruno]

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

[Luca Bruno]

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: [Pkg-openldap-devel] Bug#791751: openldap: Fails to build on mipsel

[Luca Bruno]

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#791751: Please give back openldap (2.4.40+dfsg-2) on mipsel

[Luca Bruno]

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#788795: [Pkg-javascript-devel] Bug#788795: libuv: FTBFS on mipsel. Tests failed.

[Luca Bruno]

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)

[Luca Bruno]

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)

[Luca Bruno]

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)

[Luca Bruno]

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

[Luca Bruno]

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

[Luca Bruno]

On Thu, 7 May 2015 21:53:34 +0200 Christian Garbs deb...@cgarbs.de 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

[Luca Bruno]

tags 758310 + pending
thanks

On Mon, 20 Apr 2015 13:20:09 -0400 James McCoy james...@debian.org 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()

[Luca Bruno]

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()

[Luca Bruno]

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(range) function [1] is supposed to give random numbers
between 0 and range. Without this patch, it gives random numbers
between 0 and range/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

[Luca Bruno]

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 lu...@debian.org  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?= sag...@gmail.com
+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 i...@bnoordhuis.nl
+---
+ 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 grp.h
++#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

[Luca BRUNO]

On Tue, 3 Feb 2015 12:38:39 -0800 Ryan Tandy r...@nardis.ca 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

[Luca Bruno]

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 lu...@debian.org
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 mich...@lustfield.net  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 yaowei...@gmail.com
 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 kob...@debian.org
2008,  Jose Parrella joseparre...@cantv.net
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

Bug#775559: gnupg2: New default hashing (SHA256) signing fails with cryptostick/nitrokey (storage version)

[Luca Bruno]

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 MY_SERIALNO 0
scdaemon[7609]: chan_10 - OK
scdaemon[7609]: chan_7 - PKSIGN --hash=sha256 MY_SERIALNO/MY_SIGNING_KEYID
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 SCD

(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   none
pn  parcimonie  none
pn  xloadimage  none

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of 

Bug#773341: [Pkg-javascript-devel] Bug#773341: libuv: link against -pthread to fix underlinking issues

[Luca Bruno]

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

[Luca Bruno]

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)

[Luca Bruno]

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

[Luca Bruno]

severity 758600 serious
thanks

On Tue, 19 Aug 2014 09:58:47 +0300 Mika Tiainen mi...@iki.fi 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#758600: shibboleth-sp2-utils: postinst fails on initial installation

[Luca Bruno]

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#648331: additional UDEV rule to support Crypto Stick

[Luca Bruno]

On Thu, 10 Nov 2011 16:27:23 +0100 Crypto Stick webmas...@crypto-stick.com 
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#746727: #746727 slapd: Please include slapd-sha2 contrib module

[Luca Bruno]

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#754678: openocd: FTBFS on kfreebsd-*: configure: error: libusb-1.x is required for the MPSSE mode of FTDI based devices

[Luca Bruno]

On Mon, 20 Oct 2014 07:26:20 +0400 Paul Fertser fercer...@gmail.com 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#754678: openocd: FTBFS on kfreebsd-*: configure: error: libusb-1.x is required for the MPSSE mode of FTDI based devices

[Luca Bruno]

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#762300: [Pkg-javascript-devel] Bug#762300: libuv: Versioned provides not supported during upgrades

[Luca BRUNO]

Niels Thykier ni...@thykier.net 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

[Luca BRUNO]

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

[Luca Bruno]

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#758405: Please upgrade and sync with upstream version (now at 1.0.13)

[Luca Bruno]

Source: libusb2-dev
Severity: normal

Hi,
the current version of this package as reported by pkg-config is too
old for some packages depending on it (eg. openocd[0])

$ pkg-config --modversion libusb-1.0
1.0.6

Upstream is currently shipping with 1.0.13[1], and openocd requires at least
1.0.9. Can you please sync with upstream and provide a .pc = 1.0.9?

Thanks, Luca

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754678
[1] http://svnweb.freebsd.org/base/head/lib/libusb/libusb-1.0.pc?view=log

-- 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


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#754678: openocd: FTBFS on kfreebsd-*: configure: error: libusb-1.x is required for the MPSSE mode of FTDI based devices

[Luca Bruno]

Package: openocd
Version: 0.8-1
Followup-For: Bug #754678

This is because openocd needs libusb-1.0 = 1.0.9, while the one 
provided by libusb2-dev on kfreebsd-* reports itself as 1.0.6 in 
pkg-config.
I've filled a bug asking kfreebsd porters to sync lib version 
with upstream.

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


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#756889: openocd: USB 0403:6001 incorrectly assigned to plugdev; is FTDI serial converter

[Luca Bruno]

Package: openocd
Followup-For: Bug #756889

 Product:Vendor 0403:6001 is incorrectly assigned to plugdev by openocd udev 
 rules.
 This is in fact a generic FTDI serial convert product:vendor and as such 
 should be
 assigned to 'dialout' as with all other ttyUSB devices.

I'm sorry but it has in fact a wider scope and I don't feel like removing those 
rules 
from openocd udev file.

Currently, openocd is changing group for all the following generic FTDI devices:

0403  Future Technology Devices International, Ltd
6001  FT232 USB-Serial (UART) IC
6010  FT2232C Dual USB-UART/FIFO IC
6011  FT4232H Quad HS USB-UART/FIFO IC
6014  FT232H Single HS USB-UART/FIFO IC


While I agree that it is unfortunate that some JTAG adapters abuse the generic 
PID,
I think that it is safe to say that these devices are generic enough to be owned
by the plugdev group vs. the really specific dialout.

Other rules-files seem to agree with me, and for example
/lib/udev/rules.d/77-mm-usb-serial-adapters-greylist.rules says:

# FTDI-based serial adapters
#   FTDI does USB to serial converter ICs; and it's very likely that they'll
#   never do modems themselves, so it should be safe to add a rule only based
#   on the vendor Id.
ATTRS{idVendor}==0403, ENV{ID_MM_DEVICE_MANUAL_SCAN_ONLY}=1


Thus, I'm inclined to mark this bug as wontfix and keep the status-quo.

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


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org