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,
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
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 spec
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'
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
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
> S
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/co
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 a
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 pu
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
close 879483
thanks
--
Best regards,
Michael
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
> $buil
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://pk
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
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,
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 wro
:
> 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 regressi
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 De
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 --p
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?
>
>
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_mak
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.
T
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
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 pat
close 866172 3.0.0-1
thanks
--
Best regards,
Michael
close 839293 1.12-1
thanks
--
Best regards,
Michael
close 841590 1.12-1
thanks
--
Best regards,
Michael
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,
>
> th
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
>
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
ie(-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
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
> > ou
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-
.
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
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
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, 20
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
>
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
>
> > > >
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
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
&& ./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
, 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:
> >
> > […]
> > [pi
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 Sta
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
> >
t? 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 +020
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:
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
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 (=
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 pack
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 t
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 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.1
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:/
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
> &
:
> 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 relo
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
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
[+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
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
>
D
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/free
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/hint
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
>
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:ka
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=
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,
>
> Unfortun
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
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
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
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.
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
e 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.
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
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 C
[+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
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 d
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:
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
>
>
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+git2015072
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 mach
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 t
(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, Michae
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
> Justificatio
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 upstrea
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:
> >> con
: 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
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 wr
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 bui
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:3
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 :).
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
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.or
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 jus
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 ins
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/issue
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
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=3931c095f59
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
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
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
1 - 100 of 207 matches
Mail list logo
