Bug#1015080: irssi-plugin-robustirc: FTBFS: robustsession.c:599:25: error: ‘G_INPUT_READ’ undeclared (first use in this function); did you mean ‘I_INPUT_READ’?
I fixed the compilation issue with
https://github.com/robustirc/irssi-robustirc/commit/a89d711914cc852c7135bd8f822bbd0a4e16829a
upstream, but the plugin itself doesn’t actually work, at least not with
irssi 1.4.2.
When I last tried to use this plugin a few months ago by installing it from
Debian, it wouldn’t work either (mismatching ABI between irssi and the
plugin), but there never have been any user bug reports about this.
Given the low user interest and breakage that is not currently planned to
be fixed upstream (
https://github.com/robustirc/irssi-robustirc/commit/6c5a9d01f61dac8698cd993c44b525c5246c4890),
I think it would be best to remove this package from Debian entirely.
On Sat, 16 Jul 2022 at 16:02, Lucas Nussbaum wrote:
> Source: irssi-plugin-robustirc
> Version: 0.6-4
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20220716 ftbfs-bookworm
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
>
> Relevant part (hopefully):
> > cd /<>/obj-x86_64-linux-gnu/src/core && /usr/bin/cc
> -DUOFF_T_LONG -Drobustirc_core_EXPORTS -I/usr/include/yajl
> -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/glib-2.0
> -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/<>/src/core
> -I/<>/src/core/robustsession -I/<>/src/fe-common
> -I/usr/include/irssi -I/usr/include/irssi/src
> -I/usr/include/irssi/src/fe-common/core -I/usr/include/irssi/src/core
> -I/usr/include/irssi/src/irc/core -g -O2
> -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat
> -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wextra
> -fPIC -pthread -std=gnu99 -MD -MT
> src/core/CMakeFiles/robustirc_core.dir/robustsession/robustsession.c.o -MF
> CMakeFiles/robustirc_core.dir/robustsession/robustsession.c.o.d -o
> CMakeFiles/robustirc_core.dir/robustsession/robustsession.c.o -c
> /<>/src/core/robustsession/robustsession.c
> > /<>/src/core/robustsession/robustsession.c: In function
> ‘get_messages_timeout’:
> > /<>/src/core/robustsession/robustsession.c:268:17: warning:
> unused variable ‘server’ [-Wunused-variable]
> > 268 | SERVER_REC *server = request->server;
> > | ^~
> > /<>/src/core/robustsession/robustsession.c: In function
> ‘socket_recv_cb’:
> > /<>/src/core/robustsession/robustsession.c:543:34: warning:
> unused parameter ‘data’ [-Wunused-parameter]
> > 543 | static void socket_recv_cb(void *data, GIOChannel *source, int
> condition) {
> > |~~^~~~
> > /<>/src/core/robustsession/robustsession.c:543:64: warning:
> unused parameter ‘condition’ [-Wunused-parameter]
> > 543 | static void socket_recv_cb(void *data, GIOChannel *source, int
> condition) {
> > |
> ^
> > /<>/src/core/robustsession/robustsession.c: In function
> ‘socket_callback’:
> > /<>/src/core/robustsession/robustsession.c:595:26: warning:
> implicit declaration of function ‘g_io_channel_new’; did you mean
> ‘i_io_channel_new’? [-Wimplicit-function-declaration]
> > 595 | GIOChannel *handle = g_io_channel_new(s);
> > | ^~~~
> > | i_io_channel_new
> > /<>/src/core/robustsession/robustsession.c:595:26: warning:
> initialization of ‘GIOChannel *’ {aka ‘struct _GIOChannel *’} from ‘int’
> makes pointer from integer without a cast [-Wint-conversion]
> > /<>/src/core/robustsession/robustsession.c:599:25: error:
> ‘G_INPUT_READ’ undeclared (first use in this function); did you mean
> ‘I_INPUT_READ’?
> > 599 | condition = G_INPUT_READ;
> > | ^~~~
> > | I_INPUT_READ
> > /<>/src/core/robustsession/robustsession.c:599:25: note:
> each undeclared identifier is reported only once for each function it
> appears in
> > /<>/src/core/robustsession/robustsession.c:602:25: error:
> ‘G_INPUT_WRITE’ undeclared (first use in this function); did you mean
> ‘I_INPUT_WRITE’?
> > 602 | condition = G_INPUT_WRITE;
> > | ^
> > | I_INPUT_WRITE
> > /<>/src/core/robustsession/robustsession.c:608:11: warning:
> implicit declaration of function ‘g_input_add’; did you mean ‘i_input_add’?
> [-Wimplicit-function-declaration]
> > 608 | *id = g_input_add(handle, condition, socket_recv_cb, NULL);
> > | ^~~
> > | i_input_add
> > /<>/src/core/robustsession/robustsession.c:575:34: warning:
> unused parameter ‘easy’ [-Wunused-parameter]
> > 575 | static int socket_callback(CURL *easy, curl_socket_t s, int
> what, void *userp, void *socketp) {
> > |~~^~~~
> > /<>/src/core/robustsession/robustsession.c:575:73: warning:
> unused parameter ‘userp’ [-Wunused-parameter]
> > 575 | static int socket_callback(CURL *easy, curl_socket_t s, int
> what, void *userp, void *socketp
Bug#983010: mdocml breaks debiman autopkgtest: different output
Agreed, the test seems too brittle. Can we just turn the test off for now? https://github.com/Debian/debiman/issues/127 tracks updating mdocml on manpages.d.o, which I intend to do as time permits. I wonder whether it makes sense to have debiman packaged in Debian itself, though. Personally, I’m not maintaining that package, and I’m not sure if there are any users of the package. Anyway, any help welcome to sort this out on the package level. I don’t have time to help, sorry: https://michael.stapelberg.ch/posts/2019-03-10-debian-winding-down/ On Tue, Feb 23, 2021 at 12:45 PM Ivo De Decker wrote: > Control: reassign -1 debiman 0.0~git20200217.fc82521-1 > > Hi, > > On Thu, Feb 18, 2021 at 07:31:32AM +0100, Paul Gevers wrote: > > With a recent upload of mdocml the autopkgtest of debiman fails in > > testing when that autopkgtest is run with the binary packages of mdocml > > from unstable. It passes when run with only packages from testing. In > > tabular form: > > [...] > > > === CONT TestToHTML/i3lock > > convert_test.go:92: unexpected conversion result: (diff from want → > > got): > > --- /tmp/debiman-8492488252021-02-18 04:13:33.034473409 + > > +++ /tmp/debiman-3766921622021-02-18 04:13:33.034473409 + > > @@ -7,67 +7,76 @@ > > > > > > > > - > > - > > + > > + > > + > [...] > > Hard-coding the exact html output of a dependency that generates html, and > expecting that not to change doesn't seem like a robust way to test it > functionality, so I think it's clear that the bug is in the autopkgtest of > debiman. It's perfectly acceptable for mdocml to generate different html > output to represent the data (whether the upload of the new upstream > version > should have happened during the soft freeze is a different matter, but > that's > unrelated to this bug). > > Testing that the html is valid, and contains certain parts of the input > might > be a more useful test. > > Cheers, > > Ivo > -- Best regards, Michael
Bug#969254: i3-save-tree: Can't locate AnyEvent/I3.pm in @INC (you may need to install the AnyEvent::I3 module)
control: severity -1 normal The i3-wm package recommends libanyevent-i3-perl: https://packages.debian.org/bullseye/i3-wm I have verified that in a clean debian:sid Docker container, running “apt update && apt install i3” results in installing libanyevent-i3-perl, so I think this situation is specific to your system somehow. Maybe you have disabled installation of recommended packages in apt at some point? In any case, install the package and things should start working. On Sun, Aug 30, 2020 at 10:27 AM xiscu wrote: > > Package: i3 > Version: 4.18-1 > Severity: grave > Justification: renders package unusable > > Dear Maintainer, > I wanted to save/restore the layout used in workspace 1 and tested, following > as on: > > https://i3wm.org/docs/layout-saving.html (and man i3-save-tree) > > But I get: > ~> i3-save-tree --workspace 1 > ~/.i3/ws1.json > Can't locate AnyEvent/I3.pm in @INC (you may need to install the AnyEvent::I3 > module) > (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.30.3 > /usr/local/share/perl/5.30.3 /usr/lib/x86_64-linux-gnu/perl5/5.30 > /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base > /usr/lib/x86_64-linux-gnu/perl/5.30 /usr/share/perl/5.30 > /usr/local/lib/site_perl) > at /usr/bin/i3-save-tree line 19. > BEGIN failed--compilation aborted at /usr/bin/i3-save-tree line 19. > > the file is created but is empty. > > Shouldn't the dependencies to run that command be installed? > otherwise IMHO the command isn't as usefull as it promisses. > Or what I'm missing or doing wrong? > > Let me know if some information is needed. > > Thanks in advance! > xiscu > > -- System Information: > Debian Release: bullseye/sid > APT prefers testing > APT policy: (900, 'testing'), (10, 'unstable'), (1, 'experimental') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.7.0-2-amd64 (SMP w/4 CPU threads) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), > LANGUAGE=en_US:en > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages i3 depends on: > ii i3-wm 4.18-1 > > Versions of packages i3 recommends: > pn dunst > ii i3lock 2.11.1-1 > ii i3status2.13-3 > ii suckless-tools 45-1 > > i3 suggests no packages. > > -- no debconf information -- Best regards, Michael -- Best regards, Michael
Bug#921351: [pkg-go] Bug#921351: prometheus-postfix-exporter: Init script missing
On Thu, Feb 7, 2019 at 8:46 AM Scott Kitterman wrote: > No. It's an actual policy violation, so the bug is correct. I'd leave it > as is and ask the release team to mark it buster-ignore. > Could you kindly point me to where the process is described for this? I’m not sure what I’d need to do to get it marked buster-ignore. Thanks. > > Scott K > > On February 7, 2019 7:29:01 AM UTC, Michael Stapelberg < > stapelb...@debian.org> wrote: > >On Wed, Feb 6, 2019 at 11:01 PM Scott Kitterman > >wrote: > > > >> It's not the FTP Team's job to fix policy compliance issues in > >packages. > >> If you have a problem with that being a policy must, then you should > >take > >> it up with the policy team. > >> > > > >Yeah, I’ll post to #911165 > > > > > >> > >> I completely understand the frustration, but in my own packages I > >take the > >> time to do it because Debian policy says it's required, not because I > >> particularly care about sysvinit. > >> > > > >I don’t think fulfilling the policy for fulfilling the policy’s sake is > >a > >good use of anyone’s time. > > > >Can we close this bug until someone comes along who actually cares? :) > > > > > >> > >> Scott K > >> > >> On February 6, 2019 9:23:46 PM UTC, Michael Stapelberg < > >> stapelb...@debian.org> wrote: > >> >Can you provide a patch if you care about sysvinit please? The Go > >> >packaging > >> >team is pretty manpower-constrained and non-systemd is a niche case, > >so > >> >any > >> >help is appreciated. Thanks! > >> > > >> >On Wed, Feb 6, 2019 at 7:49 PM Scott Kitterman > > > >> >wrote: > >> > > >> >> Package: prometheus-postfix-exporter > >> >> Version: 0.1.2-1 > >> >> Severity: serious > >> >> Justification: Policy 9.11 > >> >> > >> >> Excerpt from policy 9.11: > >> >> > >> >> However, any package integrating with other init systems > >> >> must also be backwards-compatible with sysvinit by providing a > >SysV- > >> >> style init script with the same name as and equivalent > >functionality > >> >> to any init-specific job, as this is the only start-up > >configuration > >> >> method guaranteed to be supported by all init implementations. > >> >> > >> >> The package violates a policy must by not providing s sysvint init > >> >script. > >> >> > >> >> Scott K > >> >> > >> >> ___ > >> >> Pkg-go-maintainers mailing list > >> >> pkg-go-maintain...@alioth-lists.debian.net > >> >> > >> > > >> > > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers > >> > -- Best regards, Michael
Bug#921351: [pkg-go] Bug#921351: prometheus-postfix-exporter: Init script missing
On Wed, Feb 6, 2019 at 11:01 PM Scott Kitterman wrote: > It's not the FTP Team's job to fix policy compliance issues in packages. > If you have a problem with that being a policy must, then you should take > it up with the policy team. > Yeah, I’ll post to #911165 > > I completely understand the frustration, but in my own packages I take the > time to do it because Debian policy says it's required, not because I > particularly care about sysvinit. > I don’t think fulfilling the policy for fulfilling the policy’s sake is a good use of anyone’s time. Can we close this bug until someone comes along who actually cares? :) > > Scott K > > On February 6, 2019 9:23:46 PM UTC, Michael Stapelberg < > stapelb...@debian.org> wrote: > >Can you provide a patch if you care about sysvinit please? The Go > >packaging > >team is pretty manpower-constrained and non-systemd is a niche case, so > >any > >help is appreciated. Thanks! > > > >On Wed, Feb 6, 2019 at 7:49 PM Scott Kitterman > >wrote: > > > >> Package: prometheus-postfix-exporter > >> Version: 0.1.2-1 > >> Severity: serious > >> Justification: Policy 9.11 > >> > >> Excerpt from policy 9.11: > >> > >> However, any package integrating with other init systems > >> must also be backwards-compatible with sysvinit by providing a SysV- > >> style init script with the same name as and equivalent functionality > >> to any init-specific job, as this is the only start-up configuration > >> method guaranteed to be supported by all init implementations. > >> > >> The package violates a policy must by not providing s sysvint init > >script. > >> > >> Scott K > >> > >> ___ > >> Pkg-go-maintainers mailing list > >> pkg-go-maintain...@alioth-lists.debian.net > >> > > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers > -- Best regards, Michael
Bug#921351: [pkg-go] Bug#921351: prometheus-postfix-exporter: Init script missing
Can you provide a patch if you care about sysvinit please? The Go packaging team is pretty manpower-constrained and non-systemd is a niche case, so any help is appreciated. Thanks! On Wed, Feb 6, 2019 at 7:49 PM Scott Kitterman wrote: > Package: prometheus-postfix-exporter > Version: 0.1.2-1 > Severity: serious > Justification: Policy 9.11 > > Excerpt from policy 9.11: > > However, any package integrating with other init systems > must also be backwards-compatible with sysvinit by providing a SysV- > style init script with the same name as and equivalent functionality > to any init-specific job, as this is the only start-up configuration > method guaranteed to be supported by all init implementations. > > The package violates a policy must by not providing s sysvint init script. > > Scott K > > ___ > Pkg-go-maintainers mailing list > pkg-go-maintain...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers -- Best regards, Michael
Bug#911180: [Pkg-freeradius-maintainers] Bug#911180: freeradius: freeradius refuses to start - missing libs
control: reassign -1 freeradius-dhcp
control: severity -1 important
(Downgrading severity because this only affects installations which have
the optional freeradius-dhcp package installed and enabled.)
Dimitri, this is a result of your change
https://salsa.debian.org/freeradius-team/freeradius/commit/1fad1d069a8148c5c640157147f4ad1b111ca919.
Could you revert it for the time being, and, if you chose to go forward
with a fix, outline the rationale? The commit only describes the what, not
the why. Specifically, in which way was the rpath “bogus”?
Also, while at it, could you please ensure that
https://salsa.debian.org/freeradius-team/freeradius is in sync with what’s
in the archive? Your NMU is not reflected in the changelog, for example :-/
Thanks!
On Tue, Oct 16, 2018 at 10:09 PM Kamil Jonca wrote:
> Package: freeradius
> Version: 3.0.16+dfsg-4.1+b1
> Severity: grave
> Justification: renders package unusable
>
> After upgrade, freeradius refuses to start.
> In its log we can see:
>
> Tue Oct 16 21:59:52 2018 : Error:
> /etc/freeradius/3.0/mods-enabled/dhcp[18]: Failed to link to module
> 'rlm_dhcp': libfreeradius-dhcp.so: cannot open shared object file: No such
> file or directory
>
> bug is mysterious because:
> [from /etc/freeradius/3.0/radiusd.conf]
> libdir = /usr/lib/freeradius/
>
> #ls -la /usr/lib/freeradius/rlm_dhcp*
> -rw-r--r-- 1 root root 14344 Oct 13 06:49 /usr/lib/freeradius/rlm_dhcp.so
>
>
> moreover (I do not know if it is important)
> #ldd /usr/lib/freeradius/rlm_dhcp.so
> linux-vdso.so.1 (0x7fff15dcc000)
> libfreeradius-dhcp.so => not found
> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f4c96b7a000)
> /lib64/ld-linux-x86-64.so.2 (0x7f4c96d78000)
>
>
> -- System Information:
> Debian Release: buster/sid
> APT prefers unstable
> APT policy: (500, 'unstable'), (500, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores)
> Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8),
> LANGUAGE=pl_PL.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages freeradius depends on:
> ii freeradius-common 3.0.16+dfsg-4.1
> ii freeradius-config 3.0.16+dfsg-4.1+b1
> ii libc6 2.27-6
> ii libcap21:2.25-1.2
> ii libct4 1.00.82-2+b1
> ii libfreeradius3 3.0.16+dfsg-4.1+b1
> ii libgdbm6 1.18-2
> ii libpam0g 1.1.8-3.8
> ii libpcre3 2:8.39-11
> ii libperl5.265.26.2-7+b1
> ii libreadline7 7.0-5
> ii libsqlite3-0 3.25.2-1
> ii libssl1.1 1.1.1-1
> ii libtalloc2 2.1.14-1
> ii libwbclient0 2:4.8.5+dfsg-1
> ii lsb-base 9.20170808
>
> Versions of packages freeradius recommends:
> ii freeradius-utils 3.0.16+dfsg-4.1+b1
>
> Versions of packages freeradius suggests:
> pn freeradius-krb5
> ih freeradius-ldap3.0.16+dfsg-4.1+b1
> pn freeradius-mysql
> ih freeradius-postgresql 3.0.16+dfsg-4.1+b1
> pn freeradius-python2
> ii snmp 5.7.3+dfsg-3
>
> -- Configuration Files:
> /etc/default/freeradius changed:
> FREERADIUS_OPTIONS="-xxx -l /var/log/freeradius/radius.log"
>
> /etc/logrotate.d/freeradius changed:
> /var/log/freeradius/*.log {
> weekly
> compress
> delaycompress
> notifempty
> missingok
> postrotate
> /etc/init.d/freeradius reload > /dev/null
> endscript
> }
>
>
> -- no debconf information
>
> ___
> Pkg-freeradius-maintainers mailing list
> pkg-freeradius-maintain...@alioth-lists.debian.net
>
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-freeradius-maintainers
>
--
Best regards,
Michael
Bug#905104: [pkg-go] Bug#905104: ratt fails with "Could not find InRelease file for unstable."
I think you’re missing a deb-src entry for unstable in your sources.list. On Tue, Jul 31, 2018 at 12:17 PM, Jörg Frings-Fürst wrote: > Package: ratt > Version: 0.0~git20160202.0.a14e2ff-1+b3 > Severity: grave > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Hi, > > if I run ratt I get allways: > > [quote] > $ ratt ../sane-backends/sane-backends_1.0.27-1~ > experimental6_source.changes > 2018/07/31 12:06:06 Loading changes file "../sane-backends/sane- > backends_1.0.27-1~experimental6_source.changes" > 2018/07/31 12:06:06 - 4 binary packages: sane-utils libsane-common > libsane1 > libsane-dev > 2018/07/31 12:06:06 - corresponding .debs (will be injected when > building): > 2018/07/31 12:06:07 Could not find InRelease file for unstable. Are you > missing > unstable in your /etc/apt/sources.list? > [/quote] > > Unstable is in my sources.list. > > [quote] > $ cat /etc/apt/sources.list > # > > # deb cdrom:[Debian GNU/Linux jessie-DI-b1 _Jessie_ - Official Snapshot > amd64 > NETINST Binary-1 20140812-10:58]/ jessie main > > # deb cdrom:[Debian GNU/Linux jessie-DI-b1 _Jessie_ - Official Snapshot > amd64 > NETINST Binary-1 20140812-10:58]/ jessie main > > deb http://mirror.1und1.de/debian/ buster main non-free contrib > deb-src http://mirror.1und1.de/debian/ buster main non-free contrib > > deb http://security.debian.org/ buster/updates main non-free contrib > deb-src http://security.debian.org/ buster/updates main non-free contrib > > # stretch-updates, previously known as 'volatile' > deb http://mirror.1und1.de/debian/ buster-updates main non-free contrib > deb-src http://mirror.1und1.de/debian/ buster-updates main non-free > contrib > > # stretch-backports, previously on backports.debian.org > # deb http://mirror.1und1.de/debian/ stretch-backports main non-free > contrib > # deb-src http://mirror.1und1.de/debian/ stretch-backports main non-free > contrib > > unstable # > deb http://mirror.1und1.de/debian unstable main contrib non-free > > # experimental # > deb http://mirror.1und1.de/debian experimental main contrib non-free > deb http://deb.debian.org/debian/ buster main non-free contrib > [/quote] > > > > And the InRelease file exists. > > [quote]$ ls -l /var/lib/apt/lists/*InRelease > - -rw-r--r-- 1 root root 149528 Jul 31 10:36 > /var/lib/apt/lists/deb.debian.org_debian_dists_buster_InRelease > - -rw-r--r-- 1 root root 3561 Jul 31 03:55 > /var/lib/apt/lists/josm.openstreetmap.de_apt_dists_alldist_InRelease > - -rw-r--r-- 1 root root 149528 Jul 31 10:36 > /var/lib/apt/lists/mirror.1und1.de_debian_dists_buster_InRelease > - -rw-r--r-- 1 root root 47567 Jul 31 10:35 > /var/lib/apt/lists/mirror.1und1.de_debian_dists_buster-updates_InRelease > - -rw-r--r-- 1 root root 101329 Jul 31 10:35 > /var/lib/apt/lists/mirror.1und1.de_debian_dists_experimental_InRelease > - -rw-r--r-- 1 root root 232649 Jul 31 10:37 > /var/lib/apt/lists/mirror.1und1.de_debian_dists_unstable_InRelease > - -rw-r--r-- 1 root root 4487 Jul 20 12:20 > /var/lib/apt/lists/repo.skype.com_deb_dists_stable_InRelease > - -rw-r--r-- 1 root root 38336 Jul 30 03:32 > /var/lib/apt/lists/security.debian.org_dists_buster_updates_InRelease > - -rw-r--r-- 1 root root 9282 Jun 20 10:26 /var/lib/apt/lists/wire- > app.wire.com_linux_debian_dists_stable_InRelease > [/quote] > > CU > Jörg > > > > - -- System Information: > Debian Release: buster/sid > APT prefers testing > APT policy: (500, 'testing'), (300, 'unstable'), (1, 'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 4.17.0-1-amd64 (SMP w/6 CPU cores) > Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), > LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages ratt depends on: > ii libc6 2.27-5 > > ratt recommends no packages. > > ratt suggests no packages. > > - -- no debconf information > > -BEGIN PGP SIGNATURE- > > iQIzBAEBCgAdFiEEY+AHX8jUOrs1qzDuCfifPIyh0l0FAltgNzgACgkQCfifPIyh > 0l1/CBAA1fkPG20J2nwrutybSkF74FGOEQ2avTGcM0KJYHuDtw6MWIM+0elhqRmL > 6MWz0C/Mu06+dV35w6mypEbbIK6pzbr7iZ/MtbpDZZjXaT2YKRRsy8QY4g8vchJ7 > k7fkBfCvCfafKwbsZr7/0Kt1FOcxKZoJ1M417Hv/Oe105U9u5ilEbW6EbXnEKbay > 6PldlmM3/y2/99JJGN+Xe6P7jxJTcrQR9omcDJTOXTYctSuCRVe5kQB3+s27GDBt > IqfPRPBz33ojUFbAZzK2s8OYcLfRvKdrUUtoC1Vdxpzhf79E778VsV4z7TguybU9 > rq4l/E7gTUhsxj7MDVxEus7x9DVEmGpTp+2M5s96e9ODzmIBpmFQzo2xoAqZH41X > YYKx4IEu6rMq1L6D5ZamluRzp/a0Ur8lWu7hEUPrVRirqGd+6Yrw/q2Jk+Su6mn/ > MYTN+ev/4VMP19cCRJkaZKOv0RQ+DHNgQcgB+/1xLnVoBa4p8rA+Y0h64DO+vKyK > 4ErTR5oD+xtIYYSoXXciZnR9sdWvBfBw3JH30SWvxR+PFPD4Y5hYilIc3IvEdbDY > RxovOwkvDKLIfIIDExfIlmhkPx982kfiMzxCOD03abLN+GSA+xI/3PV3aACEBYL/ > bCbwsblqKel3OxXcIwEZSTlnRipwXW+BG0mzJY0pl5Dh4DXk9PQ= > =bMK6 > -END PGP SIGNATURE- > ___ > Pkg-go-maintainers mailing list > pkg-go-maintain...@alioth-lists.debian.net > https://alioth-lists.debian
Bug#901626: libtomcrypt: CVE-2018-12437
Filed https://github.com/libtom/libtomcrypt/issues/407, let’s see when upstream comes up with a patch. On Fri, Jun 15, 2018 at 9:22 PM, Salvatore Bonaccorso wrote: > Source: libtomcrypt > Version: 1.18.1-1 > Severity: grave > Tags: security upstream > > Hi, > > The following vulnerability was published for libtomcrypt. > > CVE-2018-12437[0]: > | LibTomCrypt through 1.18.1 allows a memory-cache side-channel attack on > | ECDSA signatures, aka the Return Of the Hidden Number Problem or ROHNP. > | To discover an ECDSA key, the attacker needs access to either the local > | machine or a different virtual machine on the same physical host. > > If you fix the vulnerability please also make sure to include the > CVE (Common Vulnerabilities & Exposures) id in your changelog entry. > > For further information see: > > [0] https://security-tracker.debian.org/tracker/CVE-2018-12437 > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-12437 > > Please adjust the affected versions in the BTS as needed. > > Regards, > Salvatore > -- Best regards, Michael
Bug#893577: sbuild-debian-developer-setup: Should not rely on files in /usr/share/doc
josch, could you let me know whether the attached patch does what you have
in mind please? Thanks!
On Tue, Mar 27, 2018 at 2:47 PM, Johannes Schauer wrote:
> Hi all,
>
> > At the end of the script, it runs
> >
> > symlink("/usr/share/doc/sbuild/examples/sbuild-update-all",
> "/etc/cron.daily/sbuild-debian-developer-setup-update-all");
> >
> > which requires the file in /usr/share/doc to be present. Policy 12.3
> says that
> > packages can't do that and says that such files should be in
> > /usr/share/package with a symlink into /usr/share/doc/package/ as
> > appropriate.
>
> probably the right thing to do would be to let the
> sbuild-debian-developer-setup package directly install sbuild-update-all
> into
> /etc/cron.daily/sbuild-debian-developer-setup-update-all. If necessary,
> sbuild-update-all has to be adapted such that it will not barf if the user
> has
> not yet run sbuild-debian-developer-setup.
>
> This would mean that the same copy of sbuild-update-all would potentially
> exist
> twice on a system, but I don't think that's much of a problem.
>
> Michael, can you take care of this?
>
> Thanks!
>
> cheers, josch
>
--
Best regards,
Michael
diff --git i/debian/rules w/debian/rules
index bc15c043..b1bfe785 100755
--- i/debian/rules
+++ w/debian/rules
@@ -3,5 +3,10 @@
%:
dh $@
+override_dh_install:
+ cp etc/sbuild-update-all etc/sbuild-debian-developer-setup-update-all
+ chmod +x etc/sbuild-debian-developer-setup-update-all
+ dh_install
+
override_dh_installinit:
dh_installinit --no-start --no-restart-on-upgrade
diff --git i/debian/sbuild-debian-developer-setup.install w/debian/sbuild-debian-developer-setup.install
index 406b3af9..6d2a1699 100644
--- i/debian/sbuild-debian-developer-setup.install
+++ w/debian/sbuild-debian-developer-setup.install
@@ -1 +1,2 @@
usr/bin/sbuild-debian-developer-setup
+etc/sbuild-debian-developer-setup-update-all etc/cron.daily
diff --git i/etc/sbuild-update-all w/etc/sbuild-update-all
index 12a394cb..3e22d05a 100644
--- i/etc/sbuild-update-all
+++ w/etc/sbuild-update-all
@@ -76,7 +76,7 @@ exec 1>&8
if ! ls /etc/schroot/chroot.d/$PATTERN >/dev/null 2>&1
then
echo "No chroots defined"
- break
+ exit 0
fi
for fullname in /etc/schroot/chroot.d/$PATTERN
Bug#879483: closing 879483
close 879483 thanks -- Best regards, Michael
Bug#893608: sbuild: Silent arch:all defaults change breaks buildd setups
control: tags -1 + pending Hi James, James Clarke writes: > In the latest upload, #870263 was fixed (which I support, for what it's worth; > any+all builds is the right default for users), meaning that buildd setups now > build arch:all packages, which we *have* to work around by setting > $build_arch_all=0 in sbuild.conf. Without this, uploads are rejected by the > archive (the buildd's signing key does not have upload rights for arch:all > packages, the arch:all packages already exist, etc). This is therefore a > breaking change, and so deserves at least a mention in the NEWS file. > Moreover, > having to configure this in sbuild.conf is sub-optimal; ideally, buildd would > pass --no-arch-all to sbuild when an arch:any build is requested by > wanna-build; > as far as I know, the assumption is always that a non-Architecture:all build > is > arch:any. Addressed by the following commit IIUC: https://anonscm.debian.org/cgit/buildd-tools/sbuild.git/commit/?id=821144b5ef48bb11bf98657349ba808c25452721 > We probably also don't want lintian run during buildd builds as it fork-bombs > on > packages like gcc-8-cross-ports (#890873), and there's lintian.debian.org > doing > that for x86, which is probably good enough, though I suppose in an ideal > world > it would be run too. https://anonscm.debian.org/cgit/buildd-tools/sbuild.git/commit/?id=e8da1ee764d8b3b5aaa0fe82aac8e877f1cc4f4d -- Best regards, Michael
Bug#824628: [pkg-go] Bug#824628: golang-metrics-dev and golang-github-rcrowley-go-metrics-dev: error when trying to install together
Sounds good, thanks for taking care of this. On Sat, Mar 10, 2018 at 5:48 PM, Mpampis Kostas wrote: > Hello and thanks Andreas for the bug report, > > golang-metrics-dev is outdated for 2.5 years and greatly deviates from the > package naming convention defined by the pkg-go team in > https://pkg-go.alioth.debian.org/packaging.html > This naming deviation apparently causes this bug to reoccur. > > Instead of removing the up-to-date golang-github-rcrowley-go-metrics-dev > packace which follows the right naming > convention, me and my sponsor suggest the following actions: > > * Revise golang-github-rcrowley-go-metrics-dev using Conflicts: > golang-metrics-dev & Replaces: golang-metrics-dev. > * Open bug report to the 8 reverse dependencies of golang-metrics-dev and > suggest to depend on golang-github-rcrowley-go-metrics-dev. > * Request removal of golang-metrics-dev from the archive when it has zero > reverse dependencies. > > We can proceed with the above actions if there are no objections or other > suggestions. > > Mpampis > > > ___ > Pkg-go-maintainers mailing list > pkg-go-maintain...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers > -- Best regards, Michael
Bug#890934: [pkg-go] Bug#890934: golang-github-masterzen-winrm: FTBFS and Debci failure with golang-1.10-go
This issue is tracked upstream at https://github.com/masterzen/winrm/issues/77 On Tue, Feb 20, 2018 at 8:09 PM, Adrian Bunk wrote: > Source: golang-github-masterzen-winrm > Version: 0.0~git20170601.0.1ca0ba6-2 > Severity: serious > > https://ci.debian.net/packages/g/golang-github-masterzen-winrm/unstable/ > amd64/ > https://tests.reproducible-builds.org/debian/rb-pkg/ > unstable/amd64/golang-github-masterzen-winrm.html > > ... >dh_auto_test -O--buildsystem=golang > cd obj-x86_64-linux-gnu && go test -vet=off -v -p 16 > github.com/masterzen/winrm github.com/masterzen/winrm/soap > === RUN Test > > -- > FAIL: golang-github-masterzen-winrm_0.0~git20170601.0.1ca0ba6-2/ > obj-x86_64-linux-gnu/src/github.com/masterzen/winrm/client_test.go:89: > WinRMSuite.TestRunWithString > > golang-github-masterzen-winrm_0.0~git20170601.0.1ca0ba6-2/ > obj-x86_64-linux-gnu/src/github.com/masterzen/winrm/client_test.go:100: > ...open golang-github-masterzen-winrm_0.0~git20170601.0.1ca0ba6-2/ > obj-x86_64-linux-gnu/src/github.com/masterzen/winrm/client_test.go: no > such file or directory > ... obtained string = "That's all folks!!!\x00\x00\x00\x00\x00\ > x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ > x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ > x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ > x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ > x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ > x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ > x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ > x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ > x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ > x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ > x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ > x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ > x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ > x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ > x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ > x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ > x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 > \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ > x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ > x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ > x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ > x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ > x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ > x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ > x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ > x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ > x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ > x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ > x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ > x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ > x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ > x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ > x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ > x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ > x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ > x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ > x00\x00\x00\x00\x00\x00\x00\x00\x00\x00" > ... expected string = "That's all folks!!!" > > OOPS: 36 passed, 1 FAILED > --- FAIL: Test (5.25s) > FAIL > FAILgithub.com/masterzen/winrm 5.282s > === RUN Test > OK: 6 passed > --- PASS: Test (0.01s) > === RUN TestAddUsualNamespaces > --- PASS: TestAddUsualNamespaces (0.00s) > === RUN TestSetTo > --- PASS: TestSetTo (0.00s) > PASS > ok github.com/masterzen/winrm/soap 0.027s > dh_auto_test: cd obj-x86_64-linux-gnu && go test -vet=off -v -p 16 > github.com/masterzen/winrm github.com/masterzen/winrm/soap returned exit > code 1 > make: *** [debian/rules:6: build] Error 1 > > ___ > Pkg-go-maintainers mailing list > pkg-go-maintain...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers > -- Best regards, Michael
Bug#890939: [pkg-go] Bug#890939: etcd FTBFS
Half of this issue can be fixed by re-generating the codec files by setting
“export DH_GOLANG_GO_GENERATE := 1” in debian/rules and adding a
Build-Depends: golang-github-ugorji-go-codec to debian/control.
I haven’t figured out how to re-generate the remaining (failing) files yet.
On Tue, Feb 20, 2018 at 8:57 PM, Adrian Bunk wrote:
> Source: etcd
> Version: 3.2.9+dfsg-3
> Severity: serious
> Control: affects -1 src:docker-libkv src:golang-github-spf13-viper
> src:golang-github-xordataexchange-crypt src:skydns
>
> Some recent change in unstable makes etcd FTBFS:
>
> https://tests.reproducible-builds.org/debian/history/etcd.html
> https://tests.reproducible-builds.org/debian/rb-pkg/
> unstable/amd64/etcd.html
>
> ...
> github.com/coreos/etcd/mvcc
> # github.com/coreos/etcd/etcdserver/api/v3election/v3electionpb/gw
> src/github.com/coreos/etcd/etcdserver/api/v3election/
> v3electionpb/gw/v3election.pb.gw.go:147:39: not enough arguments in call
> to runtime.AnnotateContext
> have ("golang.org/x/net/context".Context, *http.Request)
> want ("golang.org/x/net/context".Context, *runtime.ServeMux,
> *http.Request)
> src/github.com/coreos/etcd/etcdserver/api/v3election/
> v3electionpb/gw/v3election.pb.gw.go:149:21: not enough arguments in call
> to runtime.HTTPError
> have ("golang.org/x/net/context".Context, runtime.Marshaler,
> http.ResponseWriter, *http.Request, error)
> want ("golang.org/x/net/context".Context, *runtime.ServeMux,
> runtime.Marshaler, http.ResponseWriter, *http.Request, error)
> src/github.com/coreos/etcd/etcdserver/api/v3election/
> v3electionpb/gw/v3election.pb.gw.go:154:21: not enough arguments in call
> to runtime.HTTPError
> have ("golang.org/x/net/context".Context, runtime.Marshaler,
> http.ResponseWriter, *http.Request, error)
> want ("golang.org/x/net/context".Context, *runtime.ServeMux,
> runtime.Marshaler, http.ResponseWriter, *http.Request, error)
> src/github.com/coreos/etcd/etcdserver/api/v3election/
> v3electionpb/gw/v3election.pb.gw.go:158:30: not enough arguments in call
> to forward_Election_Campaign_0
> have ("golang.org/x/net/context".Context, runtime.Marshaler,
> http.ResponseWriter, *http.Request, proto.Message, []func("
> golang.org/x/net/context".Context, http.ResponseWriter, proto.Message)
> error...)
> want ("golang.org/x/net/context".Context, *runtime.ServeMux,
> runtime.Marshaler, http.ResponseWriter, *http.Request, proto.Message,
> ...func("golang.org/x/net/context".Context, http.ResponseWriter,
> proto.Message) error)
> src/github.com/coreos/etcd/etcdserver/api/v3election/
> v3electionpb/gw/v3election.pb.gw.go:175:39: not enough arguments in call
> to runtime.AnnotateContext
> have ("golang.org/x/net/context".Context, *http.Request)
> want ("golang.org/x/net/context".Context, *runtime.ServeMux,
> *http.Request)
> src/github.com/coreos/etcd/etcdserver/api/v3election/
> v3electionpb/gw/v3election.pb.gw.go:177:21: not enough arguments in call
> to runtime.HTTPError
> have ("golang.org/x/net/context".Context, runtime.Marshaler,
> http.ResponseWriter, *http.Request, error)
> want ("golang.org/x/net/context".Context, *runtime.ServeMux,
> runtime.Marshaler, http.ResponseWriter, *http.Request, error)
> src/github.com/coreos/etcd/etcdserver/api/v3election/
> v3electionpb/gw/v3election.pb.gw.go:182:21: not enough arguments in call
> to runtime.HTTPError
> have ("golang.org/x/net/context".Context, runtime.Marshaler,
> http.ResponseWriter, *http.Request, error)
> want ("golang.org/x/net/context".Context, *runtime.ServeMux,
> runtime.Marshaler, http.ResponseWriter, *http.Request, error)
> src/github.com/coreos/etcd/etcdserver/api/v3election/
> v3electionpb/gw/v3election.pb.gw.go:186:30: not enough arguments in call
> to forward_Election_Proclaim_0
> have ("golang.org/x/net/context".Context, runtime.Marshaler,
> http.ResponseWriter, *http.Request, proto.Message, []func("
> golang.org/x/net/context".Context, http.ResponseWriter, proto.Message)
> error...)
> want ("golang.org/x/net/context".Context, *runtime.ServeMux,
> runtime.Marshaler, http.ResponseWriter, *http.Request, proto.Message,
> ...func("golang.org/x/net/context".Context, http.ResponseWriter,
> proto.Message) error)
> src/github.com/coreos/etcd/etcdserver/api/v3election/
> v3electionpb/gw/v3election.pb.gw.go:203:39: not enough arguments in call
> to runtime.AnnotateContext
> have ("golang.org/x/net/context".Context, *http.Request)
> want ("golang.org/x/net/context".Context, *runtime.ServeMux,
> *http.Request)
> src/github.com/coreos/etcd/etcdserver/api/v3election/
> v3electionpb/gw/v3election.pb.gw.go:205:21: not enough arguments in call
> to runtime.HTTPError
> have ("golang.org/x/net/context".Context, runtime.Marshaler,
> http.ResponseWriter, *http.Request, error)
> want ("golang.org/x/net/context".Context, *runtime.ServeMux,
> runtime.Marshaler, http.Response
Bug#891032: [pkg-go] Bug#891032: golang-gopkg-gcfg.v1-dev: ships a copy of files already in golang-gopkg-warnings.v0-dev
Thanks for the report. I’m aware of this: I recently introduced the warnings.v0 package in order to remove the vendored code from gcfg.v1. I was waiting for the archive to catch up before uploading the fixed version, which I’ll do in a minute. On Wed, Feb 21, 2018 at 6:14 PM, Andreas Beckmann wrote: > Package: golang-gopkg-gcfg.v1-dev > Version: 1.2.0-3 > Severity: serious > User: debian...@lists.debian.org > Usertags: piuparts > Control: affects -1 + golang-gopkg-warnings.v0-dev > > Hi, > > during a test with piuparts I noticed your package ships files already > shipped by golang-gopkg-warnings.v0-dev: > > From the attached log (scroll to the bottom...): > > Selecting previously unselected package golang-gopkg-gcfg.v1-dev. > Preparing to unpack .../5-golang-gopkg-gcfg.v1-dev_1.2.0-3_all.deb ... > Unpacking golang-gopkg-gcfg.v1-dev (1.2.0-3) ... > dpkg: error processing archive /tmp/apt-dpkg-install-pcbwJL/ > 5-golang-gopkg-gcfg.v1-dev_1.2.0-3_all.deb (--unpack): >trying to overwrite '/usr/share/gocode/src/gopkg. > in/warnings.v0/warnings.go', which is also in package > golang-gopkg-warnings.v0-dev 0.1.2-1 > Errors were encountered while processing: >/tmp/apt-dpkg-install-pcbwJL/5-golang-gopkg-gcfg.v1-dev_1.2.0-3_all.deb > > > Andreas > > ___ > Pkg-go-maintainers mailing list > pkg-go-maintain...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers > -- Best regards, Michael
Bug#887062: [Pkg-raspi-maintainers] Bug#887062: raspi3-firmware: postinst fails, makes bad assumption about existence of /boot/firmware/
Thanks for the additional details. Given that the package’s only purpose is to populate /boot/firmware, may I ask why it’s being installed in your builds at all? I’d like to understand the use-case before adding code to deal with it. On Mon, Jan 15, 2018 at 12:42 PM, Raphael Hertzog wrote: > On Sat, 13 Jan 2018, Michael Stapelberg wrote: > > The only change that seems in any way related to me is > > https://anonscm.debian.org/cgit/pkg-raspi/raspi3- > firmware.git/commit/?id=c977f0210ab5c577b9d5296e4e4391225a7f85ca > > This change is not the cause of the regression. The package fails at > initial installation, not on upgrade. I have added "set -x" and I get > this: > > # dpkg --configure raspi3-firmware > Setting up raspi3-firmware (1.20171201-2) ... > + ischroot > + basename /usr/lib/raspi3-firmware/bootcode.bin > + file=bootcode.bin > + cp /usr/lib/raspi3-firmware/bootcode.bin /boot/firmware/bootcode.bin > cp: cannot create regular file '/boot/firmware/bootcode.bin': No such file > or directory > dpkg: error processing package raspi3-firmware (--configure): > installed raspi3-firmware package post-installation script subprocess > returned error exit status 1 > Errors were encountered while processing: > raspi3-firmware > > I wonder how it worked before. Maybe the package shipped /boot/firmware or > another package supplied that directory and it now fails because no > package is creating it. > > In any case, you should probably not attempt to copy the files there if the > directory is not existing. > > Something like this: > > --- /tmp/postinst 2018-01-15 11:35:43.223477268 + > +++ /var/lib/dpkg/info/raspi3-firmware.postinst 2018-01-15 > 11:40:31.818918341 + > @@ -13,19 +13,23 @@ >fi > fi > > -for file in /usr/lib/raspi3-firmware/* > -do > - file=$( basename "$file" ) > - cp "/usr/lib/raspi3-firmware/$file" "/boot/firmware/$file" > - # sync might fail when running under qemu, which, as of version 2.7, > - # has not implemented the syncfs syscall. > - sync -f "/boot/firmware/$file" || true > -done > +if [ -d /boot/firmware ]; then > + for file in /usr/lib/raspi3-firmware/* > + do > + file=$( basename "$file" ) > + cp "/usr/lib/raspi3-firmware/$file" "/boot/firmware/$file" > + # sync might fail when running under qemu, which, as of version > 2.7, > + # has not implemented the syncfs syscall. > + sync -f "/boot/firmware/$file" || true > + done > > -# Manually trigger the kernel postinst hook when raspi3-firmware is > first > -# installed (or upgraded), as the kernel package might already be > installed > -# (or not upgraded) and hence the hook would not get triggered > otherwise. > -DEB_MAINT_PARAMS="configure" /etc/kernel/postinst.d/raspi3-firmware > + # Manually trigger the kernel postinst hook when raspi3-firmware > is first > + # installed (or upgraded), as the kernel package might already be > installed > + # (or not upgraded) and hence the hook would not get triggered > otherwise. > + DEB_MAINT_PARAMS="configure" /etc/kernel/postinst.d/raspi3- > firmware > +else > + echo "Warning: not copying firmwares as /boot/firmware does not > exist." >&2 > +fi > ;; > esac > > Cheers, > -- > Raphaël Hertzog ◈ Debian Developer > > Support Debian LTS: https://www.freexian.com/services/debian-lts.html > Learn to master Debian: https://debian-handbook.info/get/ > -- Best regards, Michael
Bug#887062: [Pkg-raspi-maintainers] Bug#887062: raspi3-firmware: postinst fails, makes bad assumption about existence of /boot/firmware/
The only change that seems in any way related to me is https://anonscm.debian.org/cgit/pkg-raspi/raspi3-firmware.git/commit/?id=c977f0210ab5c577b9d5296e4e4391225a7f85ca Have a look at the log at https://anonscm.debian.org/cgit/pkg-raspi/raspi3-firmware.git/ I only have bandwidth to support the Debian raspi3 image, and I wasn’t even aware of any other usages of this package. I’ll have to rely on external contributions to fix this issue. Thanks. On Sat, Jan 13, 2018 at 10:34 AM, Raphaël Hertzog wrote: > Package: raspi3-firmware > Version: 1.20171201-2 > Severity: serious > User: de...@kali.org > Usertags: origin-kali > > My dailay builds of Kali armhf live images are now failing with this > version of > raspi3-firmware with this error: > > Setting up raspi3-firmware (1.20171201-2) ... > cp: cannot create regular file '/boot/firmware/bootcode.bin': No such file > or directory > dpkg: error processing package raspi3-firmware (--configure): > > I did not check the code but it looks like it assumes that /boot/firmware/ > does exist > while it doesn't (at least not in the context of the chroot where the live > image is being built). > > This was working fine a few days ago with the previous version that was in > testing > (1.20171006-1, Kali is based on Debian Testing). > > Cheers, > > -- System Information: > Debian Release: buster/sid > APT prefers oldoldstable > APT policy: (500, 'oldoldstable'), (500, 'unstable'), (500, 'testing'), > (500, 'stable'), (500, 'oldstable'), (1, 'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 4.14.0-1-amd64 (SMP w/4 CPU cores) > Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), > LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > ___ > Pkg-raspi-maintainers mailing list > pkg-raspi-maintain...@lists.alioth.debian.org > https://lists.alioth.debian.org/mailman/listinfo/pkg-raspi-maintainers > -- Best regards, Michael
Bug#878348: collectd FTBFS with libsigrok 0.5.0
Hi, Adrian Bunk writes: > Source: collectd > Version: 5.7.2-1 > Severity: serious > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/collectd.html > > ... > checking for LIBSIGROK... no > ... > configure:40804: checking for LIBSIGROK > configure:40811: $PKG_CONFIG --exists --print-errors "libsigrok < 0.4" > Requested 'libsigrok < 0.4' but version of libsigrok is 0.5.0 tokkee, are you on top of this? This bug marks freeradius for auto-removal from testing. If you need help with a fix, please let me know. -- Best regards, Michael
Bug#876692: owfs FTBFS with debhelper 10.9
Thanks for taking care of it. I’ll let you handle it :) On Mon, Oct 2, 2017 at 1:35 AM, Vincent Danjean wrote: > Le 02/10/2017 à 09:49, Michael Stapelberg a écrit : >> Hi Vincent, >> > [...] >> Are you working on a fix for this or would you like help with it? > > I forgot this bug. The testing autoremoval I received this morning > makes me remember it. It should not be difficult to patch. I plan > to fix it soon (probably this evening if I do not have too much > work) but if you want to prepare a patch for this bug, it will be > welcome. > I will do a quick fix and upload for this bug (and perhaps another > upload later if there are other bugs or a new upstream version) > > Regards, > Vincent > >> Asking because freeradius is marked for removal from testing due to this >> bug. >> >> Thanks! >> > > > -- > Vincent Danjean GPG key ID 0xD17897FA vdanj...@debian.org > GPG key fingerprint: 621E 3509 654D D77C 43F5 CA4A F6AE F2AF D178 97FA > Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html > APT repo: deb http://people.debian.org/~vdanjean/debian unstable main > -- Best regards, Michael
Bug#876692: owfs FTBFS with debhelper 10.9
Hi Vincent, Adrian Bunk writes: > Source: owfs > Version: 3.1p5-1 > Severity: serious > Tags: buster sid > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/owfs.html > > ... >debian/rules override_dh_makeshlibs > make[1]: Entering directory '/build/1st/owfs-3.1p5' > dh_makeshlibs --no-package libow-php5 --no-package libow-tcl > dh_makeshlibs: Unknown package libow-php5 given via -N/--no-package, expected > one of: owfs-common owfs libow-3.1-5 libowcapi-3.1-5 libow-dev libownet-3.1-5 > libownet-dev owserver ow-shell ow-tools owfs-fuse owhttpd owftpd libownet-php > libow-perl libownet-perl python-ow python-ownet libow-tcl owfs-doc owfs-dbg > dh_makeshlibs: unknown option or error during option parsing; aborting > debian/rules:97: recipe for target 'override_dh_makeshlibs' failed > make[1]: *** [override_dh_makeshlibs] Error 25 Are you working on a fix for this or would you like help with it? Asking because freeradius is marked for removal from testing due to this bug. Thanks! -- Best regards, Michael
Bug#853515: libwebsockets: ftbfs with GCC-7
Hi, Gianfranco Costamagna writes: > the new 2.3.0 release seems to build correctly with gcc-7 If cherry-picking the fixes, or packaging the new upstream release isn’t feasible, I think we could fix this issue the same way that https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871062 fixes it. This is somewhat time-critical, because this RC bug will cause freeradius to be removed from testing. Peter, do you have time to upload a new version, or would you prefer an NMU for this? -- Best regards, Michael
Bug#853579: nut: ftbfs with GCC-7
Hi, Laurent, do you have time to upload a fix, or would you prefer an NMU? This is somewhat time-critical, because this RC bug will cause freeradius to be removed from testing. -- Best regards, Michael
Bug#871062: collectd: FTBFS: client.c:621:23: error: '%s' directive output may be truncated writing up to 1023 bytes into a region of size 1010 [-Werror=format-truncation=]
Hi, Steve Langasek writes: > The attached one-liner patch corrects this build failure by simply ignoring > the (IMHO uninteresting) new gcc-7 warning. I think this is a reasonable > way to handle this until it gets fixed upstream. Marc, Sebastian, does either of you have time to upload this patch, or would you prefer an NMU? This is somewhat time-critical, because this RC bug will cause freeradius to be removed from testing. Thanks. -- Best regards, Michael
Bug#866172: closing 866172
close 866172 3.0.0-1 thanks -- Best regards, Michael
Bug#839293: closing 839293
close 839293 1.12-1 thanks -- Best regards, Michael
Bug#841590: closing 841590
close 841590 1.12-1 thanks -- Best regards, Michael
Bug#868765: [Pkg-freeradius-maintainers] Bug#868765: freeradius: New upstream version 3.0.15 fixing security critical bugs
Thanks for the heads-up. I’ll work on packaging the new upstream release later today. On Tue, Jul 18, 2017 at 4:06 AM, Karsten Heymann wrote: > Package: freeradius > Version: 3.0.12+dfsg-5 > Severity: grave > Tags: upstream security > Justification: user security hole > > Dear Maintainer, > > the freeradius team released version 3.0.15 fixing several important > security issues found by a fuzzing analysis. > > See: > http://freeradius.org/press/index.html#3.0.15 > http://freeradius.org/security/fuzzer-2017.html > > The following issues were found for v3 of freeradius up to 3.0.14: > - CVE-2017-10978. No remote code execution is possible. A denial of > service is possible. > - CVE-2017-10984. Remote code execution is possible. A denial of > service is possible. > - CVE-2017-10985. No remote code execution is possible. A denial of > service is possible. > > The following affect only the DHCP part of freeradius, which is seldomly > used: > - CVE-2017-10983. No remote code execution is possible. A denial of > service is possible. > - CVE-2017-10986. No remote code execution is possible. A denial of > service is possible. > - CVE-2017-10987. No remote code execution is possible. A denial of > service is possible. > > Please update the package accordingly. > > -- System Information: > Debian Release: 9.0 > APT prefers stable > APT policy: (500, 'stable') > Architecture: amd64 (x86_64) > > Kernel: Linux 4.9.0-3-amd64 (SMP w/2 CPU cores) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), > LANGUAGE=en_US.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages freeradius depends on: > ii freeradius-common 3.0.12+dfsg-5 > ii freeradius-config 3.0.12+dfsg-5 > ii libc6 2.24-11+deb9u1 > ii libcap21:2.25-1 > ii libfreeradius3 3.0.12+dfsg-5 > ii libgdbm3 1.8.3-14 > ii libpam0g 1.1.8-3.6 > ii libpcre3 2:8.39-3 > ii libperl5.245.24.1-3 > ii libpython2.7 2.7.13-2 > ii libreadline7 7.0-3 > ii libsqlite3-0 3.16.2-5 > ii libssl1.1 1.1.0f-3 > ii libtalloc2 2.1.8-1 > ii libwbclient0 2:4.5.8+dfsg-2+deb9u1+b1 > ii lsb-base 9.20161125 > > Versions of packages freeradius recommends: > pn freeradius-utils > > Versions of packages freeradius suggests: > pn freeradius-krb5 > pn freeradius-ldap > pn freeradius-mysql > pn freeradius-postgresql > pn snmp > > -- no debconf information > > ___ > Pkg-freeradius-maintainers mailing list > pkg-freeradius-maintain...@lists.alioth.debian.org > https://lists.alioth.debian.org/mailman/listinfo/pkg- > freeradius-maintainers > -- Best regards, Michael
Bug#868761: [Pkg-freeradius-maintainers] Bug#868761: freeradius: New upstream version 2.2.10 fixing security critical bugs
Help with this would be appreciated. I’m not sure about the appropriate processes, so if you could clarify that with the security/release team, that’d be helpful. On Tue, Jul 18, 2017 at 3:51 AM, Karsten Heymann wrote: > Subject: freeradius: New upstream version 2.2.10 fixing security critical > bugs > Package: freeradius > Version: 2.2.5+dfsg-0.2 > Justification: user security hole > Severity: grave > Tags: security upstream > > The freeradius team released version 2.2.10 fixing several important > security issues found by a fuzzing analysis. > > See: > http://freeradius.org/press/index.html#2.2.10 > http://freeradius.org/security/fuzzer-2017.html > > The following issues were found for v2 of freeradius up to 2.2.9: > - CVE-2017-10978. No remote code execution is possible. A denial of > service is possible. > - CVE-2017-10979. Remote code execution is possible. A denial of > service is possible. > > The following affect only the DHCP part of freeradius, which is seldomly > used: > - CVE-2017-10980. No remote code execution is possible. A denial of > service is possible. > - CVE-2017-10981. No remote code execution is possible. A denial of > service is possible. > - CVE-2017-10982. No remote code execution is possible. A denial of > service is possible. > - CVE-2017-10983. No remote code execution is possible. A denial of > service is possible. > > I'm not sure what's the best way to proceed. As I assume updating the > package in oldstable to 2.2.10 is not a realistic option, my guess > would be that at least CVE-2017-10978 and CVE-2017-10979 should be > fixed in the code via backporting the relevant fixes. This is even > more critical as there is no backport of freeradius 3 in jessie, and > it is not possible to create or update backports for oldstable. > > -- System Information: > Debian Release: 8.8 > APT prefers oldstable-updates > APT policy: (500, 'oldstable-updates'), (500, 'oldstable') > Architecture: amd64 (x86_64) > > Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core) > Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages freeradius depends on: > ii adduser3.113+nmu3 > ii ca-certificates20141019+deb8u3 > ii freeradius-common 2.2.5+dfsg-0.2 > ii libc6 2.19-18+deb8u10 > ii libfreeradius2 2.2.5+dfsg-0.2 > ii libgdbm3 1.8.3-13.1 > ii libltdl7 2.4.2-1.11+b1 > ii libpam0g 1.1.8-3.1+deb8u2 > ii libperl5.205.20.2-3+deb8u7 > ii libpython2.7 2.7.9-2+deb8u1 > ii libssl1.0.01.0.1t-1+deb8u6 > ii lsb-base 4.1+Debian13+nmu1 > ii ssl-cert 1.0.35 > > Versions of packages freeradius recommends: > ii freeradius-utils 2.2.5+dfsg-0.2 > > Versions of packages freeradius suggests: > pn freeradius-krb5 > ii freeradius-ldap2.2.5+dfsg-0.2 > ii freeradius-mysql 2.2.5+dfsg-0.2 > pn freeradius-postgresql > > -- Configuration Files: > /etc/freeradius/clients.conf changed [not included] > /etc/freeradius/eap.conf changed [not included] > /etc/freeradius/ldap.attrmap changed [not included] > /etc/freeradius/modules/ldap changed [not included] > /etc/freeradius/modules/pap changed [not included] > /etc/freeradius/sites-available/control-socket changed [not included] > /etc/freeradius/sites-available/default changed [not included] > /etc/freeradius/sites-available/inner-tunnel changed [not included] > /etc/freeradius/sql.conf changed [not included] > /etc/freeradius/users changed [not included] > > -- no debconf information > > ___ > Pkg-freeradius-maintainers mailing list > pkg-freeradius-maintain...@lists.alioth.debian.org > https://lists.alioth.debian.org/mailman/listinfo/pkg- > freeradius-maintainers > -- Best regards, Michael
Bug#866978: [Pkg-freeradius-maintainers] Bug#866978: freeradius FTBFS: recipe for target 'override_dh_missing' failed
I’m stumped as to why sbuild works locally, but not on the buildds o_O. On Mon, Jul 3, 2017 at 12:57 AM, Adrian Bunk wrote: > Source: freeradius > Version: 3.0.14+dfsg-1 > Severity: serious > > https://buildd.debian.org/status/package.php?p=freeradius&suite=sid > > ... >debian/rules override_dh_missing > make[1]: Entering directory '/<>/freeradius-3.0.14+dfsg' > # Use --fail-missing so that new files e.g. in usr/lib/freeradius/rlm_* > # can be detected and added to debian/freeradius.install. We cannot use > # globbing because some files are split into more specific packages, > # e.g. freeradius-mysql. > dh_missing --fail-missing > dh_missing: usr/share/man/man8/freeradius.8 exists in debian/tmp but is > not installed to anywhere > dh_missing: usr/share/man/man8/rlm_ippool_tool.8 exists in debian/tmp but > is not installed to anywhere > dh_missing: usr/share/man/man8/radsniff.8 exists in debian/tmp but is not > installed to anywhere > dh_missing: usr/share/man/man8/radmin.8 exists in debian/tmp but is not > installed to anywhere > dh_missing: usr/share/man/man8/radcrypt.8 exists in debian/tmp but is not > installed to anywhere > dh_missing: usr/share/man/man8/raddebug.8 exists in debian/tmp but is not > installed to anywhere > dh_missing: usr/share/man/man8/radrelay.8 exists in debian/tmp but is not > installed to anywhere > dh_missing: usr/share/man/man8/radsqlrelay.8 exists in debian/tmp but is > not installed to anywhere > dh_missing: usr/share/man/man5/radrelay.conf.5 exists in debian/tmp but > is not installed to anywhere > dh_missing: usr/share/man/man5/rlm_idn.5 exists in debian/tmp but is not > installed to anywhere > dh_missing: usr/share/man/man5/rlm_expr.5 exists in debian/tmp but is not > installed to anywhere > dh_missing: usr/share/man/man5/dictionary.5 exists in debian/tmp but is > not installed to anywhere > dh_missing: usr/share/man/man5/rlm_pap.5 exists in debian/tmp but is not > installed to anywhere > dh_missing: usr/share/man/man5/rlm_digest.5 exists in debian/tmp but is > not installed to anywhere > dh_missing: usr/share/man/man5/rlm_chap.5 exists in debian/tmp but is not > installed to anywhere > dh_missing: usr/share/man/man5/users.5 exists in debian/tmp but is not > installed to anywhere > dh_missing: usr/share/man/man5/rlm_mschap.5 exists in debian/tmp but is > not installed to anywhere > dh_missing: usr/share/man/man5/rlm_detail.5 exists in debian/tmp but is > not installed to anywhere > dh_missing: usr/share/man/man5/checkrad.5 exists in debian/tmp but is not > installed to anywhere > dh_missing: usr/share/man/man5/rlm_counter.5 exists in debian/tmp but is > not installed to anywhere > dh_missing: usr/share/man/man5/rlm_passwd.5 exists in debian/tmp but is > not installed to anywhere > dh_missing: usr/share/man/man5/unlang.5 exists in debian/tmp but is not > installed to anywhere > dh_missing: usr/share/man/man5/radiusd.conf.5 exists in debian/tmp but is > not installed to anywhere > dh_missing: usr/share/man/man5/clients.conf.5 exists in debian/tmp but is > not installed to anywhere > dh_missing: usr/share/man/man5/rlm_sql.5 exists in debian/tmp but is not > installed to anywhere > dh_missing: usr/share/man/man5/rlm_unix.5 exists in debian/tmp but is not > installed to anywhere > dh_missing: usr/share/man/man5/rlm_attr_filter.5 exists in debian/tmp but > is not installed to anywhere > dh_missing: usr/share/man/man5/rlm_files.5 exists in debian/tmp but is not > installed to anywhere > dh_missing: usr/share/man/man5/rlm_always.5 exists in debian/tmp but is > not installed to anywhere > dh_missing: usr/share/man/man5/rlm_realm.5 exists in debian/tmp but is not > installed to anywhere > dh_missing: usr/share/man/man1/radwho.1 exists in debian/tmp but is not > installed to anywhere > dh_missing: usr/share/man/man1/radtest.1 exists in debian/tmp but is not > installed to anywhere > dh_missing: usr/share/man/man1/radlast.1 exists in debian/tmp but is not > installed to anywhere > dh_missing: usr/share/man/man1/radclient.1 exists in debian/tmp but is not > installed to anywhere > dh_missing: usr/share/man/man1/radeapclient.1 exists in debian/tmp but is > not installed to anywhere > dh_missing: usr/share/man/man1/radzap.1 exists in debian/tmp but is not > installed to anywhere > dh_missing: usr/share/man/man1/rad_counter.1 exists in debian/tmp but is > not installed to anywhere > dh_missing: usr/share/man/man1/smbencrypt.1 exists in debian/tmp but is > not installed to anywhere > dh_missing: missing files, aborting > The following debhelper tools have reported what they installed > (with files per package) > * dh_install: freeradius (59), freeradius-common (213), > freeradius-config (1), freeradius-dhcp (3), freeradius-iodbc (1), > freeradius-krb5 (1), freeradius-ldap (1), freeradius-memcached (1), > freeradius-mysql (1), freeradius-postgresql (1), freeradius-redis (2), > freeradius-rest (1), freeradius-utils (11), freeradius-yubikey (1), > libfreeradius-dev (68),
Bug#863673: [Pkg-freeradius-maintainers] Bug#863673: CVE-2017-9148: FreeRADIUS TLS resumption authentication bypass
Thanks for your reply. I don’t have a way to test the vulnerability either. I’d trust Pavel’s assessment and call this done. On Wed, Jun 7, 2017 at 7:10 AM, Salvatore Bonaccorso wrote: > Hi Michael > > Looks it was good we had first the issue settle a bit with respect for > a jessie(-security) upload: > > On Thu, Jun 01, 2017 at 11:09:17PM +0200, Michael Stapelberg wrote: > > The original question of how to proceed still stands. I sent the patch in > > my previous message; do you want me to upload it, or do you want to > upload > > it? If I should do it, let me state for the record that I have no idea > what > > I’m doing (I never uploaded to anything but unstable/experimental). > > I learned of http://www.openwall.com/lists/oss-security/2017/06/06/5 . > Can you confirm, is this assessment correct (for us as well in > stable)? We have a 2.2.5 based version in jessie, and according to > upstream for the EOL versions only 2.1.1 through 2.1.7 are affected by > the problem. > > I do not have a way to test the vulnerability on my own. > > Regards, > Salvatore > -- Best regards, Michael
Bug#863673: [Pkg-freeradius-maintainers] Bug#863673: CVE-2017-9148: FreeRADIUS TLS resumption authentication bypass
Thanks, I agree that updating the FAQ would be good. The original question of how to proceed still stands. I sent the patch in my previous message; do you want me to upload it, or do you want to upload it? If I should do it, let me state for the record that I have no idea what I’m doing (I never uploaded to anything but unstable/experimental). On Thu, Jun 1, 2017 at 9:34 AM, Salvatore Bonaccorso wrote: > Hi > > On Thu, Jun 01, 2017 at 08:54:57AM +0200, Michael Stapelberg wrote: > > I got the idea from https://www.debian.org/security/faq#upload. Is the > FAQ > > outdated, or did I read it wrong? If the latter, please elaborate so that > > we can update the docs to be more clear. > > The idea behind that FAQ entry is to state that an upload should never > be done without first having an ack from the security team. The > dev-ref gives a broather view on how to handle security-issues, and > interact with the team: > > https://www.debian.org/doc/manuals/developers-reference/ > ch05.en.html#bug-security > > Maybe we should rephrase a bit the FAQ entry itself. > > Regards, > Salvatore > -- Best regards, Michael
Bug#863707: simple-tpm-pk11: FTBFS: ./m4/test-driver: line 107: 4695 Aborted (core dumped)
Thomas, here are the steps to reproduce using docker. They should be easily transferrable to a VM: % docker run -t -i debian:sid /bin/bash root# echo deb-src http://deb.debian.org/debian sid main >> /etc/apt/sources.list root# apt update root# apt build-dep simple-tpm-pk11 root# apt source simple-tpm-pk11 root# cd simple-tpm-pk11-0.06/ root# dpkg-buildpackage -b The backtrace of the coredump is: #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 #1 0x7f89a890c3fa in __GI_abort () at abort.c:89 #2 0x55cebe316ca5 in testing::internal::posix::Abort () at /usr/include/gtest/internal/gtest-port.h:2410 #3 testing::internal::GTestLog::~GTestLog (this=, __in_chrg=) at /usr/src/gtest/src/gtest-port.cc:923 #4 0x55cebe33d86d in testing::internal::GTestLog::~GTestLog (this=, __in_chrg=) at /usr/src/gtest/src/gtest-port.cc:921 #5 testing::internal::ThreadLocal > >::~ThreadLocal (this=, __in_chrg=) at /usr/include/gtest/internal/gtest-port.h:2044 #6 testing::internal::UnitTestImpl::~UnitTestImpl (this=0x55cebf698e10, __in_chrg=) at /usr/src/gtest/src/gtest.cc:4359 #7 0x55cebe33d979 in testing::internal::UnitTestImpl::~UnitTestImpl (this=0x55cebf698e10, __in_chrg=) at /usr/src/gtest/src/gtest.cc:4367 #8 0x55cebe33d461 in testing::UnitTest::~UnitTest ( this=0x55cebe56d7e0 , __in_chrg=) at /usr/src/gtest/src/gtest.cc:4307 #9 0x7f89a890d910 in __run_exit_handlers (status=0, listp=0x7f89a8c715d8 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true) at exit.c:83 #10 0x7f89a890d96a in __GI_exit (status=) at exit.c:105 #11 0x7f89a88f82b8 in __libc_start_main (main=0x55cebe317520 , argc=1, argv=0x7ffe994d5118, init=, fini=, rtld_fini=, stack_end=0x7ffe994d5108) at ../csu/libc-start.c:325 #12 0x55cebe3178ba in _start () Any ideas what could cause this? On Wed, May 31, 2017 at 4:09 PM, Chris Lamb wrote: > Hi Michael, > > > Thanks for the report. Do you have a VM in which upstream (Thomas Habets) > > could reproduce the failure? > > I'm inferring from this that you cannot reproduce it yourself? :) > > I'm not sure I can provide any more details apart from that it also fails > on the Reproducible Builds testing framework (as well as my personal laptop > from which I submitted my bug report): > > https://tests.reproducible-builds.org/debian/rb-pkg/ > unstable/amd64/simple-tpm-pk11.html > > > Regards, > > -- > ,''`. > : :' : Chris Lamb > `. `'` la...@debian.org / chris-lamb.co.uk >`- > -- Best regards, Michael
Bug#863673: [Pkg-freeradius-maintainers] Bug#863673: CVE-2017-9148: FreeRADIUS TLS resumption authentication bypass
I got the idea from https://www.debian.org/security/faq#upload. Is the FAQ
outdated, or did I read it wrong? If the latter, please elaborate so that
we can update the docs to be more clear.
Note that FreeRADIUS is not complex to test. The only functional tests I do
before uploading are running autopkgtest and checking whether a freshly
installed FreeRADIUS starts up.
Also note that the patch is rather simple — it permanently disables the TLS
session caching by replacing the config option with “false” in the code. I
have attached the corresponding patches for the jessie and wheezy version.
Please let me know how to proceed from here.
On Wed, May 31, 2017 at 10:32 PM, Moritz Muehlenhoff wrote:
> On Tue, May 30, 2017 at 05:50:20PM +0200, Michael Stapelberg wrote:
> > security-team, can you take care of applying the patch to stable and
> > oldstable please? Thank you.
>
> No, we generally expect maintainers to prepare/test security updates,
> particularly for packages which are complex to test like freeradius.
>
> Cheers,
> Moritz
>
--
Best regards,
Michael
diff --git i/src/modules/rlm_eap/types/rlm_eap_tls/rlm_eap_tls.c w/src/modules/rlm_eap/types/rlm_eap_tls/rlm_eap_tls.c
index 53955ba..1564238 100644
--- i/src/modules/rlm_eap/types/rlm_eap_tls/rlm_eap_tls.c
+++ w/src/modules/rlm_eap/types/rlm_eap_tls/rlm_eap_tls.c
@@ -1000,7 +1000,7 @@ static SSL_CTX *init_tls_ctx(EAP_TLS_CONF *conf)
/*
* Callbacks, etc. for session resumption.
*/
- if (conf->session_cache_enable) {
+ if (/*conf->session_cache_enable*/0) {
SSL_CTX_sess_set_new_cb(ctx, cbtls_new_session);
SSL_CTX_sess_set_get_cb(ctx, cbtls_get_session);
SSL_CTX_sess_set_remove_cb(ctx, cbtls_remove_session);
@@ -1056,7 +1056,7 @@ static SSL_CTX *init_tls_ctx(EAP_TLS_CONF *conf)
/*
* Setup session caching
*/
- if (conf->session_cache_enable) {
+ if (/*conf->session_cache_enable*/0) {
/*
* Create a unique context Id per EAP-TLS configuration.
*/
@@ -1333,7 +1333,7 @@ static int eaptls_initiate(void *type_arg, EAP_HANDLER *handler)
*
* FIXME: Also do it every N sessions?
*/
- if (inst->conf->session_cache_enable &&
+ if (/*inst->conf->session_cache_enable*/0 &&
((inst->conf->session_last_flushed + (inst->conf->session_timeout * 1800)) <= request->timestamp)) {
RDEBUG2("Flushing SSL sessions (of #%ld)",
SSL_CTX_sess_number(inst->ctx));
@@ -1471,7 +1471,7 @@ static int eaptls_initiate(void *type_arg, EAP_HANDLER *handler)
break;
}
- if (inst->conf->session_cache_enable) {
+ if (/*inst->conf->session_cache_enable*/0) {
ssn->allow_session_resumption = 1; /* otherwise it's zero */
}
@@ -1558,7 +1558,7 @@ static int eaptls_authenticate(void *arg, EAP_HANDLER *handler)
* the client can't re-use it.
*/
default:
- if (inst->conf->session_cache_enable) {
+ if (/*inst->conf->session_cache_enable*/0) {
SSL_CTX_remove_session(inst->ctx,
tls_session->ssl->session);
}
diff --git i/src/modules/rlm_eap/types/rlm_eap_tls/rlm_eap_tls.c w/src/modules/rlm_eap/types/rlm_eap_tls/rlm_eap_tls.c
index 04640e9..450b6ff 100644
--- i/src/modules/rlm_eap/types/rlm_eap_tls/rlm_eap_tls.c
+++ w/src/modules/rlm_eap/types/rlm_eap_tls/rlm_eap_tls.c
@@ -1183,7 +1183,7 @@ static SSL_CTX *init_tls_ctx(EAP_TLS_CONF *conf)
/*
* Callbacks, etc. for session resumption.
*/
- if (conf->session_cache_enable) {
+ if (/*conf->session_cache_enable*/0) {
SSL_CTX_sess_set_new_cb(ctx, cbtls_new_session);
SSL_CTX_sess_set_get_cb(ctx, cbtls_get_session);
SSL_CTX_sess_set_remove_cb(ctx, cbtls_remove_session);
@@ -1241,7 +1241,7 @@ static SSL_CTX *init_tls_ctx(EAP_TLS_CONF *conf)
/*
* Setup session caching
*/
- if (conf->session_cache_enable) {
+ if (/*conf->session_cache_enable*/0) {
/*
* Create a unique context Id per EAP-TLS configuration.
*/
@@ -1507,7 +1507,7 @@ static int eaptls_initiate(void *type_arg, EAP_HANDLER *handler)
*
* FIXME: Also do it every N sessions?
*/
- if (inst->conf.session_cache_enable &&
+ if (/*inst->conf.session_cache_enable*/0 &&
((inst->conf.session_last_flushed + (inst->conf.session_timeout * 1800)) <= request->timestamp)) {
RDEBUG2("Flushing SSL sessions (of #%ld)",
SSL_CTX_sess_number(inst->ctx));
@@ -1645,7 +1645,7 @@ static int eaptls_initiate(void *type_arg, EAP_HANDLER *handler)
break;
}
- if (inst->conf.session_cache_enable) {
+ if (/*inst->conf.session_cache_enable*/0) {
ssn->allow_session_resumption = 1; /* otherwise it's zero */
}
@@ -1774,7 +1774,7 @@ static int eaptls_authenticate(void *arg, EAP_HANDLER *handler)
* the client can't re-use it.
*/
default:
- if (inst->conf.session_cache_enable) {
+ if (/*inst->conf.session_cache_enable*/0) {
SSL_CTX_remove_session(inst->ctx,
tls_session->ssl->session);
}
Bug#863707: simple-tpm-pk11: FTBFS: ./m4/test-driver: line 107: 4695 Aborted (core dumped)
Thanks for the report. Do you have a VM in which upstream (Thomas Habets) could reproduce the failure? Or any other details about the setup that might help? On Tue, May 30, 2017 at 10:43 AM, Chris Lamb wrote: > Source: simple-tpm-pk11 > Version: 0.06-1 > Severity: serious > Justification: fails to build from source > User: reproducible-bui...@lists.alioth.debian.org > Usertags: ftbfs > X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org > > Dear Maintainer, > > simple-tpm-pk11 fails to build from source in unstable/amd64: > > […] > > /bin/bash ./libtool --tag=CXX --mode=link g++ -I/usr/src/gtest > -std=gnu++0x -Wall -g -O2 -fdebug-prefix-map=«BUILDDIR»=. > -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro > -Wl,-z,now -o stpm-verify_test src/stpm_verify_test-verify.o > src/stpm_verify_test-verify_test.o src/stpm_verify_test-common.o > src/stpm_verify_test-tspiwrap.o src/stpm_verify_test-fake_tspi.o > src/stpm_verify_test-libgtest.o -lpthread -lcrypto -ltspi > libtool: link: g++ -I/usr/src/gtest -std=gnu++0x -Wall -g -O2 > -fdebug-prefix-map=«BUILDDIR»=. -fstack-protector-strong -Wformat > -Werror=format-security -Wl,-z -Wl,relro -Wl,-z -Wl,now -o stpm-verify_test > src/stpm_verify_test-verify.o src/stpm_verify_test-verify_test.o > src/stpm_verify_test-common.o src/stpm_verify_test-tspiwrap.o > src/stpm_verify_test-fake_tspi.o src/stpm_verify_test-libgtest.o > -lpthread -lcrypto -ltspi > make[3]: Leaving directory '«BUILDDIR»' > make check-TESTS > make[3]: Entering directory '«BUILDDIR»' > make[4]: Entering directory '«BUILDDIR»' > ./m4/test-driver: line 107: 4695 Aborted (core dumped) > "$@" > $log_file 2>&1 > FAIL: stpm-keygen_test > PASS: stpm-sign_test > PASS: common_test > PASS: pk11_test > PASS: stpm-verify_test > > simple-tpm-pk11 0.06: ./test-suite.log > > > # TOTAL: 5 > # PASS: 4 > # SKIP: 0 > # XFAIL: 0 > # FAIL: 1 > # XPASS: 0 > # ERROR: 0 > > .. contents:: :depth: 2 > > FAIL: stpm-keygen_test > == > > Running main() from gtest_main.cc > [==] Running 8 tests from 2 test cases. > [--] Global test environment set-up. > [--] 2 tests from Usage > [ RUN ] Usage.NoOpts > [ OK ] Usage.NoOpts (0 ms) > [ RUN ] Usage.HelpOpts > [ OK ] Usage.HelpOpts (0 ms) > [--] 2 tests from Usage (0 ms total) > > [--] 6 tests from Keygen > [ RUN ] Keygen.EmptyOutputName > [ OK ] Keygen.EmptyOutputName (0 ms) > [ RUN ] Keygen.BadOutputName > [ OK ] Keygen.BadOutputName (1 ms) > [ RUN ] Keygen.OK > [ OK ] Keygen.OK (2 ms) > [ RUN ] Keygen.SWKeyOK > [ OK ] Keygen.SWKeyOK (14 ms) > [ RUN ] Keygen.SmallerKey > [ OK ] Keygen.SmallerKey (1 ms) > [ RUN ] Keygen.WrongTPMKeySize > [ OK ] Keygen.WrongTPMKeySize (2 ms) > [--] 6 tests from Keygen (20 ms total) > > [--] Global test environment tear-down > [==] 8 tests from 2 test cases ran. (20 ms total) > [ PASSED ] 8 tests. > > [ FATAL ] /usr/include/gtest/internal/gtest-port.h:2044:: > pthread_key_delete(key_)failed with error 22 > FAIL stpm-keygen_test (exit status: 134) > > > > Testsuite summary for simple-tpm-pk11 0.06 > > > # TOTAL: 5 > # PASS: 4 > # SKIP: 0 > # XFAIL: 0 > # FAIL: 1 > # XPASS: 0 > # ERROR: 0 > > > See ./test-suite.log > Please report to tho...@habets.se > > > Makefile:1695: recipe for target 'test-suite.log' failed > make[4]: *** [test-suite.log] Error 1 > make[4]: Leaving directory '«BUILDDIR»' > Makefile:1801: recipe for target 'check-TESTS' failed > make[3]: *** [check-TESTS] Error 2 > make[3]: Leaving directory '«BUILDDIR»' > Makefile:2060: recipe for target 'check-am' failed > make[2]: *** [check-am] Error 2 > make[2]: Leaving directory '«BUILDDIR»' > Makefile:1581: recipe for target 'check-recursive' failed > make[1]: *** [check-recursive] Error 1 > make[1]: Leaving directory '«BUILDDIR»' > dh_auto_test: make -j1 check VERBOSE=1 returned exit code 2 > debian/rules:24: recipe for target 'build' failed > make: *** [build] Error 2 > dpkg-buildpackage: error: debian/rules build gave error exit status 2 > > […] > > The full build log is attached. > > > Regards, > > -- > ,''`. > : :' : Chris Lamb > `. `'` la...@debian.org / chris-lamb.co.uk >`- > -- Best regards, Michael
Bug#863673: [Pkg-freeradius-maintainers] Bug#863673: CVE-2017-9148: FreeRADIUS TLS resumption authentication bypass
Upstream confirmed that my patch fixes the issue, so I uploaded it to unstable. See also https://anonscm.debian.org/cgit/pkg-freeradius/freeradius.git/commit/?id=8d681449aa95ee4388b5e3c266bdb070a264f563 security-team, can you take care of applying the patch to stable and oldstable please? Thank you. On Tue, May 30, 2017 at 8:29 AM, Michael Stapelberg wrote: > control: owner -1 ! > > I prepared a patch for this issue and emailed the FreeRADIUS security team > asking for review. I’ll upload the patch once they confirm its > effectiveness. > > On Mon, May 29, 2017 at 11:16 PM, Guido Günther wrote: > >> Package: freeradius >> Version: 3.0.12+dfsg-4 >> severity: grave >> >> Hi, >> >> the following vulnerability was published for freeradius. >> >> CVE-2017-9148[0]: FreeRADIUS TLS resumption authentication bypass >> >> If you fix the vulnerability please also make sure to include the >> CVE (Common Vulnerabilities & Exposures) id in your changelog entry. >> >> For further information see: >> >> [0] https://security-tracker.debian.org/tracker/CVE-2017-9148 >> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9148 >> >> Please adjust the affected versions in the BTS as needed. >> Cheers, >> -- Guido >> >> ___ >> Pkg-freeradius-maintainers mailing list >> pkg-freeradius-maintain...@lists.alioth.debian.org >> https://lists.alioth.debian.org/mailman/listinfo/pkg-freerad >> ius-maintainers >> > > > > -- > Best regards, > Michael > -- Best regards, Michael
Bug#863673: [Pkg-freeradius-maintainers] Bug#863673: CVE-2017-9148: FreeRADIUS TLS resumption authentication bypass
control: owner -1 ! I prepared a patch for this issue and emailed the FreeRADIUS security team asking for review. I’ll upload the patch once they confirm its effectiveness. On Mon, May 29, 2017 at 11:16 PM, Guido Günther wrote: > Package: freeradius > Version: 3.0.12+dfsg-4 > severity: grave > > Hi, > > the following vulnerability was published for freeradius. > > CVE-2017-9148[0]: FreeRADIUS TLS resumption authentication bypass > > If you fix the vulnerability please also make sure to include the > CVE (Common Vulnerabilities & Exposures) id in your changelog entry. > > For further information see: > > [0] https://security-tracker.debian.org/tracker/CVE-2017-9148 > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9148 > > Please adjust the affected versions in the BTS as needed. > Cheers, > -- Guido > > ___ > Pkg-freeradius-maintainers mailing list > pkg-freeradius-maintain...@lists.alioth.debian.org > https://lists.alioth.debian.org/mailman/listinfo/pkg- > freeradius-maintainers > -- Best regards, Michael
Bug#860608: [pkg-golang-devel] Bug#860608: Bug#860608: golang: FTBFS: Go version is "go1.6.1", ignoring -next /<>/api/next.txt
On Tue, May 16, 2017 at 6:46 AM, Steve Langasek wrote: > On Mon, May 15, 2017 at 03:17:03PM -0700, Steve Langasek wrote: > > On Mon, May 15, 2017 at 08:56:08AM +0200, Michael Stapelberg wrote: > > > >> Package: golang-github-gosexy-gettext-dev > > > > > vorlon, can we file for removal of this package? It wasn’t touched > since > > > > 2013 and has no rdepends. > > > > Done: https://bugs.debian.org/862612 > > > Thanks for filing, 100% agreed. > > So, I double checked and: > > $ dak rm -R -n -s unstable golang-github-gosexy-gettext > Will remove the following packages from unstable: > > golang-github-gosexy-gettext | 0~git20130221-1 | source > golang-github-gosexy-gettext-dev | 0~git20130221-1 | all > > Maintainer: Steve Langasek > > --- Reason --- > > -- > > Checking reverse dependencies... > # Broken Build-Depends: > snapd: golang-github-gosexy-gettext-dev > Thanks for checking. I just realized I only checked using “apt rdepends”, which of course won’t consider build-deps. Doh. > > Dependency problem found. > > $ > > It certainly appears that we are still using this package, so I'm closing > the bug report. (I wouldn't expect the ftpmasters to act on it in its > current state anyway.) > > And I've uploaded a no-change rebuild of golang-github-gosexy-gettext-dev. > > -- > Steve Langasek Give me a lever long enough and a Free OS > Debian Developer to set it on, and I can move the world. > Ubuntu Developerhttp://www.debian.org/ > slanga...@ubuntu.com vor...@debian.org > -- Best regards, Michael
Bug#860608: [pkg-golang-devel] Bug#860608: Bug#860608: golang: FTBFS: Go version is "go1.6.1", ignoring -next /<>/api/next.txt
On Sat, May 6, 2017 at 2:20 PM, Michael Stapelberg wrote: > > > On Tue, May 2, 2017 at 10:23 AM, Michael Hudson-Doyle < > michael.hud...@canonical.com> wrote: > >> On 2 May 2017 at 19:23, Michael Stapelberg wrote: >> >>> Sorry for the late reply, I’ve been swamped. >>> >>> On Fri, Apr 21, 2017 at 10:28 AM, Niels Thykier >>> wrote: >>> >>>> Michael Stapelberg: >>>> > On Fri, Apr 21, 2017 at 9:45 AM, Niels Thykier >>>> wrote: >>>> > >>>> >> [...] >>>> >>> >>>> >> >>>> >> They seem to be arch:all packages. We cannot binNMU arch:all >>>> packages, >>>> >> only architecture dependent ones. :-/ >>>> >> >>>> > >>>> > Okay. How do you suggest we rectify this issue instead, then? >>>> > >>>> >>>> A (possibly "no change") sourceful upload to force a rebuild of the >>>> arch:all package. >>>> >>> >>> A sourceful upload for which source package? src:golang has been removed >>> from unstable and testing since 2016-10. >>> >> >> Well, for this bug report specifically, the packages that have a >> built-using on golang 2:1.6.1-2, i.e. these: >> > > Thanks, now I get it :). > > >> >> mwhudson@aeglos:~/tmp$ chdist grep-dctrl-packages sid -FBuilt-Using >> 'golang (= 2:1.6.1-2)' -sPackage >> Package: golang-github-armon-go-metrics-dev >> > > This package has changes in the git repository which aren’t uploaded to > the archive, so it doesn’t build as-is. If someone could take care of this > one, that’d be appreciated. > Uploaded a new version, created from a separate debian/unstable branch. My changes are merged back into master. I hope this was the correct thing to do. > > >> Package: golang-github-gosexy-gettext-dev >> > > vorlon, can we file for removal of this package? It wasn’t touched since > 2013 and has no rdepends. > Done: https://bugs.debian.org/862612 > > >> Package: golang-github-hashicorp-go-msgpack-dev >> Package: golang-github-stretchr-objx-dev >> Package: golang-github-kr-pty-dev >> > > I uploaded new versions of the 3 packages above. Will take care of filing > unblock requests once they entered upstream. > Done: https://bugs.debian.org/862608 https://bugs.debian.org/862609 https://bugs.debian.org/862610 > > The following are already mentioned above: > > >> Package: golang-github-armon-go-metrics-dev >> Package: golang-github-gosexy-gettext-dev >> Package: golang-github-hashicorp-go-msgpack-dev >> Package: golang-github-stretchr-objx-dev >> Package: golang-github-kr-pty-dev >> >> As you can see these are all -dev packages, so the Built-Using is bogus >> and should simply be dropped from the package. >> >> There are quite a few more packages that reference obsolete golang >> packages in their Built-Using... >> >> Cheers, >> mwh >> >> >>> To avoid further delays, is this something you could NMU for us? If so, >>> I’d much appreciate that. Thanks! >>> >>> -- >>> Best regards, >>> Michael >>> >>> ___ >>> pkg-golang-devel mailing list >>> pkg-golang-de...@lists.alioth.debian.org >>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-golang-devel >>> >> >> > > > -- > Best regards, > Michael > -- Best regards, Michael
Bug#851877: fails every time
On Sun, May 14, 2017 at 7:59 AM, Adam Borowski wrote: > On Sat, May 13, 2017 at 08:44:15PM +0200, Michael Stapelberg wrote: > > Sorry for the late reply. > > > > Adam, could you run the attached example program (derived from the > > getaddrinfo and getnameinfo manpages) please? The output should help us > > narrow down whether the problem is with the application code of sslh or > > something in the environment. > > > > Use: gcc -Wall -o gai gai.c && ./gai localhost 9002 > > On all three machines, it looks fine: > . > printing getaddrinfo(localhost, 9002) results: > > ai_family = 10 > ai_socktype = 2 > ai_protocol = 17 > rp->ai_addrlen = 28 > host=::1, serv=9002 > > ai_family = 2 > ai_socktype = 2 > ai_protocol = 17 > rp->ai_addrlen = 16 > host=127.0.0.1, serv=9002 > > done > ` > This seems correct. > > Inside the chroot: > . > [/srv/sbuild/stretch-armhf/tmp]# cp -p /tmp/gai . > [/srv/sbuild/stretch-armhf/tmp]# chroot .. > (stretch-armhf-sbuild)root@kholdan:/# tmp/gai localhost 9002 > printing getaddrinfo(localhost, 9002) results: > > ai_family = 2 > ai_socktype = 2 > ai_protocol = 17 > rp->ai_addrlen = 16 > host=127.0.0.1, serv=9002 > > ai_family = 2 > ai_socktype = 2 > ai_protocol = 17 > rp->ai_addrlen = 16 > host=127.0.0.1, serv=9002 > > done > ` > This seems incorrect: the results are two IPv4 addresses (127.0.0.1:9002) as opposed to one IPv6 and one IPv4 address (or just one IPv4 address). I can actually reproduce this issue on abel.debian.org (armhf porterbox): On abel, my gai test program returns ::1, 127.0.0.1. On abel within an schroot, my gai test program returns 127.0.0.1, 127.0.0.1. Looking at /etc/hosts within the schroot, I see: 127.0.0.1 localhost 127.0.0.1 localhost ip6-localhost ip6-loopback 172.28.17.11abel.debian.org abel Modifying /etc/hosts by replacing ::1 with 127.0.0.1 results in being able to reproduce the issue on other machines as well. This has already caused issues in other packages (e.g. rustc), and is tracked as Debian bug #842634. Now, the next question is: where does this /etc/hosts come from? The file is present in the above form directly after unpacking the schroot tarball, before even entering the schroot: abel% sessionid=$(schroot -b -c sid) abel% cat /srv/chroot/schroot-unpack/$sessionid/etc/hosts 127.0.0.1 localhost 127.0.0.1 localhost ip6-localhost ip6-loopback 172.28.17.11abel.debian.org abel Running debootstrap does not produce an /etc/hosts in --variant=minbase and --variant=buildd. When run without --variant, it does produce an /etc/hosts, but that looks correct: midna% sudo debootstrap --variant=minbase stretch /tmp/bootstrap http://deb.debian.org/debian midna% cat /tmp/bootstrap/etc/hosts cat: /tmp/bootstrap/etc/hosts: No such file or directory midna% sudo rm -rf /tmp/bootstrap midna% sudo debootstrap stretch /tmp/bootstrap http://deb.debian.org/debian midna% cat /tmp/bootstrap/etc/hosts 127.0.0.1 localhost ::1 localhost ip6-localhost ip6-loopback ff02::1 ip6-allnodes ff02::2 ip6-allrouters So, where does the file get mangled? I can’t find any traces in the schroot and sbuild sources. Does anyone know by chance? > > > Meow! > -- > Don't be racist. White, amber or black, all beers should be judged based > solely on their merits. Heck, even if occasionally a cider applies for a > beer's job, why not? > On the other hand, corpo lager is not a race. > -- Best regards, Michael
Bug#851877: fails every time
Sorry for the late reply.
Adam, could you run the attached example program (derived from the
getaddrinfo and getnameinfo manpages) please? The output should help us
narrow down whether the problem is with the application code of sslh or
something in the environment.
Use: gcc -Wall -o gai gai.c && ./gai localhost 9002
Thanks.
On Sat, May 6, 2017 at 8:57 PM, Adam Borowski wrote:
> On Sat, May 06, 2017 at 08:00:11PM +0200, Michael Stapelberg wrote:
> > Thanks. It seems like getaddrinfo() is returning two results when
> resolving
> > localhost. Can you provide the contents of your hostname
> resolution-related
> > configuration please? I.e., /etc/hosts, /etc/resolv.conf,
> > /etc/nsswitch.conf, anything else you might have tweaked in that area.
>
> nsswitch.conf: always default.
>
>
> amd64 (100% fails on all chroots):
> .--[ /etc/hosts ]
> 127.0.0.1 localhost
> 127.0.1.1 umbar.angband.plumbar
> #lots of commented out stuff
>
> # The following lines are desirable for IPv6 capable hosts
> ::1 localhost ip6-localhost ip6-loopback
> ff02::1 ip6-allnodes
> ff02::2 ip6-allrouters
> +--[ /etc/resolv.conf ]
> domain angband.pl
> search angband.pl
> nameserver 2001:6a0:118::3:2
> `
>
> armhf (100% fails on all chroots):
> .--[ /etc/hosts ]
> 127.0.0.1 localhost
> ::1 localhost ip6-localhost ip6-loopback
> fe00::0 ip6-localnet
> ff00::0 ip6-mcastprefix
> ff02::1 ip6-allnodes
> ff02::2 ip6-allrouters
>
> 127.0.0.1 kholdan kholdan.angband.pl
> 2001:6a0:118::3:6 narchost
> #2001:6a0:118::3:3 apt.angband.pl
> +--[ /etc/resolv.conf ]
> domain angband.pl
> search angband.pl
> nameserver 10.0.1.2
> `
>
> arm64 (100% ok on all chroots):
> .--[ /etc/hosts ]
> 127.0.0.1 localhost
> 127.0.1.1 sirius.angband.pl sirius
>
> # The following lines are desirable for IPv6 capable hosts
> ::1 localhost ip6-localhost ip6-loopback
> fe00::0 ip6-localnet
> ff00::0 ip6-mcastprefix
> ff02::1 ip6-allnodes
> ff02::2 ip6-allrouters
> +--[ /etc/resolv.conf ]
> domain angband.pl
> nameserver 10.0.1.2
> nameserver 2001:6a0:118::3:2
> `
>
> (10.0.1.2 is same as 2001:6a0:118::3:2)
>
> --
> Don't be racist. White, amber or black, all beers should be judged based
> solely on their merits. Heck, even if occasionally a cider applies for a
> beer's job, why not?
> On the other hand, corpo lager is not a race.
>
--
Best regards,
Michael
#include
#include
#include
#include
#include
#include
#include
int main(int argc, char *argv[]) {
struct addrinfo hints;
struct addrinfo *result, *rp;
int s;
if (argc < 3) {
fprintf(stderr, "Usage: %s host port...\n", argv[0]);
exit(EXIT_FAILURE);
}
/* Obtain address(es) matching host/port */
memset(&hints, 0, sizeof(struct addrinfo));
hints.ai_family = AF_UNSPEC;/* Allow IPv4 or IPv6 */
hints.ai_socktype = SOCK_DGRAM; /* Datagram socket */
hints.ai_flags = 0;
hints.ai_protocol = 0; /* Any protocol */
s = getaddrinfo(argv[1], argv[2], &hints, &result);
if (s != 0) {
fprintf(stderr, "getaddrinfo: %s\n", gai_strerror(s));
exit(EXIT_FAILURE);
}
printf("printing getaddrinfo(%s, %s) results:\n", argv[1], argv[2]);
printf("\n");
for (rp = result; rp != NULL; rp = rp->ai_next) {
printf(" ai_family = %d\n", rp->ai_family);
printf(" ai_socktype = %d\n", rp->ai_socktype);
printf(" ai_protocol = %d\n", rp->ai_protocol);
printf(" rp->ai_addrlen = %d\n", rp->ai_addrlen);
char hbuf[NI_MAXHOST], sbuf[NI_MAXSERV];
if (getnameinfo(rp->ai_addr, rp->ai_addrlen, hbuf, sizeof(hbuf), sbuf, sizeof(sbuf), NI_NUMERICHOST | NI_NUMERICSERV) == 0)
printf("host=%s, serv=%s\n", hbuf, sbuf);
printf("\n");
}
printf("done\n");
}
Bug#851877: fails every time
Thanks. It seems like getaddrinfo() is returning two results when resolving
localhost. Can you provide the contents of your hostname resolution-related
configuration please? I.e., /etc/hosts, /etc/resolv.conf,
/etc/nsswitch.conf, anything else you might have tweaked in that area.
On Sat, May 6, 2017 at 7:15 PM, Adam Borowski wrote:
> On Sat, May 06, 2017 at 06:38:19PM +0200, Michael Stapelberg wrote:
> > Thanks for the strace. We can see that sslh creates two sockets of the
> same
> > address family, on the same host and port:
> >
> > […]
> > [pid 23812] socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 3
> > [pid 23812] setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
> > [pid 23812] setsockopt(3, SOL_IP, IP_FREEBIND, [1], 4) = 0
> > [pid 23812] bind(3, {sa_family=AF_INET, sin_port=htons(37229),
> > sin_addr=inet_addr("127.0.0.1")}, 16) = 0
> > [pid 23812] listen(3, 50) = 0
> > [pid 23812] socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 4
> > [pid 23812] setsockopt(4, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
> > [pid 23812] setsockopt(4, SOL_IP, IP_FREEBIND, [1], 4) = 0
> > [pid 23812] bind(4, {sa_family=AF_INET, sin_port=htons(37229),
> > sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EADDRINUSE (Address already
> in
> > use)
> > […]
> >
> > Does the attached patch help by any chance? If not, could you supply a
> new
> > strace file, with both patches applied please?
>
> No help; strace attached.
>
>
> Meow!
> --
> Don't be racist. White, amber or black, all beers should be judged based
> solely on their merits. Heck, even if occasionally a cider applies for a
> beer's job, why not?
> On the other hand, corpo lager is not a race.
>
--
Best regards,
Michael
Bug#851877: fails every time
Thanks for the strace. We can see that sslh creates two sockets of the same
address family, on the same host and port:
[…]
[pid 23812] socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 3
[pid 23812] setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
[pid 23812] setsockopt(3, SOL_IP, IP_FREEBIND, [1], 4) = 0
[pid 23812] bind(3, {sa_family=AF_INET, sin_port=htons(37229),
sin_addr=inet_addr("127.0.0.1")}, 16) = 0
[pid 23812] listen(3, 50) = 0
[pid 23812] socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 4
[pid 23812] setsockopt(4, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
[pid 23812] setsockopt(4, SOL_IP, IP_FREEBIND, [1], 4) = 0
[pid 23812] bind(4, {sa_family=AF_INET, sin_port=htons(37229),
sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EADDRINUSE (Address already in
use)
[…]
Does the attached patch help by any chance? If not, could you supply a new
strace file, with both patches applied please?
On Sat, May 6, 2017 at 5:33 PM, Adam Borowski wrote:
> On Sat, May 06, 2017 at 04:57:09PM +0200, Michael Stapelberg wrote:
> > On Sat, May 6, 2017 at 4:02 PM, Adam Borowski
> wrote:
> >
> > > On Sat, May 06, 2017 at 03:44:42PM +0200, Michael Stapelberg wrote:
> > > > I pushed a commit adding a patch which fixes the test by picking an
> > > > unused port. The mechanism is not atomic (i.e., the port is picked by
> > > > the test process, as opposed to the listening process itself and
> > > > communicated back to the test process), but it’s an improvement and
> > > > should fix the issue at hand.
> > > >
> > > > gui, could you take care of preparing a new upload, and filing the
> > > > unblock request? Let me know if you don’t have time for it, and I
> can do
> > > > an NMU.
> > > >
> > > > For your convenience, I have also attached the patch to this message.
> > >
> > > > create mode 100644 debian/patches/fix-ftbfs-static-port.patch
> > >
> > > Nope, I'm afraid it still fails.
> > >
> >
> > Huh. Can you attach an strace of running the tests please?
>
> Sure, 'ere you go.
>
> > Do you have any funky business going on with regards to your IPv4/IPv6
> > setup?
>
> .--[ armhf that fails ]
> auto lo
> iface lo inet loopback
>
> auto eth0
> iface eth0 inet6 static
> address 2001:6a0:118::5
> netmask 64
> gateway 2001:6a0:118::90
> iface eth0 inet static
> address 10.0.1.5
> netmask 255.255.255.0
> gateway 10.0.1.90
> +--[ arm64 that succeeds (chroots: armhf arm64) ]
> auto lo
> iface lo inet loopback
>
> auto eth0
> iface eth0 inet static
> address 10.0.1.9
> netmask 255.255.255.0
> gateway 10.0.1.90
> iface eth0 inet6 static
> address 2001:6a0:118::9
> netmask 64
> gateway 2001:6a0:118::90
> `
>
> The amd64 box (chroots: amd64 i386 x32 armhf/qemu-user arm64/qemu-user) has
> br0 that's the only configured and up interface, all other config is
> dormant.
> Virtual machines are also boring.
>
>
> > Firewall rules?
>
> [~]# iptables -L
> Chain INPUT (policy ACCEPT)
> target prot opt source destination
>
> Chain FORWARD (policy ACCEPT)
> target prot opt source destination
>
> Chain OUTPUT (policy ACCEPT)
> target prot opt source destination
> [~]# iptables -L -t nat
> Chain PREROUTING (policy ACCEPT)
> target prot opt source destination
>
> Chain INPUT (policy ACCEPT)
> target prot opt source destination
>
> Chain OUTPUT (policy ACCEPT)
> target prot opt source destination
>
> Chain POSTROUTING (policy ACCEPT)
> target prot opt source destination
>
>
> Meow!
> --
> Don't be racist. White, amber or black, all beers should be judged based
> solely on their merits. Heck, even if occasionally a cider applies for a
> beer's job, why not?
> On the other hand, corpo lager is not a race.
>
--
Best regards,
Michael
From d9855452c9a3dc3063653c4ee80d3f82fb363ea7 Mon Sep 17 00:00:00 2001
From: Michael Stapelberg
Date: Sat, 6 May 2017 18:31:03 +0200
Subject: [PATCH] add addr_family.patch
---
debian/patches/addr_family.patch | 23 +++
debian/patches/series| 1 +
2 files changed, 24 insertions(+)
create mode 100644 debian/patches/addr_family.patch
diff --git a/debian/patches/addr_family.patch b/debian/patches/addr_family.patch
new file mode 100644
index 000..5311498
--- /dev/null
+++ b/debian/patches/addr_family.patch
@@ -0,0 +1,23 @@
+Index: sslh/common.c
+===
Bug#851877: fails every time
On Sat, May 6, 2017 at 4:02 PM, Adam Borowski wrote: > On Sat, May 06, 2017 at 03:44:42PM +0200, Michael Stapelberg wrote: > > I pushed a commit adding a patch which fixes the test by picking an > > unused port. The mechanism is not atomic (i.e., the port is picked by > > the test process, as opposed to the listening process itself and > > communicated back to the test process), but it’s an improvement and > > should fix the issue at hand. > > > > gui, could you take care of preparing a new upload, and filing the > > unblock request? Let me know if you don’t have time for it, and I can do > > an NMU. > > > > For your convenience, I have also attached the patch to this message. > > > create mode 100644 debian/patches/fix-ftbfs-static-port.patch > > Nope, I'm afraid it still fails. > Huh. Can you attach an strace of running the tests please? Do you have any funky business going on with regards to your IPv4/IPv6 setup? Firewall rules? -- Best regards, Michael
Bug#851877: fails every time
control: tags -1 + pending
Hi,
Tomasz Buchert writes:
> On 04/05/17 04:47, Adam Borowski wrote:
>> [...]
>
> I cannot reproduce these failures. I've built in my stretch sbuild
> around 15 times, and succedeed every time.
>
> I use:
> gbp buildpackage --git-builder='sbuild --source-only-changes -v -As
> --build-dep-resolver=apt --dist=stretch -j4' "$@"
The issue is reproducible as soon as something starts listening on port
9002 (e.g. nc -l -p 9002).
I pushed a commit adding a patch which fixes the test by picking an
unused port. The mechanism is not atomic (i.e., the port is picked by
the test process, as opposed to the listening process itself and
communicated back to the test process), but it’s an improvement and
should fix the issue at hand.
gui, could you take care of preparing a new upload, and filing the
unblock request? Let me know if you don’t have time for it, and I can do
an NMU.
For your convenience, I have also attached the patch to this message.
--
Best regards,
Michael
>From 243bb3faa682afa8168664eaf5a4f72cfc21ee27 Mon Sep 17 00:00:00 2001
From: Michael Stapelberg
Date: Sat, 6 May 2017 15:15:44 +0200
Subject: [PATCH] Add fix-ftbfs-static-port.patch
Closes: #851877
---
debian/patches/fix-ftbfs-static-port.patch | 35 ++
debian/patches/series | 1 +
2 files changed, 36 insertions(+)
create mode 100644 debian/patches/fix-ftbfs-static-port.patch
diff --git a/debian/patches/fix-ftbfs-static-port.patch b/debian/patches/fix-ftbfs-static-port.patch
new file mode 100644
index 000..5d5a9f0
--- /dev/null
+++ b/debian/patches/fix-ftbfs-static-port.patch
@@ -0,0 +1,35 @@
+Index: sslh/t
+===
+--- sslh.orig/t
sslh/t
+@@ -4,14 +4,24 @@
+
+ use strict;
+ use IO::Socket::INET6;
++use IO::Socket::INET;
+ use Test::More qw/no_plan/;
+
+-# We use ports 9000, 9001 and 9002 -- hope that won't clash
+-# with anything...
+-my $ssh_address = "::1:9000";
+-my $ssl_address = "::1:9001";
+-my $sslh_port = 9002;
+-my $no_listen = 9003; # Port on which no-one listens
++sub get_unused_port {
++my $sock = IO::Socket::INET->new(
++Listen => 1,
++LocalAddr => 'localhost',
++ReuseAddr => 1,
++);
++my $port = $sock->sockport();
++$sock->shutdown(2);
++return $port;
++}
++
++my $ssh_address = "::1:" . get_unused_port();
++my $ssl_address = "::1:" . get_unused_port();
++my $sslh_port = get_unused_port();
++my $no_listen = get_unused_port(); # Port on which no-one listens
+ my $pidfile = "/tmp/sslh_test.pid";
+
+ # Which tests do we run
diff --git a/debian/patches/series b/debian/patches/series
index 677eb75..faf6fff 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -2,3 +2,4 @@ fixed_version.diff
disable_valgrind_launch.diff
ftbfs_localhost.diff
transparent_mode_local.diff
+fix-ftbfs-static-port.patch
--
2.11.0
Bug#860608: [pkg-golang-devel] Bug#860608: Bug#860608: golang: FTBFS: Go version is "go1.6.1", ignoring -next /<>/api/next.txt
On Tue, May 2, 2017 at 10:23 AM, Michael Hudson-Doyle < michael.hud...@canonical.com> wrote: > On 2 May 2017 at 19:23, Michael Stapelberg wrote: > >> Sorry for the late reply, I’ve been swamped. >> >> On Fri, Apr 21, 2017 at 10:28 AM, Niels Thykier >> wrote: >> >>> Michael Stapelberg: >>> > On Fri, Apr 21, 2017 at 9:45 AM, Niels Thykier >>> wrote: >>> > >>> >> [...] >>> >>> >>> >> >>> >> They seem to be arch:all packages. We cannot binNMU arch:all >>> packages, >>> >> only architecture dependent ones. :-/ >>> >> >>> > >>> > Okay. How do you suggest we rectify this issue instead, then? >>> > >>> >>> A (possibly "no change") sourceful upload to force a rebuild of the >>> arch:all package. >>> >> >> A sourceful upload for which source package? src:golang has been removed >> from unstable and testing since 2016-10. >> > > Well, for this bug report specifically, the packages that have a > built-using on golang 2:1.6.1-2, i.e. these: > Thanks, now I get it :). > > mwhudson@aeglos:~/tmp$ chdist grep-dctrl-packages sid -FBuilt-Using > 'golang (= 2:1.6.1-2)' -sPackage > Package: golang-github-armon-go-metrics-dev > This package has changes in the git repository which aren’t uploaded to the archive, so it doesn’t build as-is. If someone could take care of this one, that’d be appreciated. > Package: golang-github-gosexy-gettext-dev > vorlon, can we file for removal of this package? It wasn’t touched since 2013 and has no rdepends. > Package: golang-github-hashicorp-go-msgpack-dev > Package: golang-github-stretchr-objx-dev > Package: golang-github-kr-pty-dev > I uploaded new versions of the 3 packages above. Will take care of filing unblock requests once they entered upstream. The following are already mentioned above: > Package: golang-github-armon-go-metrics-dev > Package: golang-github-gosexy-gettext-dev > Package: golang-github-hashicorp-go-msgpack-dev > Package: golang-github-stretchr-objx-dev > Package: golang-github-kr-pty-dev > > As you can see these are all -dev packages, so the Built-Using is bogus > and should simply be dropped from the package. > > There are quite a few more packages that reference obsolete golang > packages in their Built-Using... > > Cheers, > mwh > > >> To avoid further delays, is this something you could NMU for us? If so, >> I’d much appreciate that. Thanks! >> >> -- >> Best regards, >> Michael >> >> ___ >> pkg-golang-devel mailing list >> pkg-golang-de...@lists.alioth.debian.org >> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-golang-devel >> > > -- Best regards, Michael
Bug#860608: [pkg-golang-devel] Bug#860608: golang: FTBFS: Go version is "go1.6.1", ignoring -next /<>/api/next.txt
Sorry for the late reply, I’ve been swamped. On Fri, Apr 21, 2017 at 10:28 AM, Niels Thykier wrote: > Michael Stapelberg: > > On Fri, Apr 21, 2017 at 9:45 AM, Niels Thykier > wrote: > > > >> [...] > >>> > >> > >> They seem to be arch:all packages. We cannot binNMU arch:all packages, > >> only architecture dependent ones. :-/ > >> > > > > Okay. How do you suggest we rectify this issue instead, then? > > > > A (possibly "no change") sourceful upload to force a rebuild of the > arch:all package. > A sourceful upload for which source package? src:golang has been removed from unstable and testing since 2016-10. To avoid further delays, is this something you could NMU for us? If so, I’d much appreciate that. Thanks! -- Best regards, Michael
Bug#860608: [pkg-golang-devel] Bug#860608: golang: FTBFS: Go version is "go1.6.1", ignoring -next /<>/api/next.txt
On Fri, Apr 21, 2017 at 9:45 AM, Niels Thykier wrote: > Michael Stapelberg: > > On Wed, Apr 19, 2017 at 12:05 PM, Michael Hudson-Doyle < > > michael.hud...@canonical.com> wrote: > > > >> [...] > >>> 0.7.0+ds-3), golang-protobuf-extensions (= 0+git20150513.fc2b8d3-4) > >>> -- > >>> Package: golang-github-gosexy-gettext-dev > >>> Built-Using: golang (= 2:1.6.1-2) > >>> -- > >>> Package: golang-github-hashicorp-go-msgpack-dev > >>> Built-Using: golang (= 2:1.6.1-2) > >>> -- > >>> Package: golang-github-stretchr-objx-dev > >>> Built-Using: golang (= 2:1.6.1-2) > >>> -- > >>> Package: golang-github-kr-pty-dev > >>> Built-Using: golang (= 2:1.6.1-2) > >>> > >>> This case could be ignored by the rebuild scripts, or binnmus could be > >>> trigerred to get rid of the other versions. I'm not sure it makes sense > >>> to ship > >>> that many copies of golang in stretch. > >>> > >>> I think I read something about an organized plan to get rid of such > extra > >>> packages using binnmus, but maybe I was dreaming. Ccing debian-release@ > . > >>> > >> > >> [...] > >> > > > > Updating or dropping the field seems fine with me. Could you do these 4 > > binNMUs so that we can close out this bug please? :) > > > > They seem to be arch:all packages. We cannot binNMU arch:all packages, > only architecture dependent ones. :-/ > Okay. How do you suggest we rectify this issue instead, then? -- Best regards, Michael
Bug#860608: [pkg-golang-devel] Bug#860608: golang: FTBFS: Go version is "go1.6.1", ignoring -next /<>/api/next.txt
On Wed, Apr 19, 2017 at 12:05 PM, Michael Hudson-Doyle < michael.hud...@canonical.com> wrote: > On 19 April 2017 at 20:55, Lucas Nussbaum wrote: > >> On 19/04/17 at 09:05 +0200, Michael Stapelberg wrote: >> > This is the third time an FTBFS report against this package (which was >> > removed from Debian) was submitted. >> > >> > The other two times were >> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855926 and >> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848806, both were >> closed >> > asking for an explanation as to why the issue was filed in the first >> place. >> >> ... And none sending the question to the bug submitter. > > > Defeated by the Debian BTS, I didn't realize that you had to email the > submitter separately when closing a bug... > > >> >> > lucas, is this a bug in your rebuild infrastructure, or did something go >> > wrong with the removal? >> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839364 (same issue >> as the >> > one you’re reporting) was closed by ftpmaster due to package removal. >> >> In my local Sources file, I have: > > > [...] > > >> 'Extra-Source-Only' means that there are still binary packages in the >> archive >> that were built using that version of the golang package. >> >> In fact, for that version: >> $ grep -e Package -e Using 127.0.0.1\:_debian_dists_t >> esting_main_binary-amd64_Packages |grep -B1 'golang (= 2:1.6.1-2)' >> Package: golang-github-armon-go-metrics-dev >> Built-Using: golang (= 2:1.6.1-2), golang-github-datadog-datadog-go (= >> 0.0~git20150930.0.b050cd8-1), golang-github-prometheus-common (= >> 0+git20160321.4045694-1), golang-goprotobuf (= 0.0~git20160330-1), >> golang-procfs (= 0+git20150616.c91d8ee-1), golang-prometheus-client (= >> 0.7.0+ds-3), golang-protobuf-extensions (= 0+git20150513.fc2b8d3-4) >> -- >> Package: golang-github-gosexy-gettext-dev >> Built-Using: golang (= 2:1.6.1-2) >> -- >> Package: golang-github-hashicorp-go-msgpack-dev >> Built-Using: golang (= 2:1.6.1-2) >> -- >> Package: golang-github-stretchr-objx-dev >> Built-Using: golang (= 2:1.6.1-2) >> -- >> Package: golang-github-kr-pty-dev >> Built-Using: golang (= 2:1.6.1-2) >> >> This case could be ignored by the rebuild scripts, or binnmus could be >> trigerred to get rid of the other versions. I'm not sure it makes sense >> to ship >> that many copies of golang in stretch. >> >> I think I read something about an organized plan to get rid of such extra >> packages using binnmus, but maybe I was dreaming. Ccing debian-release@. >> > > I think I heard something about that. FWIW, though, these Built-Using > fields are bogus, golang -dev packages just ship source and so do not > actually contain anything built by the mentioned version of the compiler. I > think I've managed to hammer this into everyone's heads now but I guess > there are plenty of packages in the archive that haven't had an upload > since then (so I guess the binNMUs could just drop the field?). > Updating or dropping the field seems fine with me. Could you do these 4 binNMUs so that we can close out this bug please? :) -- Best regards, Michael
Bug#860608: golang: FTBFS: Go version is "go1.6.1", ignoring -next /<>/api/next.txt
This is the third time an FTBFS report against this package (which was removed from Debian) was submitted. The other two times were https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855926 and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848806, both were closed asking for an explanation as to why the issue was filed in the first place. lucas, is this a bug in your rebuild infrastructure, or did something go wrong with the removal? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839364 (same issue as the one you’re reporting) was closed by ftpmaster due to package removal. On Wed, Apr 19, 2017 at 8:21 AM, Lucas Nussbaum wrote: > Source: golang > Version: 2:1.6.1-2 > Severity: serious > Tags: stretch sid > User: debian...@lists.debian.org > Usertags: qa-ftbfs-20170418 qa-ftbfs > Justification: FTBFS in stretch on amd64 > > Hi, > > During a rebuild of all packages in stretch (in a stretch chroot, not a > sid chroot), your package failed to build on amd64. > > Relevant part (hopefully): > > make[1]: Entering directory '/<>' > > set -ex; \ > > cd src; \ > > export PATH="/<>/bin:$PATH"; \ > > eval "$(go tool dist env)"; \ > > bash run.bash -k -no-rebuild; > > + cd src > > + export PATH=/<>/bin:/usr/local/sbin:/usr/local/bin: > /usr/sbin:/usr/bin:/sbin:/bin:/usr/games > > + go tool dist env > > + eval CC="gcc" > > CC_FOR_TARGET="gcc" > > GOROOT="/<>" > > GOBIN="/<>/bin" > > GOARCH="amd64" > > GOOS="linux" > > GOHOSTARCH="amd64" > > GOHOSTOS="linux" > > GOTOOLDIR="/<>/pkg/tool/linux_amd64" > > + CC=gcc > > + CC_FOR_TARGET=gcc > > + GOROOT=/<> > > + GOBIN=/<>/bin > > + GOARCH=amd64 > > + GOOS=linux > > + GOHOSTARCH=amd64 > > + GOHOSTOS=linux > > + GOTOOLDIR=/<>/pkg/tool/linux_amd64 > > + bash run.bash -k -no-rebuild > > > > # Testing packages. > > okarchive/tar 0.019s > > okarchive/zip 0.215s > > okbufio 0.193s > > okbytes 0.204s > > okcompress/bzip2 0.247s > > okcompress/flate 0.831s > > okcompress/gzip 0.100s > > okcompress/lzw0.039s > > okcompress/zlib 0.168s > > okcontainer/heap 0.009s > > okcontainer/list 0.038s > > okcontainer/ring 0.017s > > okcrypto/aes 0.083s > > okcrypto/cipher 0.015s > > okcrypto/des 0.085s > > okcrypto/dsa 0.055s > > okcrypto/ecdsa0.072s > > okcrypto/elliptic 0.125s > > okcrypto/hmac 0.024s > > okcrypto/md5 0.047s > > okcrypto/rand 0.050s > > okcrypto/rc4 0.213s > > okcrypto/rsa 0.146s > > okcrypto/sha1 0.049s > > okcrypto/sha256 0.036s > > okcrypto/sha512 0.019s > > okcrypto/subtle 0.008s > > okcrypto/tls 2.594s > > okcrypto/x509 3.088s > > okdatabase/sql0.136s > > okdatabase/sql/driver 0.066s > > okdebug/dwarf 0.039s > > okdebug/elf 0.117s > > okdebug/gosym 0.520s > > okdebug/macho 0.032s > > okdebug/pe0.034s > > okdebug/plan9obj 0.017s > > okencoding/ascii850.088s > > okencoding/asn1 0.021s > > okencoding/base32 0.020s > > okencoding/base64 0.035s > > okencoding/binary 0.043s > > okencoding/csv0.037s > > okencoding/gob0.055s > > okencoding/hex0.048s > > okencoding/json 0.412s > > okencoding/pem0.046s > > okencoding/xml0.024s > > okerrors 0.021s > > okexpvar 0.017s > > okflag0.026s > > okfmt 0.205s > > okgo/ast 0.040s > > okgo/build0.205s > > okgo/constant 0.023s > > okgo/doc 0.125s > > okgo/format 0.041s > > okgo/internal/gccgoimporter 0.013s > > okgo/internal/gcimporter 0.314s > > okgo/parser 0.086s > > okgo/printer 0.716s > > okgo/scanner 0.049s > > okgo/token0.044s > > okgo/types1.656s > > okhash/adler320.032s > > okhash/crc32 0.039s > > okhash/crc64 0.045s > > okhash/fnv0.038s > > okhtml0.019s > > okhtml/template 0.078s > > okimage 0.226s > > okimage/color 0.110s > > okimage/draw 0.117s > > okimage/gif 0.160s > > okimage/jpeg 0.341s > > okimage/png 0.103s > > okindex/suffixarray 0.044s > > okinternal/golang.org/x/net/http2/hpack 0.029s > > okinternal/singleflight 0.062s > > okinternal/trace 0.069s > > okio 0.048s > > okio/ioutil 0.014s > > oklog 0.020s > > oklog/syslog 2.055s > > okmath0.017s > > okmath/big1.017s > > okmath/cmplx 0.009s > > okmath/rand 0.189s > > okmime0.087s > > okmime/multipart 1.560s > > okmime/quotedprintable0.759s > > oknet 1.464s > > oknet/http10.894s > > oknet/http/cgi0.616s > > oknet/http/cookiejar 0.012s > > oknet/http/fcgi 0.009s > > oknet/http/httptest 0.026s > > ok
Bug#855922: [pkg-go] Bug#855922: containerd: 0.2.3 ds1-1 breaks docker 1.11 - unable to start containerd
With runc 1.0.0~rc2+git20161109.131.5137186-2, things indeed work again. Thanks! On Thu, Mar 30, 2017 at 5:26 AM, Potter, Tim wrote: > On 30 Mar 2017, at 3:54 AM, Michael Stapelberg > wrote: > > > > Hi Tim, > > > > "Potter, Tim" writes: > >> Hi Ricardo. Thanks for the bug report. I messed up by uploading some > of the Docker 1.13 > >> dependencies to unstable instead of experimental - my apologies. > >> > >> I've done a new upload with a Breaks line to avoid this bug occurring > until I finish testing > >> 1.13 and uploading to unstable. > > > > I’m still running into this issue (or a very similar one?) with: > > > > docker.io 1.13.0~ds1-2 > > runc 0.1.1+dfsg1-2+b1 > > containerd 0.2.3~git20161117.78.03e5862~ds1-2 > > golang-libnetwork 0.8.0~dev.2+git20161130.568.fd27f22-4 > > > > I installed these packages from Debian unstable, but AFAICT, no newer > > version is available in experimental. > > > > The symptom is: > > $ docker run -t -i debian:sid /bin/bash > > docker: Error response from daemon: containerd: container not started. > > > > In the journal, I can’t see any errors from containerd itself. > > > > Should docker be working in Debian at the moment? If not, is there a > > workaround? > > Hi Michael. I did an upload yesterday to unstable and things should be > working again. > Sorry about the mess in experimental vs unstable. I was trying to keep > both the old > and new version working but failed miserably. > > Please let me know if you find any more brokenness. > > > Tim. > -- Best regards, Michael
Bug#855922: [pkg-go] Bug#855922: containerd: 0.2.3 ds1-1 breaks docker 1.11 - unable to start containerd
Hi Tim, "Potter, Tim" writes: > Hi Ricardo. Thanks for the bug report. I messed up by uploading some of the > Docker 1.13 > dependencies to unstable instead of experimental - my apologies. > > I've done a new upload with a Breaks line to avoid this bug occurring until I > finish testing > 1.13 and uploading to unstable. I’m still running into this issue (or a very similar one?) with: docker.io 1.13.0~ds1-2 runc 0.1.1+dfsg1-2+b1 containerd 0.2.3~git20161117.78.03e5862~ds1-2 golang-libnetwork 0.8.0~dev.2+git20161130.568.fd27f22-4 I installed these packages from Debian unstable, but AFAICT, no newer version is available in experimental. The symptom is: $ docker run -t -i debian:sid /bin/bash docker: Error response from daemon: containerd: container not started. In the journal, I can’t see any errors from containerd itself. Should docker be working in Debian at the moment? If not, is there a workaround? Thanks! -- Best regards, Michael
Bug#857025: [pkg-go] Bug#857025: golang-golang-x-tools FRBFS on armhf: golang.org/x/tools/refactor/satisfy [no test files]
control: owner -1 ! Hi, Michael Hudson-Doyle writes: > and the failure is this: > > === RUN TestImportSymlinks > --- FAIL: TestImportSymlinks (0.03s) > Which, frankly, is a very bizarre test to be arch dependent. It’s not arch-dependent, it’s “just” flaky :). This was fixed upstream: https://github.com/golang/tools/commit/f60b69ed8cd7a29e91f87050ae23a29581a0f367 I’ll cherry-pick this fix into a new upload after having a look at #857024. -- Best regards, Michael
Bug#749272: varnish doesn't source /etc/default/varnish when started with systemd
That sounds like a good idea! On Wed, Mar 1, 2017 at 9:04 PM, Stig Sandbeck Mathisen wrote: > Michael Stapelberg writes: > > > Yet another alternative might be (and it pains me to say that, but > > maybe it’s required to not break people’s setups) to have the service > > file start a wrapper shell script which evaluates /etc/default/varnish > > before starting varnish. > > That could actually be done when upgrading the package from whatever is > in stable currently. > > For instance: If upgrading from 4.0.2-1, add a > /etc/systemd/system/varnish.service.d/upgrade.conf with such a shell > wrapper for people upgrading from the version in current stable. > > Oh, and "ick!", but thanks. :) > > I'd really like to avoid keeping /etc/default/* around for new installs. > > -- > Stig Sandbeck Mathisen > https://fnord.no/ > -- Best regards, Michael
Bug#749272: varnish doesn't source /etc/default/varnish when started with systemd
Yet another alternative might be (and it pains me to say that, but maybe it’s required to not break people’s setups) to have the service file start a wrapper shell script which evaluates /etc/default/varnish before starting varnish. On Wed, Mar 1, 2017 at 7:29 AM, Stig Sandbeck Mathisen wrote: > Michael Stapelberg writes: > > > Hi, > > > > Gregory Colpart writes: > >> tags 749272 - wontfix > >> severity 749272 serious > >> retitle 749272 varnish doesn't source /etc/default/varnish when started > but uses it when reloaded > > > > This bug’s severity now results in varnish and, transitively, > > freeradius being removed from testing, so it warrants timely > > action. Whether that’s a downgrade or a fix is up to the package > > maintainers (ssm?). > > > > FWIW, I think the request to load environment variable files is > > reasonable. It’s not idiomatic for systemd, but it is a widely used > > technique in Debian and will smoothen the transition for our users. > > A problem with /etc/default/varnish is that it is a shell script > fragment, with examples using interpolation, and not just key=value > statements. If someone has used "Alternative 3" for Varnish from that > file, the "reload" script will still fail when using systemd. > > I think a fix for this issue may be: > > * remove the reload action from systemd. > > * Possibly patch the reload script to ensure it does not attempt to run > when using systemd, by checking for the presence of > "/run/systemd/system" and exit with a message if it is present. > > I wrote that reload-vcl script long ago, and it has developed other > problems as varnish has developed, and probably needs to be rewritten > from scratch. > > It needs to synchronize its varnishd command line option parser with > what varnishd may possibly use, and that was last done a long time ago. > > "What should the varnish service actually reload when told to reload" > has multiple options. The VCL file used when starting up? The compiled > VCL from starting up? The VCL file last loaded, etc. > > -- > Stig Sandbeck Mathisen > https://fnord.no/ > -- Best regards, Michael
Bug#749272: varnish doesn't source /etc/default/varnish when started with systemd
Hi, Gregory Colpart writes: > tags 749272 - wontfix > severity 749272 serious > retitle 749272 varnish doesn't source /etc/default/varnish when started but > uses it when reloaded This bug’s severity now results in varnish and, transitively, freeradius being removed from testing, so it warrants timely action. Whether that’s a downgrade or a fix is up to the package maintainers (ssm?). FWIW, I think the request to load environment variable files is reasonable. It’s not idiomatic for systemd, but it is a widely used technique in Debian and will smoothen the transition for our users. In case I don’t hear from any package maintainer until 2017-03-04, I will upload a delayed NMU (applying the supplied patch) and file an unblock request in order to prevent removal from testing. Thanks! -- Best regards, Michael
Bug#851015: nut: FTBFS: a2x: ERROR: missing configuration file: /etc/asciidoc/dblatex/asciidoc-dblatex.xsl
Thanks! Let me know if you can’t get around to it, and I’ll be happy to give a hand. On Thu, Jan 19, 2017 at 8:47 PM, Laurent Bigonville wrote: > Le 19/01/17 à 19:52, Michael Stapelberg a écrit : >> >> [+aquette, bigon directly] >> >> Are you aware of this issue? This RC bug transitively marked freeradius >> for removal from testing. If you need help, please let me know — I have >> some incentive to look into it in order to keep freeradius in stretch. > > Apparently it lacks of asciidoc-dblatex build-dependency > > I'll try do an upload tonight -- Best regards, Michael
Bug#851015: nut: FTBFS: a2x: ERROR: missing configuration file: /etc/asciidoc/dblatex/asciidoc-dblatex.xsl
[+aquette, bigon directly] Are you aware of this issue? This RC bug transitively marked freeradius for removal from testing. If you need help, please let me know — I have some incentive to look into it in order to keep freeradius in stretch. Lucas Nussbaum writes: > Source: nut > Version: 2.7.4-4 > Severity: serious > Tags: stretch sid > User: debian...@lists.debian.org > Usertags: qa-ftbfs-20170111 qa-ftbfs > Justification: FTBFS on amd64 > > Hi, > > During a rebuild of all packages in sid, your package failed to build on > amd64. > > Relevant part (hopefully): >> make[3]: Entering directory '/<>/docs' >> make[3]: Nothing to be done for 'all-am'. >> make[3]: Leaving directory '/<>/docs' >> /usr/bin/a2x --attribute icons --xsltproc-opts "--nonet" --xsltproc-opts >> "--stringparam nut.localdate \"`TZ=UTC date +%Y-%m-%d`\"" --xsltproc-opts >> "--stringparam nut.localtime \"`TZ=UTC date +%H:%M:%S`\"" --xsltproc-opts >> "--stringparam nut.nutversion \"2.7.4\"" --attribute iconsdir=./images >> --attribute=badges --attribute=external_title --attribute tree_version=2.7 >> -a toc -a numbered --destination-dir=. --attribute=chunked_format >> --format=chunked --xsl-file=./chunked.xsl user-manual.txt >> /usr/bin/a2x --attribute icons --xsltproc-opts "--nonet" --xsltproc-opts >> "--stringparam nut.localdate \"`TZ=UTC date +%Y-%m-%d`\"" --xsltproc-opts >> "--stringparam nut.localtime \"`TZ=UTC date +%H:%M:%S`\"" --xsltproc-opts >> "--stringparam nut.nutversion \"2.7.4\"" --attribute iconsdir=./images >> --attribute=badges --attribute=external_title --attribute tree_version=2.7 >> -a toc -a numbered --destination-dir=. --attribute=chunked_format >> --format=chunked --xsl-file=./chunked.xsl developer-guide.txt >> /usr/bin/a2x --attribute icons --xsltproc-opts "--nonet" --xsltproc-opts >> "--stringparam nut.localdate \"`TZ=UTC date +%Y-%m-%d`\"" --xsltproc-opts >> "--stringparam nut.localtime \"`TZ=UTC date +%H:%M:%S`\"" --xsltproc-opts >> "--stringparam nut.nutversion \"2.7.4\"" --attribute iconsdir=./images >> --attribute=badges --attribute=external_title --attribute tree_version=2.7 >> -a toc -a numbered --destination-dir=. --attribute=chunked_format >> --format=chunked --xsl-file=./chunked.xsl packager-guide.txt >> /usr/bin/a2x --attribute icons --xsltproc-opts "--nonet" --xsltproc-opts >> "--stringparam nut.localdate \"`TZ=UTC date +%Y-%m-%d`\"" --xsltproc-opts >> "--stringparam nut.localtime \"`TZ=UTC date +%H:%M:%S`\"" --xsltproc-opts >> "--stringparam nut.nutversion \"2.7.4\"" --attribute iconsdir=./images >> --attribute=badges --attribute=external_title --attribute tree_version=2.7 >> -a toc -a numbered --destination-dir=. --attribute=xhtml11_format >> --format=xhtml --xsl-file=./xhtml.xsl FAQ.txt >> /usr/bin/a2x --attribute icons --xsltproc-opts "--nonet" --xsltproc-opts >> "--stringparam nut.localdate \"`TZ=UTC date +%Y-%m-%d`\"" --xsltproc-opts >> "--stringparam nut.localtime \"`TZ=UTC date +%H:%M:%S`\"" --xsltproc-opts >> "--stringparam nut.nutversion \"2.7.4\"" --attribute iconsdir=./images >> --attribute=badges --attribute=external_title --attribute tree_version=2.7 >> -a toc -a numbered --destination-dir=. --attribute=pdf_format --format=pdf >> -a docinfo1 user-manual.txt >> a2x: WARNING: --destination-dir option is only applicable to HTML based >> outputs >> a2x: ERROR: missing configuration file: >> /etc/asciidoc/dblatex/asciidoc-dblatex.xsl >> Makefile:825: recipe for target 'user-manual.pdf' failed >> make[2]: *** [user-manual.pdf] Error 1 > > The full build log is available from: >http://aws-logs.debian.net/2017/01/11/nut_2.7.4-4_unstable.log > > A list of current common problems and possible solutions is available at > http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! > > About the archive rebuild: The rebuild was done on EC2 VM instances from > Amazon Web Services, using a clean, minimal and up-to-date chroot. Every > failed build was retried once to eliminate random failures. > > -- Best regards, Michael
Bug#846496: golang-go: Cannot dist-upgrade golang-go from Jessie to Stretch
On Thu, Dec 1, 2016 at 7:28 AM, Dave Page wrote: > Package: golang-go.tools > Version: 1:0.0~git20161028.0.b814a3b+ds-3 > Severity: grave > File: golang-go > Justification: renders package unusable > > Dear Maintainer, > > > I am in the middle of a dist-upgrade from jessie to lennie, and the > Did you mean from lenny to jessie? As per https://www.debian.org/releases/stable/i386/release-notes/ch-upgrading.en.html#system-status, Debian only supports upgrades from the previous stable version to the current stable version. I think you need to upgrade lenny → squeeze → wheezy → jessie. > process has broken on golang-go: > > Preparing to unpack .../golang-go_2%3a1.7~1_amd64.deb ... > dpkg-maintscript-helper: error: directory '/usr/lib/go' contains files > not owned by package golang-go:amd64, cannot switch to symlink > dpkg: error processing archive > /var/cache/apt/archives/golang-go_2%3a1.7~1_amd64.deb (--unpack): > subprocess new pre-installation script returned error exit status 1 > Errors were encountered while processing: > /var/cache/apt/archives/golang-go_2%3a1.7~1_amd64.deb > E: Sub-process /usr/bin/dpkg returned an error code (1) > > # dpkg -S /usr/lib/go /usr/lib/go/doc > golang-go, golang-doc: /usr/lib/go > golang-doc: /usr/lib/go/doc > > So it looks like having golang-doc installed alongside, breaks the > upgrade of golang-go. > > Purging golang golang-go golang-doc allowed me to complete the > dist-upgrade. > > -- System Information: > Debian Release: stretch/sid > APT prefers testing > APT policy: (500, 'testing') > Architecture: amd64 (x86_64) > > Kernel: Linux 4.6.0-0.bpo.1-amd64 (SMP w/4 CPU cores) > Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages golang-go.tools depends on: > ii golang-golang-x-tools 1:0.0~git20161028.0.b814a3b+ds-3 > > golang-go.tools recommends no packages. > > golang-go.tools suggests no packages. > > -- no debconf information > -- Best regards, Michael
Bug#839931: [Pkg-freeradius-maintainers] Bug#839931: freeradius-config: fails to upgrade from 'sid' - trying to overwrite /etc/freeradius/clients.conf
Figured out some more details: /etc/freeradius/hints is not listed in DEBIAN/conffiles in freeradius-config 3.0.12+dfsg-1 because it’s a symlink (dh_installdeb uses find -type f to find conffiles). IIUC, that’s the reason why dpkg does not realize that a conffile is moving between two packages here. Now, let’s see how we can fix that… On Mon, Oct 24, 2016 at 10:00 AM, Michael Stapelberg wrote: > I think the issue is that the file(s) in question (e.g. > /etc/freeradius/hints) are marked as conffiles in freeradius > 2.2.8+dfsg-0.1+b3: > > # grep hints /var/lib/dpkg/info/freeradius.* > /var/lib/dpkg/info/freeradius.conffiles:/etc/freeradius/hints > /var/lib/dpkg/info/freeradius.list:/etc/freeradius/hints > /var/lib/dpkg/info/freeradius.postinst: > /etc/freeradius/hints \ > /var/lib/dpkg/info/freeradius.prerm: /etc/freeradius/hints \ > > When updating, the entry vanishes from freeradius.conffiles, but stays in > freeradius.list: > > # dpkg -i freeradius-common_3.0.12+dfsg-1_all.deb > freeradius_3.0.12+dfsg-1_amd64.deb libfreeradius3_3.0.12+dfsg-1_amd64.deb > freeradius-config_3.0.12+dfsg-1_amd64.deb > (Reading database ... 24462 files and directories currently installed.) > Preparing to unpack freeradius-common_3.0.12+dfsg-1_all.deb ... > Unpacking freeradius-common (3.0.12+dfsg-1) over (3.0.12+dfsg-1) ... > Preparing to unpack freeradius_3.0.12+dfsg-1_amd64.deb ... > Unpacking freeradius (3.0.12+dfsg-1) over (2.2.8+dfsg-0.1+b3) ... > dpkg: warning: unable to delete old directory '/etc/freeradius/sites-enabled': > Directory not empty > dpkg: warning: unable to delete old directory > '/etc/freeradius/sites-available': > Directory not empty > dpkg: warning: unable to delete old directory '/etc/freeradius/modules': > Directory not empty > dpkg: warning: unable to delete old directory '/etc/freeradius/certs': > Directory not empty > dpkg: warning: unable to delete old directory '/etc/freeradius': Directory > not empty > Preparing to unpack libfreeradius3_3.0.12+dfsg-1_amd64.deb ... > Unpacking libfreeradius3 (3.0.12+dfsg-1) over (3.0.12+dfsg-1) ... > Preparing to unpack freeradius-config_3.0.12+dfsg-1_amd64.deb ... > Unpacking freeradius-config (3.0.12+dfsg-1) ... > dpkg: error processing archive freeradius-config_3.0.12+dfsg-1_amd64.deb > (--install): > trying to overwrite '/etc/freeradius/hints', which is also in package > freeradius 3.0.12+dfsg-1 > Setting up freeradius-common (3.0.12+dfsg-1) ... > dpkg: dependency problems prevent configuration of freeradius: > freeradius depends on freeradius-config; however: > Package freeradius-config is not installed. > > dpkg: error processing package freeradius (--install): > dependency problems - leaving unconfigured > Setting up libfreeradius3 (3.0.12+dfsg-1) ... > Processing triggers for man-db (2.7.5-1) ... > Processing triggers for systemd (229-1) ... > Errors were encountered while processing: > freeradius-config_3.0.12+dfsg-1_amd64.deb > freeradius > > # grep hints /var/lib/dpkg/info/freeradius.* > /var/lib/dpkg/info/freeradius.list:/etc/freeradius/hints > /var/lib/dpkg/info/freeradius.postinst: > /etc/freeradius/mods-config/preprocess/hints \ > /var/lib/dpkg/info/freeradius.prerm: > /etc/freeradius/mods-config/preprocess/hints > \ > > anbe, do you know how this situation should be properly handled? Do I need > to use rm_conffiles in the maintscripts? > > Thanks! > > On Sat, Oct 15, 2016 at 3:15 PM, Andreas Beckmann wrote: > >> Followup-For: Bug #839931 >> Control: found -1 3.0.12+dfsg-1 >> >> Hi, >> >> there are still file overwrite problems in the latest version: >> >> Preparing to unpack .../07-freeradius_3.0.12+dfsg-1_amd64.deb ... >> Unpacking freeradius (3.0.12+dfsg-1) over (2.2.8+dfsg-0.1+b3) ... >> dpkg: warning: unable to delete old directory >> '/etc/freeradius/sites-enabled': Directory not empty >> dpkg: warning: unable to delete old directory >> '/etc/freeradius/sites-available': Directory not empty >> dpkg: warning: unable to delete old directory >> '/etc/freeradius/modules': Directory not empty >> dpkg: warning: unable to delete old directory '/etc/freeradius/certs': >> Directory not empty >> dpkg: warning: unable to delete old directory '/etc/freeradius': >> Directory not empty >> Selecting previously unselected package freeradius-config. >> Preparing to unpack .../08-freeradius-config_3.0.12+dfsg-1_amd64.deb >> ... >> Unpacking freeradius-config (3.0.12+dfsg-1) ... >> dpkg: error processing archive /tmp/apt-dpkg-install-5B7fDA/0 >
Bug#839931: [Pkg-freeradius-maintainers] Bug#839931: freeradius-config: fails to upgrade from 'sid' - trying to overwrite /etc/freeradius/clients.conf
I think the issue is that the file(s) in question (e.g. /etc/freeradius/hints) are marked as conffiles in freeradius 2.2.8+dfsg-0.1+b3: # grep hints /var/lib/dpkg/info/freeradius.* /var/lib/dpkg/info/freeradius.conffiles:/etc/freeradius/hints /var/lib/dpkg/info/freeradius.list:/etc/freeradius/hints /var/lib/dpkg/info/freeradius.postinst: /etc/freeradius/hints \ /var/lib/dpkg/info/freeradius.prerm: /etc/freeradius/hints \ When updating, the entry vanishes from freeradius.conffiles, but stays in freeradius.list: # dpkg -i freeradius-common_3.0.12+dfsg-1_all.deb freeradius_3.0.12+dfsg-1_amd64.deb libfreeradius3_3.0.12+dfsg-1_amd64.deb freeradius-config_3.0.12+dfsg-1_amd64.deb (Reading database ... 24462 files and directories currently installed.) Preparing to unpack freeradius-common_3.0.12+dfsg-1_all.deb ... Unpacking freeradius-common (3.0.12+dfsg-1) over (3.0.12+dfsg-1) ... Preparing to unpack freeradius_3.0.12+dfsg-1_amd64.deb ... Unpacking freeradius (3.0.12+dfsg-1) over (2.2.8+dfsg-0.1+b3) ... dpkg: warning: unable to delete old directory '/etc/freeradius/sites-enabled': Directory not empty dpkg: warning: unable to delete old directory '/etc/freeradius/sites-available': Directory not empty dpkg: warning: unable to delete old directory '/etc/freeradius/modules': Directory not empty dpkg: warning: unable to delete old directory '/etc/freeradius/certs': Directory not empty dpkg: warning: unable to delete old directory '/etc/freeradius': Directory not empty Preparing to unpack libfreeradius3_3.0.12+dfsg-1_amd64.deb ... Unpacking libfreeradius3 (3.0.12+dfsg-1) over (3.0.12+dfsg-1) ... Preparing to unpack freeradius-config_3.0.12+dfsg-1_amd64.deb ... Unpacking freeradius-config (3.0.12+dfsg-1) ... dpkg: error processing archive freeradius-config_3.0.12+dfsg-1_amd64.deb (--install): trying to overwrite '/etc/freeradius/hints', which is also in package freeradius 3.0.12+dfsg-1 Setting up freeradius-common (3.0.12+dfsg-1) ... dpkg: dependency problems prevent configuration of freeradius: freeradius depends on freeradius-config; however: Package freeradius-config is not installed. dpkg: error processing package freeradius (--install): dependency problems - leaving unconfigured Setting up libfreeradius3 (3.0.12+dfsg-1) ... Processing triggers for man-db (2.7.5-1) ... Processing triggers for systemd (229-1) ... Errors were encountered while processing: freeradius-config_3.0.12+dfsg-1_amd64.deb freeradius # grep hints /var/lib/dpkg/info/freeradius.* /var/lib/dpkg/info/freeradius.list:/etc/freeradius/hints /var/lib/dpkg/info/freeradius.postinst: /etc/freeradius/mods-config/preprocess/hints \ /var/lib/dpkg/info/freeradius.prerm: /etc/freeradius/mods-config/preprocess/hints \ anbe, do you know how this situation should be properly handled? Do I need to use rm_conffiles in the maintscripts? Thanks! On Sat, Oct 15, 2016 at 3:15 PM, Andreas Beckmann wrote: > Followup-For: Bug #839931 > Control: found -1 3.0.12+dfsg-1 > > Hi, > > there are still file overwrite problems in the latest version: > > Preparing to unpack .../07-freeradius_3.0.12+dfsg-1_amd64.deb ... > Unpacking freeradius (3.0.12+dfsg-1) over (2.2.8+dfsg-0.1+b3) ... > dpkg: warning: unable to delete old directory > '/etc/freeradius/sites-enabled': > Directory not empty > dpkg: warning: unable to delete old directory > '/etc/freeradius/sites-available': > Directory not empty > dpkg: warning: unable to delete old directory '/etc/freeradius/modules': > Directory not empty > dpkg: warning: unable to delete old directory '/etc/freeradius/certs': > Directory not empty > dpkg: warning: unable to delete old directory '/etc/freeradius': > Directory not empty > Selecting previously unselected package freeradius-config. > Preparing to unpack .../08-freeradius-config_3.0.12+dfsg-1_amd64.deb ... > Unpacking freeradius-config (3.0.12+dfsg-1) ... > dpkg: error processing archive /tmp/apt-dpkg-install-5B7fDA/ > 08-freeradius-config_3.0.12+dfsg-1_amd64.deb (--unpack): >trying to overwrite '/etc/freeradius/hints', which is also in package > freeradius 3.0.12+dfsg-1 > > > Andreas > > ___ > Pkg-freeradius-maintainers mailing list > pkg-freeradius-maintain...@lists.alioth.debian.org > https://lists.alioth.debian.org/mailman/listinfo/pkg- > freeradius-maintainers > -- Best regards, Michael
Bug#839388: kanla: FTBFS randomly (failing tests)
Turns out I screwed up the 1.5 upload in that I forgot to push the changes to the kanla git repository and don’t have them anymore. Hence, applying the fix isn’t easy enough to justify spending the effort. I’ll file a removal request for kanla instead. On Wed, Oct 5, 2016 at 7:12 PM, Santiago Vila wrote: > tags 839388 + patch > thanks > > On Wed, Oct 05, 2016 at 06:49:45PM +0200, Michael Stapelberg wrote: > > > Just to set expectations: kanla is unmaintained upstream by now, and I > > don’t intend to address this issue. If any user of kanla would like to > step > > up and contribute a fix, that’d be welcome. > > I'm not a user myself (this is just QA work), but the package builds > ok and it's only the tests that fail randomly. > > So if the package is unmaintained upstream I would just disable the > tests: > > --- a/debian/rules > +++ b/debian/rules > @@ -5,3 +5,5 @@ override_dh_fixperms: > > %: > dh $@ --with=systemd > + > +override_dh_auto_test: > > This will always be better than having a package which FTBFS half of > the time. > > Thanks. > -- Best regards, Michael
Bug#839388: kanla: FTBFS randomly (failing tests)
Thanks for reporting this issue. Just to set expectations: kanla is unmaintained upstream by now, and I don’t intend to address this issue. If any user of kanla would like to step up and contribute a fix, that’d be welcome. On Sat, Oct 1, 2016 at 12:53 PM, Santiago Vila wrote: > Package: src:kanla > Version: 1.5-1 > Severity: serious > > Dear maintainer: > > I tried to build this package in stretch with "dpkg-buildpackage -A" > (which is what the "Arch: all" autobuilder would do to build it) > but it failed: > > > > [...] > debian/rules build-indep > dh build-indep --with=systemd >dh_testdir -i >dh_update_autotools_config -i >dh_auto_configure -i > perl -I. Makefile.PL INSTALLDIRS=vendor > Checking if your kit is complete... > Warning: the following files are missing in your kit: > kanla-1.4.tar > MYMETA.json > Please inform the author. > Generating a Unix-style Makefile > Writing Makefile for kanla > > [... snipped ...] > > Test Summary Report > --- > t/009-silenced-by.t (Wstat: 512 Tests: 3 Failed: 2) > Failed tests: 2-3 > Non-zero exit status: 2 > Files=9, Tests=49, 16 wallclock secs ( 0.06 usr 0.02 sys + 1.47 cusr > 0.22 csys = 1.77 CPU) > Result: FAIL > Failed 1/9 test programs. 2/49 subtests failed. > Makefile:781: recipe for target 'test_dynamic' failed > make[1]: *** [test_dynamic] Error 2 > make[1]: Leaving directory '/<>' > dh_auto_test: make -j1 test TEST_VERBOSE=1 returned exit code 2 > debian/rules:7: recipe for target 'build-indep' failed > make: *** [build-indep] Error 2 > dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2 > > > > The failure does not seem related to using "dpkg-buildpackage -A" > > It does not always fail, but it does not always build ok. > > I'm attaching three different build logs. > > Thanks. -- Best regards, Michael
Bug#815867: libxkbcommon: FTBFS: FAIL: test/x11comp
https://github.com/xkbcommon/libxkbcommon/commit/ 914e84e0188b5fbd67855f38f4499bb1412f4516 disabled the test upstream (included in the 0.6.1 release). I’ve packaged the new upstream release and uploaded a version built with: gbp buildpackage --git-debian-branch=debian-unstable --git-upstream-tag="xkbcommon-%(version)s" --git-export-dir=$PWD/../export --git-builder='sbuild -v -As --dist=unstable' On Thu, Aug 18, 2016 at 7:45 PM, Julien Cristau wrote: > CC:ing the last uploader. > > Cheers, > Julien > > On Thu, Feb 25, 2016 at 08:54:03 +0100, Chris Lamb wrote: > > > Source: libxkbcommon > > Version: 0.5.0-1 > > Severity: serious > > Justification: fails to build from source > > User: reproducible-bui...@lists.alioth.debian.org > > Usertags: ftbfs > > X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org > > > > Dear Maintainer, > > > > libxkbcommon fails to build from source in unstable/amd64: > > > > [..] > > > > make[3]: Leaving directory '/home/lamby/temp/cdt. > 20160225074617.SVmbtSnzXS/libxkbcommon-0.5.0' > > make check-TESTS > > make[3]: Entering directory '/home/lamby/temp/cdt. > 20160225074617.SVmbtSnzXS/libxkbcommon-0.5.0' > > make[4]: Entering directory '/home/lamby/temp/cdt. > 20160225074617.SVmbtSnzXS/libxkbcommon-0.5.0' > > PASS: test/context > > PASS: test/utf8 > > PASS: test/rules-file > > PASS: test/log > > PASS: test/atom > > PASS: test/keysym > > PASS: test/state > > PASS: test/filecomp > > PASS: test/buffercomp > > PASS: test/stringcomp > > PASS: test/compose > > PASS: test/rulescomp > > PASS: test/keyseq > > SKIP: test/x11 > > FAIL: test/x11comp > > > > > Testsuite summary for libxkbcommon 0.5.0 > > > > > # TOTAL: 15 > > # PASS: 13 > > # SKIP: 1 > > # XFAIL: 0 > > # FAIL: 1 > > # XPASS: 0 > > # ERROR: 0 > > > > > See ./test-suite.log > > Please report to https://bugs.freedesktop.org/enter_bug.cgi?product= > libxkbcommon > > > > > Makefile:1687: recipe for target 'test-suite.log' failed > > make[4]: *** [test-suite.log] Error 1 > > make[4]: Leaving directory '/home/lamby/temp/cdt. > 20160225074617.SVmbtSnzXS/libxkbcommon-0.5.0' > > Makefile:1793: recipe for target 'check-TESTS' failed > > make[3]: *** [check-TESTS] Error 2 > > make[3]: Leaving directory '/home/lamby/temp/cdt. > 20160225074617.SVmbtSnzXS/libxkbcommon-0.5.0' > > Makefile:2102: recipe for target 'check-am' failed > > make[2]: *** [check-am] Error 2 > > make[2]: Leaving directory '/home/lamby/temp/cdt. > 20160225074617.SVmbtSnzXS/libxkbcommon-0.5.0' > > Makefile:2105: recipe for target 'check' failed > > make[1]: *** [check] Error 2 > > make[1]: Leaving directory '/home/lamby/temp/cdt. > 20160225074617.SVmbtSnzXS/libxkbcommon-0.5.0' > > dh_auto_test: make -j9 check returned exit code 2 > > debian/rules:17: recipe for target 'build' failed > > make: *** [build] Error 2 > > > > [..] > > > > The full build log is attached. > > > > > > Regards, > > > > -- > > ,''`. > > : :' : Chris Lamb > > `. `'` la...@debian.org / chris-lamb.co.uk > >`- > > > -- Best regards, Michael
Bug#821350: dh-golang: generates rubbish in Built-Using; errors on invocation
I unfortunately don’t have time to test this package before uploading. If anyone has the time to either contribute a working and comprehensive test suite for the package and/or take over maintenance, that’d be much appreciated. I’m merely uploading these patches as-is to avoid blocking progress on the package. On Tue, Apr 19, 2016 at 11:10 PM, Dmitry Smirnov wrote: > On Tuesday, 19 April 2016 10:32:58 PM AEST Michael Stapelberg wrote: > > Dmitry, please let us know if the patch works for you and I’ll be happy > to > > upload it. > > Hi Michael, > > Unfortunately I won't be able to spare time for testing at least till > weekend. > Please upload if patch looks good for you -- I doubt it could make > situation > worse than it already is. > > I should trust you to remember to test this important package before every > upload. ;) > > Uploaded or not I'll have a look at first opportunity. Thanks. > > -- > Cheers, > Dmitry Smirnov. > > --- > > Truth — Something somehow discreditable to someone. > -- H. L. Mencken, 1949 > -- Best regards, Michael
Bug#821350: dh-golang: generates rubbish in Built-Using; errors on invocation
Dmitry, please let us know if the patch works for you and I’ll be happy to upload it. On Tue, Apr 19, 2016 at 2:02 AM, Michael Hudson-Doyle < michael.hud...@canonical.com> wrote: > The attached should fix this. I get this for rkt's Built-Using now: > > Built-Using: docker-registry (= 2.3.1~ds1-1), golang (= 2:1.6.1-2), > golang-context (= 0.0~git20140604.1.14f550f-1), golang-github-appc-cni > (= 0.2.0~rc0+dfsg-1), golang-github-appc-docker2aci (= 0.9.3+dfsg-1), > golang-github-appc-spec (= 0.7.4+dfsg-1), > golang-github-coreos-go-systemd (= 5-1), > golang-github-coreos-ioprogress (= 0.0~git20151023.0.4637e49-1), > golang-github-cznic-b (= 0.0~git20151027.0.01b13d7-1), > golang-github-cznic-bufs (= 0.0~git20140818.0.3dcccbd-1), > golang-github-cznic-fileutil (= 0.0~git20150708.0.1c9c88f-1), > golang-github-cznic-mathutil (= 0.0~git20150605.0.a804f0f-1), > golang-github-cznic-ql (= 1.0.2-1), golang-github-cznic-sortutil (= > 0.0~git20150617.0.4c73428-1), golang-github-cznic-strutil (= > 0.0~git20150430.0.1eb03e3-1), golang-github-cznic-zappy (= > 0.0~git20160305.0.4f5e6ef-1), golang-github-dustin-go-humanize (= > 0.0~git20151125.0.8929fe9-1), golang-github-google-btree (= > 0.0~git20150413.0.cc6329d-1), golang-github-gorilla-mux (= > 0.0~git20150814.0.f7b6aaa-1), golang-github-hashicorp-errwrap (= > 0.0~git20141028.0.7554cd9-1), golang-github-pborman-uuid (= > 0.0+git20150824.0.cccd189-1), golang-github-peterbourgon-diskv (= > 2.0.0-1), golang-github-spf13-cobra (= 0.0~git20160117.0.8e91712-1), > golang-github-spf13-pflag (= 0.0~git20151218.0.7f60f83-2), > golang-go-semver (= 0.0~git20150304-1), golang-go.crypto (= > 1:0.0~git20151201.0.7b85b09-2), golang-gocapability-dev (= > 0.0~git20150506.1.66ef2aa-1), golang-golang-x-net-dev (= > 1:0.0+git20160110.4fd4a9f-1), golang-google-grpc (= > 0.0~git20151002.0.3e7b7e5-1), golang-goprotobuf (= 0.0~git20160330-1), > golang-speter-go-exp-math-dec-inf (= 0.0~git20140417.0.42ca6cd-2) > > which looks at least plausible. > > On 19 April 2016 at 10:28, Dmitry Smirnov wrote: > > On Tuesday, 19 April 2016 10:19:56 AM AEST Michael Hudson-Doyle wrote: > >> Wow, I'm not sure that package gets much from using dh-golang at all? > >> But I think the problem is the " --builddirectory=_build" in the > >> default target, somehow that needs to get funnelled into the right > >> place. Will have a look. > > > > Thanks. We actually have many Golang packages with > "--builddirectory=_build" > > so fixing that is very important. > > Are there any other packages you think would be particularly good to > try to build? > > Cheers, > mwh > -- Best regards, Michael
Bug#821350: dh-golang: generates rubbish in Built-Using; errors on invocation
Michael, can you take a look at this issue please? On Mon, Apr 18, 2016 at 12:45 AM, Dmitry Smirnov wrote: > Package: dh-golang > Version: 1.15 > Severity: serious > > Recent upload of "rkt" was rejected > > rkt_1.4.0+dfsg-1_amd64.deb: Built-Using refers to non-existing source > package apt (= 1.0.9.10) > > due to rubbish in Built-Using field: > > apt (= 1.0.9.10), apt (= 1.0.10.2), apt (= 1.2.10) > > Also invocation of dh-golang logged the following: > > >dh_golang -O--buildsystem=golang -O--builddirectory=_build > can't load package: package github.com/coreos/rkt/api/v1alpha: cannot > find package "github.com/coreos/rkt/api/v1alpha" in any of: > /usr/lib/go/src/github.com/coreos/rkt/api/v1alpha (from $GOROOT) > /build/rkt-1.4.0+dfsg/obj-x86_64-linux-gnu/src/ > github.com/coreos/rkt/api/v1alpha (from $GOPATH) > can't load package: package github.com/coreos/rkt/rkt: cannot find > package "github.com/coreos/rkt/rkt" in any of: > /usr/lib/go/src/github.com/coreos/rkt/rkt (from $GOROOT) > /build/rkt-1.4.0+dfsg/obj-x86_64-linux-gnu/src/ > github.com/coreos/rkt/rkt (from $GOPATH) > can't load package: package .: no buildable Go source files in > /build/rkt-1.4.0+dfsg > can't load package: package .: no buildable Go source files in > /build/rkt-1.4.0+dfsg > dpkg-query: error: --search needs at least one file name pattern argument > > Use --help for help about querying packages. > > > This is regression from "dh-golang" v1.12. > > Please investigate. > > -- > All the best, > Dmitry Smirnov > GPG key : 4096R/53968D1B > > --- > > Truth never damages a cause that is just. > -- Mahatma Gandhi > -- Best regards, Michael
Bug#821000: dh-golang: matched no packages; no buildable Go source files
Michael Hudson-Doyle, can you take a look at this please? Dmitry, can you please provide steps to reproduce? On Thu, Apr 14, 2016 at 2:46 PM, Dmitry Smirnov wrote: > Package: dh-golang > Version: 1.14 > Severity: serious > > 1.14 is completely broken and unable to build golang packages any more, > failing with warning "matched no packages" and error "no buildable Go > source > files". > > -- > Regards, > Dmitry Smirnov > GPG key : 4096R/53968D1B > -- Best regards, Michael
Bug#819472: [pkg-go] Bug#819472: dh-make-golang: diff for NMU version 0.0~git20150913.0.1221041-1.1
On Thu, Apr 14, 2016 at 12:57 AM, Raphael Hertzog wrote: > Hi, > > On Thu, 14 Apr 2016, Michael Stapelberg wrote: > > I didn’t see this before pushing a new version. > > What new version? The new version looks like my changes only. > I packaged a new upstream snapshot. > > > Why did you not commit your changes to the collab-maint git repository? > :( > > Because it's not in collab-maint but in pkg-go which I am not part of... > Sorry, I confused this package with dh-golang. I’d encourage you to become a member of pkg-go, though. It’s a quick procedure: you click the button on alioth, we approve :). Thanks! > > Cheers, > -- > Raphaël Hertzog ◈ Debian Developer > > Support Debian LTS: http://www.freexian.com/services/debian-lts.html > Learn to master Debian: http://debian-handbook.info/get/ > -- Best regards, Michael
Bug#819472: [pkg-go] Bug#819472: dh-make-golang: diff for NMU version 0.0~git20150913.0.1221041-1.1
I didn’t see this before pushing a new version. Why did you not commit your changes to the collab-maint git repository? :( On Thu, Apr 7, 2016 at 11:29 AM, Raphael Hertzog wrote: > Control: tags 819472 + patch > Control: tags 819472 + pending > > Dear maintainer, > > I've prepared an NMU for dh-make-golang (versioned as > 0.0~git20150913.0.1221041-1.1) and just uploaded it. > > Regards. > -- > Raphaël Hertzog ◈ Debian Developer > > Support Debian LTS: http://www.freexian.com/services/debian-lts.html > Learn to master Debian: http://debian-handbook.info/get/ > > ___ > Pkg-go-maintainers mailing list > pkg-go-maintain...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers > -- Best regards, Michael
Bug#817057: network-manager-openconnect: Update unstable version to latest Upstream Build
Thanks for clarifying the issue you’re seeing. I don’t think this is related to the D-Bus changes. Also, to be clear: I’m not the maintainer of this package, I sponsored mtmiller@’s uploads, who maintains the package. On Tue, Mar 8, 2016 at 3:09 AM, Ryan Chewning wrote: > Michael, I copied you on this bug as you're the package maintainer for > network-manager-openconnect and the imports of the upstream are failing. > Currently, upstream for network-open-connect is at 1.91 and in Debian > unstable/testing are both on the 1.0.2 release which isn't working with the > network-manager builds in unstable and are on 1.91. I'm attempting to > create an openconnect vpn profile but I get the following error messages in > my .xsession-error log when launching nm-connection editor > > """ > ** Message: vpn: (iodine,/usr/lib/NetworkManager/VPN/ > nm-iodine-service.name) cannot load legacy-only plugin > ** Message: vpn: (ssh,/usr/lib/NetworkManager/VPN/nm-ssh-service.name) > cannot load legacy-only plugin > ** Message: vpn: (openconnect,/usr/lib/NetworkManager/VPN/ > nm-openconnect-service.name) cannot load legacy-only plugin > ** Message: vpn: (strongswan,/etc/NetworkManager/VPN/ > nm-strongswan-service.name) cannot load legacy-only plugin > """" > > I also only have the option to configure the following three types of vpns > OpenVPN, PPTP or KVPNC even though I have iodine, ssh, openconnect and > strongswan installed. > > If you think this bug is better suited for the network-manager package > please let me know and I'll head over that way. > > Thanks, > > Ryan > > On Mon, Mar 7, 2016 at 12:22 PM, Michael Stapelberg > wrote: > >> >> >> On Mon, Mar 7, 2016 at 9:07 AM, Ryan Chewning wrote: >> >>> Package: network-manager-openconnect >>> Version: 1.0.2-1+b1 >>> Severity: grave >>> Tags: upstream >>> Justification: renders package unusable >>> >>> The latest builds of networkmanager in testing/unstable no longer >>> support dbus. https://blogs.gnome.org/dcbw/2016/02/19/die-dbus-glib-die/ >>> >> >> I’m only a bystander for the purpose of this bug, but “networkmanager […] >> no longer supports dbus” conflicts with the article you refer to, which >> mentions: >> >> """ >> I cannot understate how much work this was and how much careful planning >> we (well, mostly Dan Winship) did to ensure we didn’t break backwards >> compatibility of either the utility libraries or the D-Bus interface. >> """ >> >> The way I read this, the new networkmanager version is >> backwards-compatible with regards to its D-Bus interface. >> >> Can you clarify? If it turns out that it’s actually backwards-compatible, >> is severity: grave still justified? >> >> >>> There is an updated version of the network-manager-openconnect but it is >>> failing to be pulled down by uscan. Manual intervention is needed. >>> >>> Thanks, >>> >>> Ryan >>> >>> -- System Information: >>> Debian Release: stretch/sid >>> APT prefers testing-updates >>> APT policy: (500, 'testing-updates'), (500, 'testing') >>> Architecture: amd64 (x86_64) >>> Foreign Architectures: i386 >>> >>> Kernel: Linux 4.3.0-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 network-manager-openconnect depends on: >>> ii adduser 3.113+nmu3 >>> ii libc6 2.21-9 >>> ii libdbus-1-3 1.10.6-1 >>> ii libdbus-glib-1-2 0.106-1 >>> ii libglib2.0-0 2.46.2-3 >>> ii libnm-glib-vpn1 1.1.90-6 >>> ii libnm-glib4 1.1.90-6 >>> ii libnm-util2 1.1.90-6 >>> ii network-manager 1.1.90-6 >>> ii openconnect 7.06-2+b2 >>> >>> network-manager-openconnect recommends no packages. >>> >>> network-manager-openconnect suggests no packages. >>> >>> -- no debconf information >>> >>> >> >> >> -- >> Best regards, >> Michael >> > > -- Best regards, Michael
Bug#817057: network-manager-openconnect: Update unstable version to latest Upstream Build
On Mon, Mar 7, 2016 at 9:07 AM, Ryan Chewning wrote: > Package: network-manager-openconnect > Version: 1.0.2-1+b1 > Severity: grave > Tags: upstream > Justification: renders package unusable > > The latest builds of networkmanager in testing/unstable no longer support > dbus. https://blogs.gnome.org/dcbw/2016/02/19/die-dbus-glib-die/ > I’m only a bystander for the purpose of this bug, but “networkmanager […] no longer supports dbus” conflicts with the article you refer to, which mentions: """ I cannot understate how much work this was and how much careful planning we (well, mostly Dan Winship) did to ensure we didn’t break backwards compatibility of either the utility libraries or the D-Bus interface. """ The way I read this, the new networkmanager version is backwards-compatible with regards to its D-Bus interface. Can you clarify? If it turns out that it’s actually backwards-compatible, is severity: grave still justified? > There is an updated version of the network-manager-openconnect but it is > failing to be pulled down by uscan. Manual intervention is needed. > > Thanks, > > Ryan > > -- System Information: > Debian Release: stretch/sid > APT prefers testing-updates > APT policy: (500, 'testing-updates'), (500, 'testing') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 4.3.0-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 network-manager-openconnect depends on: > ii adduser 3.113+nmu3 > ii libc6 2.21-9 > ii libdbus-1-3 1.10.6-1 > ii libdbus-glib-1-2 0.106-1 > ii libglib2.0-0 2.46.2-3 > ii libnm-glib-vpn1 1.1.90-6 > ii libnm-glib4 1.1.90-6 > ii libnm-util2 1.1.90-6 > ii network-manager 1.1.90-6 > ii openconnect 7.06-2+b2 > > network-manager-openconnect recommends no packages. > > network-manager-openconnect suggests no packages. > > -- no debconf information > > -- Best regards, Michael
Bug#803320: [pkg-go] golang-github-jacobsa-ogletest: Bug#803320: TestGoldenFiles fails with Go 1.5
Dmitry, can you do the upload please? On Sat, Feb 27, 2016 at 12:17 PM, Dmitry Smirnov wrote: > On Sun, 17 Jan 2016 06:51:59 PM Harlan Lieberman-Berg wrote: > > Confirmed and pre-existing upstream bug referenced. > > Guys could someone please re-upload "jacobsa-ogletest" with tests disabled > or > something to avoid dropping the whole hierarchy of innocent packages from > "testing"? > > Thanks. > > -- > Best wishes, > Dmitry Smirnov. > > --- > > It is a fine thing to be honest, but it is also very important to be right. > -- Winston Churchill > > ___ > Pkg-go-maintainers mailing list > pkg-go-maintain...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers > -- Best regards, Michael
Bug#807380: Regression for 'PKCS11Provider libsimple-tpm-pk11.so' - ignoring uninitialised token in slot 0
If you could do an upload (possibly even of the new version), that’d be appreciated. On Tue, Dec 8, 2015 at 3:23 AM, Didier 'OdyX' Raboud wrote: > Control: found -1 0.03-1 > Control: severity -1 serious > Control: tags -1 +upstream +patch +fixed-upstream > > Le mardi, 8 décembre 2015, 09.47:04 Colin Watson a écrit : > > Control: reassign -1 simple-tpm-pk11 > > > > On Tue, Dec 08, 2015 at 09:34:07AM +0100, Didier 'OdyX' Raboud wrote: > > > I'm using the following SSH config to use my X220's TPM through > > > > > > simple-tpm-pk11: > > > > Host test > > > > > > > > PKCS11Provider libsimple-tpm-pk11.so > > > > > This is because of the fix in > > https://bugzilla.mindrot.org/show_bug.cgi?id=2427 - OpenSSH now checks > > whether the token is initialised, but simple-tpm-pk11 doesn't set > > that flag. This is essentially the same as > > https://github.com/ThomasHabets/simple-tpm-pk11/issues/13. I think > > that cherry-picking this commit would do it, or simply upgrading to > > simple-tpm-pk11 0.04: > > > > > > https://github.com/ThomasHabets/simple-tpm-pk11/commit/bd8202d0f270e0 > > 2e89b7df84c7373fbe1ace3e9e > > Good catch, thanks. I can confirm that simple-tpm-pk11 0.04 works! > > I'm rising the severity of that bug as the main use of simple-tpm-pk11 > is broken by the openssh in unstable. > > Michael: would you be up for upload, or should I proceed with a cherry- > pick and upload to DELAYED ? > > Cheers, > > OdyX > -- Best regards, Michael
Bug#805664: golang-go.tools: FTBFS: code.google.com/p/go.net/html expects import "golang.org/x/net/html"
[+cc tianon, who touched this package most recently] [+cc paultag, for all things ftp master knowledge] I’m a bit confused by this report, I must say. I thought that with commit https://anonscm.debian.org/cgit/pkg-go/packages/golang-go.tools.git/commit/?id=b4ec506c6331c363e0ac9997e8e78a4c73e5f563 we had addressed any sort of weirdness with the old version, but this bug report is against version 0.0~hg20140703-4, which you shouldn’t be able to install on a testing/unstable system. On https://packages.qa.debian.org/g/golang-golang-x-tools.html, I also see: There were override disparities found in suite unstable: golang-go.tools-dev: Override says devel - extra, .deb says oldlibs - extra golang-go.tools: Override says devel - extra, .deb says oldlibs - extra Not sure if that’s related at all. Any hints as to what’s going on are appreciated. On Fri, Nov 20, 2015 at 9:00 PM, Chris West (Faux) < solo-debianb...@goeswhere.com> wrote: > Source: golang-go.tools > Version: 0.0~hg20140703-4 > Severity: serious > Justification: fails to build from source > Tags: sid > User: reproducible-bui...@lists.alioth.debian.org > Usertags: ftbfs > X-Debbugs-CC: reproducible-bui...@lists.alioth.debian.org > > Dear Maintainer, > > The package fails to build offline, such as on the builders: > > go install -v code.google.com/p/go [...] go.tools/refactor/eg > src/code.google.com/p/go.tools/cmd/html2article/conv.go:21:2: code in > directory /golang-go.tools-0.0~hg20140703/obj-x86_64-linux-gnu/src/ > code.google.com/p/go.net/html expects import "golang.org/x/net/html" > src/code.google.com/p/go.tools/cmd/html2article/conv.go:22:2: code in > directory /golang-go.tools-0.0~hg20140703/obj-x86_64-linux-gnu/src/ > code.google.com/p/go.net/html/atom expects import " > golang.org/x/net/html/atom" > src/code.google.com/p/go.tools/playground/socket/socket.go:38:2: code in > directory /golang-go.tools-0.0~hg20140703/obj-x86_64-linux-gnu/src/ > code.google.com/p/go.net/websocket expects import " > golang.org/x/net/websocket" > > Full build log: > https://reproducible.debian.net/rb-pkg/unstable/amd64/golang-go.tools.html > > -- System Information: > Debian Release: stretch/sid > APT prefers unstable > APT policy: (500, 'unstable') > Architecture: amd64 (x86_64) > -- Best regards, Michael
Bug#803886: dnsval: FTBFS: SSLv3 method
Ondřej, are you taking care of this one or do you need help with it? Asking because this will lead to removal of irssi and related packages from testing, which I’d like to avoid. Kurt Roeckx writes: > Source: dnsval > Version: 2.0-2 > Severity: serious > > Hi, > > Version 2.0 has this line in dane_check.c: > const SSL_METHOD *meth = SSLv3_client_method(); > > On the other hand, the 2.1 version has: > const SSL_METHOD *meth = SSLv23_client_method(); > > (It also explicitly disables SSLv2 and SSLv3, but that doesn't > have any effect in Debian since jessie.) > > Please change the 2.0 to use SSLv23_client_method() that actually > support multiple versions. The SSLv3_client_method only talks > SSLv3. > > Also please consider backporting to stable, you really don't want > to use SSLv3. > > > Kurt > > > -- Best regards, Michael
Bug#799797: golang-go.tools: FTBFS: code.google.com/p/go.net/html expects import "golang.org/x/net/html"
control: tags -1 + pending So, the problem at hand is addressed with https://anonscm.debian.org/cgit/pkg-go/packages/golang-go.tools.git/commit/?id=b4ec506c6331c363e0ac9997e8e78a4c73e5f563, I think, but I can’t build that because golang-doc is not installable because it’s not buildable currently: https://buildd.debian.org/status/fetch.php?pkg=golang&arch=all&ver=2%3A1.4.3-1&stamp=1443166782. I’ve notified tianon/paultag about it, so hopefully they can take a look. On Tue, Sep 22, 2015 at 7:20 PM, Chris West (Faux) < solo-debianb...@goeswhere.com> wrote: > Source: golang-go.tools > Version: 0.0~hg20140703-4 > Severity: serious > Justification: fails to build from source > Tags: sid stretch > User: reproducible-bui...@lists.alioth.debian.org > Usertags: ftbfs > X-Debbugs-CC: reproducible-bui...@lists.alioth.debian.org > > Dear Maintainer, > > The package fails to build: > > dh_auto_build override_dh_auto_build > can't load package: the code.google.com/p/go.tools/cmd/cover command has > moved; use golang.org/x/tools/cmd/cover instead. > can't load package: the code.google.com/p/go.tools/cmd/godoc command has > moved; use golang.org/x/tools/cmd/godoc instead. > can't load package: the code.google.com/p/go.tools/cmd/vet command has > moved; use golang.org/x/tools/cmd/vet instead. > cd obj-x86_64-linux-gnu > go install -v [..]/go.tools/cmd/html2article/conv.go:21:2: code in > directory /golang-go.tools-0.0~hg20140703/obj-x86_64-linux-gnu/src/ > code.google.com/p/go.net/html expects import "golang.org/x/net/html" > src/code.google.com/p/go.tools/cmd/html2article/conv.go:22:2: code in > directory /golang-go.tools-0.0~hg20140703/obj-x86_64-linux-gnu/src/ > code.google.com/p/go.net/html/atom expects import " > golang.org/x/net/html/atom" > src/code.google.com/p/go.tools/playground/socket/socket.go:38:2: code in > directory /golang-go.tools-0.0~hg20140703/obj-x86_64-linux-gnu/src/ > code.google.com/p/go.net/websocket expects import " > golang.org/x/net/websocket" > > Full build log: > https://reproducible.debian.net/rb-pkg/unstable/amd64/golang-go.tools.html > > -- System Information: > Debian Release: stretch/sid > APT prefers unstable > APT policy: (500, 'unstable') > Architecture: amd64 (x86_64) > -- Best regards, Michael
Bug#798725: [pkg-go] Bug#798725: golang-github-vbatts-tar-split: FTBFS: B-D favors nonexistent packages over real ones
On Sat, Sep 12, 2015 at 12:15 AM, Aaron M. Ucko wrote: > Source: golang-github-vbatts-tar-split > Version: 0.9.7-1 > Severity: serious > Justification: fails to build from source > > Automatic builds of golang-github-vbatts-tar-split have been failing > because its build dependencies include > > golang-github-codegangsta-cli-dev | golang-codegangsta-cli-dev > > and > > golang-github-sirupsen-logrus-dev | golang-logrus-dev > > These terms are both technically satisfiable because > golang-codegangsta-cli-dev and golang-logrus-dev both exist in the > archive. However, for the sake of reproducibility, the autobuilders > only ever try the first option (modulo explicit architectural > constraints), and consequently fail. Please either remove the Ugh :(. That is a serious downside for our renaming strategy. > references to golang-github-*-dev or swap them to appear after the > packages that are actually available. I think the better fix is to actually upload golang-github-codegangsta-cli-dev and golang-github-sirupsen-logrus-dev. > > Thanks! > > ___ > Pkg-go-maintainers mailing list > pkg-go-maintain...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers -- Best regards, Michael
Bug#796806: [pkg-go] Bug#796806: golang-check.v1: Non-determistically FTBFS due to unreliable timing in tests
Bug #796400 was similar.
lamby, can you explain how I can reproduce this failure locally? I’d
like to better understand how you are testing this before I can do
anything about fixing the issue.
On Mon, Aug 24, 2015 at 9:45 AM, Chris Lamb wrote:
> Source: golang-check.v1
> Version: 0.0+git20150729.11d3bc7-1
> Severity: serious
> Justification: fails to build from source
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: ftbfs
> X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
>
> Dear Maintainer,
>
> golang-check.v1's testsuite appears to use method timing/benchmarking in
> such
> a way that it will non-deterministically FTBFS:
>
> [..]
>
> dh_auto_test -O--buildsystem=golang
> go test -v gopkg.in/check.v1
> === RUN Test
>
> --
> FAIL: benchmark_test.go:39: BenchmarkS.TestBenchmark
>
> benchmark_test.go:59:
> c.Assert(output.value, Matches, expected)
> ... value string = "PASS: check_test.go:144:
> FixtureHelper.Benchmark1\t 50\t261765 ns/op\n"
> ... regex string = "PASS: check_test\\.go:[0-9]+:
> FixtureHelper\\.Benchmark1\t *100\t *[12][0-9]{5} ns/op\n"
>
>
> --
> FAIL: benchmark_test.go:62: BenchmarkS.TestBenchmarkBytes
>
> benchmark_test.go:74:
> c.Assert(output.value, Matches, expected)
> ... value string = "PASS: check_test.go:151:
> FixtureHelper.Benchmark2\t 50\t346352 ns/op\t 2.96 MB/s\n"
> ... regex string = "PASS: check_test\\.go:[0-9]+:
> FixtureHelper\\.Benchmark2\t *100\t *[12][0-9]{5} ns/op\t
> *[4-9]\\.[0-9]{2} MB/s\n"
>
> OOPS: 125 passed, 2 FAILED
> --- FAIL: Test (0.46s)
> FAIL
> exit status 1
> FAILgopkg.in/check.v1 0.469s
> dh_auto_test: go test -v gopkg.in/check.v1 returned exit code 1
> debian/rules:7: recipe for target 'build' failed
> make: *** [build] Error 1
> dpkg-buildpackage: error: debian/rules build gave error exit status 2
>
> [..]
>
> The full build log is attached or can be viewed here:
>
>
> https://reproducible.debian.net/logs/unstable/amd64/golang-check.v1_0.0+git20150729.11d3bc7-1.build1.log.gz
>
>
> Regards,
>
> --
> ,''`.
> : :' : Chris Lamb
> `. `'` la...@debian.org / chris-lamb.co.uk
>`-
>
> ___
> Pkg-go-maintainers mailing list
> pkg-go-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
--
Best regards,
Michael
On Mon, Aug 24, 2015 at 6:45 PM, Chris Lamb wrote:
> Source: golang-check.v1
> Version: 0.0+git20150729.11d3bc7-1
> Severity: serious
> Justification: fails to build from source
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: ftbfs
> X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
>
> Dear Maintainer,
>
> golang-check.v1's testsuite appears to use method timing/benchmarking in
> such
> a way that it will non-deterministically FTBFS:
>
> [..]
>
> dh_auto_test -O--buildsystem=golang
> go test -v gopkg.in/check.v1
> === RUN Test
>
> --
> FAIL: benchmark_test.go:39: BenchmarkS.TestBenchmark
>
> benchmark_test.go:59:
> c.Assert(output.value, Matches, expected)
> ... value string = "PASS: check_test.go:144:
> FixtureHelper.Benchmark1\t 50\t261765 ns/op\n"
> ... regex string = "PASS: check_test\\.go:[0-9]+:
> FixtureHelper\\.Benchmark1\t *100\t *[12][0-9]{5} ns/op\n"
>
>
> --
> FAIL: benchmark_test.go:62: BenchmarkS.TestBenchmarkBytes
>
> benchmark_test.go:74:
> c.Assert(output.value, Matches, expected)
> ... value string = "PASS: check_test.go:151:
> FixtureHelper.Benchmark2\t 50\t346352 ns/op\t 2.96 MB/s\n"
> ... regex string = "PASS: check_test\\.go:[0-9]+:
> FixtureHelper\\.Benchmark2\t *100\t *[12][0-9]{5} ns/op\t
> *[4-9]\\.[0-9]{2} MB/s\n"
>
> OOPS: 125 passed, 2 FAILED
> --- FAIL: Test (0.46s)
> FAIL
> exit status 1
> FAILgopkg.in/check.v1 0.469s
> dh_auto_test: go test -v gopkg.in/check.v1 returned exit code 1
> debian/rules:7: recipe for target 'build' failed
> make: *** [build] Error 1
> dpkg-buildpackage: error: debian/rules build gave error exit status 2
>
> [..]
>
> The full build log is attached or can be viewed here:
>
>
> https://reproducible.debian.net/logs/unstable/amd64/golang-check.v1_0.0+git20150729.11d3bc7-1.build1.log.gz
>
>
> Regards,
>
> --
> ,''`.
> : :' : Chris Lamb
> `. `'` la...@debian.org / chris-lamb.co.uk
>`-
>
> ___
> Pkg-go-maintainers mailing list
> pkg-go-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
Bug#796400: [pkg-go] Bug#796400: Bug#796400: golang-github-jacobsa-ratelimit: Non-determistically FTBFS due to unreliable timing in tests
On Tue, Aug 25, 2015 at 7:13 PM, Chris Lamb wrote: >> > Sure. Are you able to modify the test before running it on the relevant >> > system >> > and find a timing that works reliably? >> >> lamby, do I have access to the system on which the tests don’t pass? > > I fear gaining access to this machine would serve no real purpose; the > solution here is not to bump the values so that the test is "less" flaky > - the test would remain non-determistic and thus this bug would remain > unresolved IMHO, even though it might be harder to trigger. > > As a concept, I have no problem with automated solutions to point out > potential performance regressions, but having a testsuite that fails I don’t think the intention of the test in question is to point out performance regressions, so while I agree with your general statement about flakyness in general, I’m not convinced it applies here. > non-determinstically is generally perceived to be a Bad Idea in software > engineering. Perhaps some sort of switch or environment variable can be > introduced to enable them so that they do not get in the way of the > regular build. > > > Regards, > > -- > ,''`. > : :' : Chris Lamb > `. `'` la...@debian.org / chris-lamb.co.uk >`- -- Best regards, Michael
Bug#796400: [pkg-go] Bug#796400: Bug#796400: golang-github-jacobsa-ratelimit: Non-determistically FTBFS due to unreliable timing in tests
On Mon, Aug 24, 2015 at 3:32 PM, Aaron Jacobs wrote: > On Mon, Aug 24, 2015 at 4:37 PM, Michael Stapelberg >> Could the timing requirements be relaxed to make it less flaky? > > Sure. Are you able to modify the test before running it on the relevant system > and find a timing that works reliably? lamby, do I have access to the system on which the tests don’t pass? > > >> I don’t think giving up is a good idea :). FWIW, just to be clear, >> it’s not that vendoring is not supported, it’s a conscious decision by >> Debian to avoid it. Also, AFAICT, other distributions (like Fedora) >> are following the same model, so I don’t think Debian is different in >> this regard. If you have trouble getting the software into Debian, >> you’ll likely have trouble getting it into any of the other big >> distributions, too. > > (I understand about vendoring; it's a philosophical difference.) > > The model we've chosen is distributing binaries from our own apt and yum > repos: > > > https://github.com/googlecloudplatform/gcsfuse/blob/master/docs/installing.md > > I'm totally fine with you finishing this off for the official debian repo if > you want to, but I wanted to be clear about the situation from our end. It seems to me that there’s little value in making gcsfuse available in Debian when the officially recommended way of installing it is from a third-party repository. I’ll think about how to proceed; moving in either direction is work, and leaving things as they are means bloating our repository and control files shipped to users for no good reason. -- Best regards, Michael
Bug#796400: [pkg-go] Bug#796400: Bug#796400: golang-github-jacobsa-ratelimit: Non-determistically FTBFS due to unreliable timing in tests
On Sun, Aug 23, 2015 at 11:47 PM, Aaron Jacobs wrote: > Yes, this is a test for an object whose functionality is based on wall time, > so > it uses wall time. I know that makes it flaky and in general I try to avoid > such tests, but it was a conscious decision here. Could the timing requirements be relaxed to make it less flaky? > The best way to deal with this may be to just delete the package. Michael, I > apologize because I know you've spent a bunch of time on this, but it seems > like the Debian packaging model just doesn't work out for us. (In particular: > lack of support for vendoring and needing a separate package per tiny > dependency.) :-( I don’t think giving up is a good idea :). FWIW, just to be clear, it’s not that vendoring is not supported, it’s a conscious decision by Debian to avoid it. Also, AFAICT, other distributions (like Fedora) are following the same model, so I don’t think Debian is different in this regard. If you have trouble getting the software into Debian, you’ll likely have trouble getting it into any of the other big distributions, too. > > Aaron > > On Sun, Aug 23, 2015 at 9:08 PM, Michael Stapelberg > wrote: >> Aaron, could you take a look at this problem please? It seems to me >> like this is a shortcoming of your tests, unrelated to Debian. >> >> On Fri, Aug 21, 2015 at 8:44 PM, Chris Lamb wrote: >>> Source: golang-github-jacobsa-ratelimit >>> Version: 0.0~git20150723.0.2ca5e0c-1 >>> Severity: serious >>> Justification: fails to build from source >>> User: reproducible-bui...@lists.alioth.debian.org >>> Usertags: ftbfs >>> X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org >>> >>> Dear Maintainer, >>> >>> golang-github-jacobsa-ratelimit's testsuite appears to use method >>> timing/benchmarking in such >>> a way that it will non-deterministically FTBFS: >>> >>> throttle_test.go: >>> expected := smallerRateHz * (float64(perCaseDuration) / >>> float64(time.Second)) >>> >>> For example: >>> >>> [..] >>> go test -v github.com/jacobsa/ratelimit >>> === RUN TestThrottle >>> [--] Running tests from ThrottleTest >>> [ RUN ] ThrottleTest.IntegrationTest >>> throttle_test.go:202: >>> Expected: greater than 135, and less than 165 >>> Actual: 88 >>> Test case 0. expected: 150.00 >>> >>> throttle_test.go:202: >>> Expected: greater than 180, and less than 220.03 >>> Actual: 138 >>> Test case 1. expected: 200.00 >>> >>> throttle_test.go:202: >>> Expected: greater than 180, and less than 220.03 >>> Actual: 163 >>> Test case 2. expected: 200.00 >>> >>> [ FAILED ] ThrottleTest.IntegrationTest (6.031585896s) >>> [--] Finished with tests from ThrottleTest >>> [--] Running tests from ThrottledReaderTest >>> [ RUN ] ThrottledReaderTest.CallsThrottle >>> [ OK ] ThrottledReaderTest.CallsThrottle >>> [ RUN ] ThrottledReaderTest.ThrottleReturnsError >>> [ OK ] ThrottledReaderTest.ThrottleReturnsError >>> [ RUN ] ThrottledReaderTest.CallsWrapped >>> [ OK ] ThrottledReaderTest.CallsWrapped >>> [ RUN ] ThrottledReaderTest.WrappedReturnsError >>> [ OK ] ThrottledReaderTest.WrappedReturnsError >>> [ RUN ] ThrottledReaderTest.WrappedReturnsEOF >>> [ OK ] ThrottledReaderTest.WrappedReturnsEOF >>> [ RUN ] ThrottledReaderTest.WrappedReturnsFullRead >>> [ OK ] ThrottledReaderTest.WrappedReturnsFullRead >>> [ RUN ] ThrottledReaderTest.WrappedReturnsShortRead_CallsAgain >>> [ OK ] ThrottledReaderTest.WrappedReturnsShortRead_CallsAgain >>> [ RUN ] >>> ThrottledReaderTest.WrappedReturnsShortRead_SecondReturnsError >>> [ OK ] >>> ThrottledReaderTest.WrappedReturnsShortRead_SecondReturnsError >>> [ RUN ] >>> ThrottledReaderTest.WrappedReturnsShortRead_SecondReturnsEOF >>> [ OK ] >>> ThrottledReaderTest.WrappedReturnsShortRead_SecondReturnsEOF >>> [ RUN ] >>> ThrottledReaderTest.WrappedReturnsShortRead_SecondSucceedsInFull >>> [ OK ] >>> ThrottledReaderTest.WrappedReturnsShortRead_SecondSucceedsInFull >>> [ RUN ] ThrottledReaderTest.ReadSizeIsAboveThrottleCapacity >>> [
Bug#796400: [pkg-go] Bug#796400: golang-github-jacobsa-ratelimit: Non-determistically FTBFS due to unreliable timing in tests
Aaron, could you take a look at this problem please? It seems to me like this is a shortcoming of your tests, unrelated to Debian. On Fri, Aug 21, 2015 at 8:44 PM, Chris Lamb wrote: > Source: golang-github-jacobsa-ratelimit > Version: 0.0~git20150723.0.2ca5e0c-1 > Severity: serious > Justification: fails to build from source > User: reproducible-bui...@lists.alioth.debian.org > Usertags: ftbfs > X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org > > Dear Maintainer, > > golang-github-jacobsa-ratelimit's testsuite appears to use method > timing/benchmarking in such > a way that it will non-deterministically FTBFS: > > throttle_test.go: > expected := smallerRateHz * (float64(perCaseDuration) / > float64(time.Second)) > > For example: > > [..] > go test -v github.com/jacobsa/ratelimit > === RUN TestThrottle > [--] Running tests from ThrottleTest > [ RUN ] ThrottleTest.IntegrationTest > throttle_test.go:202: > Expected: greater than 135, and less than 165 > Actual: 88 > Test case 0. expected: 150.00 > > throttle_test.go:202: > Expected: greater than 180, and less than 220.03 > Actual: 138 > Test case 1. expected: 200.00 > > throttle_test.go:202: > Expected: greater than 180, and less than 220.03 > Actual: 163 > Test case 2. expected: 200.00 > > [ FAILED ] ThrottleTest.IntegrationTest (6.031585896s) > [--] Finished with tests from ThrottleTest > [--] Running tests from ThrottledReaderTest > [ RUN ] ThrottledReaderTest.CallsThrottle > [ OK ] ThrottledReaderTest.CallsThrottle > [ RUN ] ThrottledReaderTest.ThrottleReturnsError > [ OK ] ThrottledReaderTest.ThrottleReturnsError > [ RUN ] ThrottledReaderTest.CallsWrapped > [ OK ] ThrottledReaderTest.CallsWrapped > [ RUN ] ThrottledReaderTest.WrappedReturnsError > [ OK ] ThrottledReaderTest.WrappedReturnsError > [ RUN ] ThrottledReaderTest.WrappedReturnsEOF > [ OK ] ThrottledReaderTest.WrappedReturnsEOF > [ RUN ] ThrottledReaderTest.WrappedReturnsFullRead > [ OK ] ThrottledReaderTest.WrappedReturnsFullRead > [ RUN ] ThrottledReaderTest.WrappedReturnsShortRead_CallsAgain > [ OK ] ThrottledReaderTest.WrappedReturnsShortRead_CallsAgain > [ RUN ] > ThrottledReaderTest.WrappedReturnsShortRead_SecondReturnsError > [ OK ] > ThrottledReaderTest.WrappedReturnsShortRead_SecondReturnsError > [ RUN ] > ThrottledReaderTest.WrappedReturnsShortRead_SecondReturnsEOF > [ OK ] > ThrottledReaderTest.WrappedReturnsShortRead_SecondReturnsEOF > [ RUN ] > ThrottledReaderTest.WrappedReturnsShortRead_SecondSucceedsInFull > [ OK ] > ThrottledReaderTest.WrappedReturnsShortRead_SecondSucceedsInFull > [ RUN ] ThrottledReaderTest.ReadSizeIsAboveThrottleCapacity > [ OK ] ThrottledReaderTest.ReadSizeIsAboveThrottleCapacity > [--] Finished with tests from ThrottledReaderTest > [--] Running tests from TokenBucketTest > [ RUN ] TokenBucketTest.CarefulAccounting > [ OK ] TokenBucketTest.CarefulAccounting > [--] Finished with tests from TokenBucketTest > --- FAIL: TestThrottle (6.03s) > === RUN TestThrottledReader > --- PASS: TestThrottledReader (0.00s) > === RUN TestTokenBucket > --- PASS: TestTokenBucket (0.00s) > FAIL > exit status 1 > FAILgithub.com/jacobsa/ratelimit6.074s > dh_auto_test: go test -v github.com/jacobsa/ratelimit returned exit > code 1 > debian/rules:6: recipe for target 'build' failed > make: *** [build] Error 1 > dpkg-buildpackage: error: debian/rules build gave error exit status 2 > > [..] > > The full build log is attached or can be viewed here: > > > https://reproducible.debian.net/logs/unstable/amd64/golang-github-jacobsa-ratelimit_0.0~git20150723.0.2ca5e0c-1.build2.log.gz > > > Regards, > > -- > ,''`. > : :' : Chris Lamb > `. `'` la...@debian.org / chris-lamb.co.uk >`- > > ___ > Pkg-go-maintainers mailing list > pkg-go-maintain...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers -- Best regards, Michael
Bug#793518: [pkg-go] Bug#793518: Bug#793518: FTBFS: TestString fails: ini_test.go:167: Dict cannot be stringified as expected.
On Thu, Jul 30, 2015 at 6:05 AM, Potter, Tim (Cloud Services) < timothy.pot...@hp.com> wrote: > On 28 Jul 2015, at 5:14 pm, Michael Stapelberg > wrote: > > > > So, yes, if you could work with upstream on a proper solution and then > we could just package a new upstream snapshot, that’d be great. > > I’ve just posted two pull requests on the upstream project. One to fix the > occasional test failures, and another to fix another instances of relying > on the ordering of hash keys. > > If someone can give me upload access (since I’m only a DM) I’ll upload > the package if/when upstream accepts my patches. Otherwise I’ll just > pester people on the list for an update. (-: > Once upstream accepts your patches, please update the packaging git repository and let me know, I’ll gladly sponsor this upload. I’m also open to granting you DM upload privileges on individual packages, but I’d like to have a few more interactions with you before that :). -- Best regards, Michael
Bug#793518: [pkg-go] Bug#793518: Bug#793518: FTBFS: TestString fails: ini_test.go:167: Dict cannot be stringified as expected.
Chris, thanks for the explanation, that makes sense! I totally missed the fact that there were not-yet-uploaded changes in git. Tim, I just tried packaging the new upstream snapshot, and the fix you got upstream to merge was indeed not enough. My first guess is that exampleStr requires section1 and section2 to be serialized in order, but Dict.format() does not sort the keys when iterating over the map. It’s surprising that this hasn’t caused issues elsewhere yet. So, yes, if you could work with upstream on a proper solution and then we could just package a new upstream snapshot, that’d be great. On Tue, Jul 28, 2015 at 3:02 AM, Potter, Tim (Cloud Services) < timothy.pot...@hp.com> wrote: > On 28 Jul 2015, at 6:35 am, solo-debianb...@goeswhere.com wrote: > > > > On Mon, Jul 27, 2015 at 07:26:10PM +0200, Michael Stapelberg wrote: > >> control: tags -1 + unreproducible > >> > >> Chris, was this an issue on your end? Or am I misinterpreting something? > >> > > > > The problem seems to have gone away. I was running local builds in > > response to errors on the reproducible-builds builder. Their builder > > has rebuilt sucessfully since then, and I have also just rebuilt > > sucessfully. Perhaps it was fixed by dependency changes? > > > > Proof I'm not mad: my build log from local: > > https://paste.debian.net/286717/ > > Hi everyone. I think this bug is due to this test relying on the > ordering of keys retrieved from > a hash being the same as they were inserted. This seems to work most of > the time (at > least on amd64) but occasionally the keys come out in a different order > and the test breaks. > > I could disable the test so things work and work with upstream for a > proper fix. Would that > help out some? > > > Tim. -- Best regards, Michael
Bug#793518: [pkg-go] Bug#793518: FTBFS: TestString fails: ini_test.go:167: Dict cannot be stringified as expected.
Actually, my bad, the commit I referenced is already in the package in the form of a patch. In your https://paste.debian.net/286717/, I don’t see any mention of the patch, though…? Does your build environment not apply patches? When running gbp buildpackage --git-pbuilder, I see: […] dpkg-source: warning: extracting unsigned source package (golang-github-glacjay-goini_0.0~git20141123-1.dsc) dpkg-source: info: extracting golang-github-glacjay-goini in golang-github-glacjay-goini-0.0~git20141123 dpkg-source: info: unpacking golang-github-glacjay-goini_0.0~git20141123.orig.tar.gz dpkg-source: info: unpacking golang-github-glacjay-goini_0.0~git20141123-1.debian.tar.xz dpkg-source: info: applying 0001-fix-test-nondeterminism.patch I: Building the package On Mon, Jul 27, 2015 at 10:39 PM, Michael Stapelberg wrote: > Turns out that test is flaky. The problem was fixed upstream in > https://github.com/glacjay/goini/commit/5352bdc2ac2ddf2b5d27447c95bfe9588a8e09e9, > I’ll package a new snapshot. > > On Mon, Jul 27, 2015 at 10:35 PM, wrote: > >> On Mon, Jul 27, 2015 at 07:26:10PM +0200, Michael Stapelberg wrote: >> > control: tags -1 + unreproducible >> > >> > Chris, was this an issue on your end? Or am I misinterpreting something? >> > >> >> The problem seems to have gone away. I was running local builds in >> response to errors on the reproducible-builds builder. Their builder >> has rebuilt sucessfully since then, and I have also just rebuilt >> sucessfully. Perhaps it was fixed by dependency changes? >> >> Proof I'm not mad: my build log from local: >> https://paste.debian.net/286717/ >> >> > > > -- > Best regards, > Michael > -- Best regards, Michael
Bug#793518: [pkg-go] Bug#793518: FTBFS: TestString fails: ini_test.go:167: Dict cannot be stringified as expected.
Turns out that test is flaky. The problem was fixed upstream in https://github.com/glacjay/goini/commit/5352bdc2ac2ddf2b5d27447c95bfe9588a8e09e9, I’ll package a new snapshot. On Mon, Jul 27, 2015 at 10:35 PM, wrote: > On Mon, Jul 27, 2015 at 07:26:10PM +0200, Michael Stapelberg wrote: > > control: tags -1 + unreproducible > > > > Chris, was this an issue on your end? Or am I misinterpreting something? > > > > The problem seems to have gone away. I was running local builds in > response to errors on the reproducible-builds builder. Their builder > has rebuilt sucessfully since then, and I have also just rebuilt > sucessfully. Perhaps it was fixed by dependency changes? > > Proof I'm not mad: my build log from local: > https://paste.debian.net/286717/ > > -- Best regards, Michael
Bug#793518: [pkg-go] Bug#793518: FTBFS: TestString fails: ini_test.go:167: Dict cannot be stringified as expected.
control: tags -1 + unreproducible I can’t reproduce this. Using gbp buildpackage --git-pbuilder, the package builds fine. Additionally, clicking “build2” on https://reproducible.debian.net/rb-pkg/unstable/amd64/golang-github-glacjay-goini.html (which your bug report pointed me to) results in a build log that tells me everything is okay. Chris, was this an issue on your end? Or am I misinterpreting something? On Fri, Jul 24, 2015 at 9:31 PM, Chris West (Faux) < solo-debianb...@goeswhere.com> wrote: > Source: golang-github-glacjay-goini > Version: 0.0~git20141123-1 > Severity: serious > Tags: sid > Justification: fails to build from source > User: reproducible-bui...@lists.alioth.debian.org > Usertags: ftbfs > > Dear Maintainer, > > The package fails to build: > > === RUN TestString > --- FAIL: TestString (0.00s) > ini_test.go:167: Dict cannot be stringified as expected. > FAIL > exit status 1 > FAILgithub.com/glacjay/goini0.012s > dh_auto_test: go test -v github.com/glacjay/goini returned exit code 1 > > Full build log: > > https://reproducible.debian.net/rb-pkg/unstable/amd64/golang-github-glacjay-goini.html > > -- System Information: > Debian Release: stretch/sid > APT prefers unstable > APT policy: (500, 'unstable') > Architecture: amd64 (x86_64) > > Kernel: Linux 3.19.0-23-generic (SMP w/8 CPU cores) > Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > ___ > Pkg-go-maintainers mailing list > pkg-go-maintain...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers > -- Best regards, Michael
Bug#791514: [pkg-go] Bug#791514: golang-mreiferson-httpclient: FTBFS without internet access: attempts to connect to a service on the internet during tests
Instead of trying to fix this, I think it’s better to let the autoremoval remove this package from Debian. The functionality which the package provides is by now part of the standard library (HTTP request timeouts), and there are no dependencies on the package currently. On Sun, Jul 5, 2015 at 5:33 PM, Chris West (Faux) < solo-debianb...@goeswhere.com> wrote: > Source: golang-mreiferson-httpclient > Version: 0.0~git20140425-2 > Severity: serious > Tags: sid stretch > Justification: fails to build from source > User: reproducible-bui...@lists.alioth.debian.org > Usertags: ftbfs > > Dear Maintainer, > > The package's tests fail when run on a pbuilder without networking, > it attempts to make a request to a website on the internet: > === RUN TestHttpsConnection > --- FAIL: TestHttpsConnection (0.00s) > httpclient_test.go:93: 1st request failed - Get > https://httpbin.org/ip: dial tcp: lookup httpbin.org: no such host > > Packages are required to build without a network connection. > > Full build log: > > https://reproducible.debian.net/rb-pkg/unstable/amd64/golang-mreiferson-httpclient.html > > -- System Information: > Debian Release: stretch/sid > APT prefers unstable > APT policy: (500, 'unstable'), (1, 'experimental') > Architecture: amd64 (x86_64) > > Kernel: Linux 3.19.0-21-generic (SMP w/8 CPU cores) > Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > ___ > Pkg-go-maintainers mailing list > pkg-go-maintain...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers > -- Best regards, Michael
Bug#786494: libgit2: diff for NMU version 0.22.2-1.1
I’m on vacation from Debian since many months after the exhausting systemd flamewars, so any Debian-related work has very very low priority currently. If you want faster uploads, I suggest you either find a sponsor with more time or become a DM, and I think we talked about the latter already :). I’m assuming jmw@ will upload the package now, so I’ll hold off doing anything to avoid conflicts. On Sun, May 31, 2015 at 12:52 PM, Russell Sim wrote: > Hey, > > I have been waiting for my maintainer to upload a new version since last > week :( he must be busy doing other things at the moment. > > > http://anonscm.debian.org/cgit/users/arrsim-guest/libgit2.git/commit/?id=1230d224b48069ba4e1b613694b94f9f6ce6b68b > > I would prefer that you upload my version if possible. Is that ok? > > Cheers, > Russell > > On 31 May 2015 at 07:30, Jonathan Wiltshire wrote: > >> Control: tags 786494 + patch >> Control: tags 786494 + pending >> >> Dear maintainer, >> >> I've prepared an NMU for libgit2 (versioned as 0.22.2-1.1) and >> uploaded it to DELAYED/2. Please feel free to tell me if I >> should delay it longer. >> >> Regards. >> >> -- >> Jonathan Wiltshire j...@debian.org >> Debian Developer http://people.debian.org/~jmw >> >> 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 >> >> > > > -- > Cheers, > Russell Sim > -- Best regards, Michael
Bug#778461: Broken rendering with DPI != 96
Package: i3-wm Version: 4.8-1 Severity: serious Lots of systems run with DPI != 96 for various reasons, one of the good reasons being that the display in question was correctly detected as not having a DPI of 96. Before the introduction of high-DPI displays (“retina” displays), everyone was just writing code that assumed 96 DPI. i3 gained support for high-DPI displays with 4.8, but required correct configuration of the DPI in order to work correctly. This upstream commit improves the situation a lot: https://github.com/i3/i3/commit/33d1d5d3c61a2136eb4b42ffd29870fd68d2d766, With that commit, existing non-high-DPI setups can still be slightly misconfigured and a DPI of 96 will be assumed. This fixes a couple of rendering glitches, most notably in the buttons of i3bar and window decoration font rendering. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778460: Restarting i3 breaks pidgin, hexchat, possibly others
Package: i3-wm Version: 4.8-1 Severity: critical When using i3’s “restart” feature, applications such as Pidgin, hexchat and others (not all, though) are killed. This is reported upstream at https://github.com/i3/i3/issues/1419 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#752075: daemontools-run: Add systemd support
Hi Gerrit, Gerrit Pape writes: >> There is a reason, why we added the logic in a single place. > > With sysvinit I have the logic easily implemented in the maintainer > scripts. With runit it's even more simple. I really don't want to > depend on some complex logic and an additional package just to have a > service as simple as the daemontools' one installed and always running, > think the inittab approach. I’m not sure how we can state this more clearly: Use dh-systemd or you _will_ have bugs sooner or later. It is the most simple implementation that we could come up with. -- Best regards, Michael -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#752075: daemontools-run: Add systemd support
Hi Gerrit, Gerrit Pape writes: > I'm really not keen to add a dependency to daemontools-run, esp. not to > the runit package, just for (un)installing and starting/stopping a > service. I presume you mean init-system-helpers as the dependency you don’t want to add. > Why isn't it as simple as installing the unit, and then?: > > systemd not installed || start service It is as simple as that. deb-systemd-invoke supports policy-rc.d, though, which your intended example (AIUI) does not. You’d make some users really unhappy if you break policy-rc.d with your package. > systemd not installed || have service started by default When systemd is not installed, where does the logic for having the service started by default come from? While the actually relevant part of that is as simple as creating a symlink, there are some things make this entire process more complicated. Some of them come from the fact that the enabled-state needs to be synchronized across init systems, i.e. what you do in systemd should also work for the sysvinit-fallback. We’ll most likely get rid of this in the next Debian release, but for now we still have to support it. Further, consider this (from the manpage of deb-systemd-helper): The "enable" action will only be performed once (when first installing the package). On the first "enable", an state file is created which will be deleted upon "purge". …which enables administrators to disable units and not have them magically re-enabled on the next package upgrade. Also, the dh-systemd/deb-systemd-helper combination properly handles mask-after-remove (i.e. remove but not purge). In general, it’s hugely beneficial to Debian if packages use the same helpers/debhelper addons to build their maintainer scripts. Bugfixes and other improvements that we put into i-s-h will propagate to all packages without coordinating huge updates/fixes. You don’t need to think about all the intricacies of correctly handling unit files (in Debian!) because we already did it. Let me also point out that _every_ system already has i-s-h installed these days, so there really is no cost in adding this dependency. -- Best regards, Michael -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#754644: golang-go.tools: FTBFS on armel/armhf/i386: test failures
control: forwarded -1 https://code.google.com/p/go/issues/detail?id=8366 Hi Cyril, Cyril Brulebois writes: > your package FTBFS on all buildds it was tried on (armel/armhf/i386), > in the test suite. Thanks. After investigating, I forwarded this issue upstream: https://code.google.com/p/go/issues/detail?id=8366 -- Best regards, Michael -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#750909: closed by Michael Biebl (Re: Bug#750909: systemd: breaks a big part of my system)
Hi Cristian, Cristian Ionescu-Idbohrn writes: > Is this a joke or what? That’s what we thought when we received your original report, but you seem to be serious. Your report is against systemd, but you are complaining about _other software_ depending on systemd, as far as I can tell. This is not in our control, so you’re in the wrong place. Please take this somewhere else. -- Best regards, Michael -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#749356: kanla: FTBFS - tests fail
control: tags -1 + pending Hi Michael, Michael Tautschnig writes: > During a rebuild of all Debian packages in a clean sid chroot (using > cowbuilder > and pbuilder) the build failed with the following error. This is already fixed with: http://code.stapelberg.de/git/kanla/commit/?id=3931c095f592f7c11a1cec051d11d6fe02a9e087 And will be addressed with the next release. -- Best regards, Michael -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#724602: dnsmasq: Please enable systemd unit on install and fix it
Hi Andreas, Andreas Metzler writes: > dnsmasq is packaged without debhelper, making this a little bit more > work. However I have simply checked what dh_systemd /would/ do and > have manually applied the changes to maintainerscripts and > dependencies to come up with the the attached patch. Could you please > doublecheck? I dislike the fact that we need to copy code here. This will be a maintenance nightmare if more packages start to do that (and frankly, one package is one too many already). Can we not port dnsmasq to debhelper? That’d be beneficial anyway :). I realize that porting it to debhelper requires more time, so I’d be okay with uploading a new version now with the copied code, but immediately following up with a ported-to-debhelper version. -- Best regards, Michael -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#746577: closed by Michael Biebl (Re: Bug#746577: systemd-sysv: for upgrade safety, systemd-sysv and sysvinit-core must be coinstallable)
Hi Zack, Zack Weinberg writes: > Note that coinstallability is not enough -- the bulletproof procedure > (e.g. "update-init-system") must also be implemented, shipped, and > documented. Your tone is way out of line. Who are you to tell us what we _must_ do? That’s not how it works. Either you do the work and convince us we should merge it or you make suggestions. But you cannot tell us what we must do in our spare time. -- Best regards, Michael -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#746577: closed by Michael Biebl (Re: Bug#746577: systemd-sysv: for upgrade safety, systemd-sysv and sysvinit-core must be coinstallable)
Hi Zack, Fundamentally we agree with you of course. The devil is in the detail, though: sysvinit-core and systemd are coinstallable, for all the reasons you explained. However, you seem to be using a package which depends on libpam-systemd, which, translated to English, means the package is using some functionality that can only be provided when logind is running. To ensure that logind is running, we had to make libpam-systemd depend on “systemd-sysv | systemd-shim”. It had to be systemd-sysv to not just ensure systemd is _present_, but to ensure it is _running_. If we don’t add this dependency, the package in question is broken, which may well be the bigger deal to most users than being able to roll back and forth between init systems :). So, if you want to keep systemd as an option and use/fall back to sysvinit, just install systemd-shim and sysvinit-core. If that’s not okay with you, figure out which package it is that depends on libpam-systemd and uninstall that. I’m afraid we don’t have any other options than that (AFAICT). -- Best regards, Michael -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
