On Tue, 2023-09-12 at 23:13 +0200, Luca Boccassi wrote:
> On Mon, 11 Sept 2023 at 15:57, Daniel Gröber
> wrote:
> >
> > Hi Luca,
> >
> > On Mon, Sep 11, 2023 at 01:06:06PM +0100, Luca Boccassi wrote:
> > > > I want to question whether removing these conffiles is a good idea at
> > > > all. I'm
On Sun, 2023-07-16 at 10:58 +0100, Nikolaus Rath wrote:
> If not, can you tell me how to test for it?
xss-lock uses dbus to talk to logind, specifically the service
org.freedesktop.login1, path /org/freedesktop/login1, via the
GetSessionByPID method of the org.freedesktop.login1.Manager
Hi Nikolaus,
Thanks for your report.
On Wed, 2023-07-12 at 18:38 +0100, Nikolaus Rath wrote:
> It seems that running xss-lock as `xss-lock --
> session=${XDG_SESSION_ID}` works around this problem.
That's correct, you either need a working logind session (which your
"Error getting session"
On Fri, 2020-01-31 at 01:11 +0530, Arjun wrote:
Thank you for your report. I'm very sorry, I seem to have somehow
missed this bug when it originally arrived, I don't know how.
> Both commands fail with a "usb_bulk_send() ERROR -7: Operation timed out" but
> if i pull the code from upstream, even
Package: qa.debian.org
Severity: normal
Dear Maintainer,
I followed the link from the tracker[0] to the BLS issues for my packages[1].
It was rather hard to figure out what specifially it was complaining about, it
would be great if the page could contain:
* The name of the tool (or tools)
I opened https://github.com/wavexx/xss-lock/pull/2 upstream, which at
least improves the docs in the example service.
Ian.
On Mon, 2023-01-23 at 17:28 -0500, Stuart Freeman wrote:
> I actually added the `-s ${XDG_SESSION_ID}` while trying to debug the
> issue after reading through #994762
>
> xss-lock had been working for over a year until as recently as a
> couple days ago when I experienced a prolonged power
On Mon, 2023-01-23 at 11:04 -0500, Stuart Freeman wrote:
> Process: 8434 ExecStart=xss-lock -s ${XDG_SESSION_ID} -n
> /usr/libexec/xsecurelock/dimmer -l -- xsecurelock (code=dumped, signal=ABRT)
Are you sure that `${XDG_SESSION_ID}` is being properly substituted
here and with the correct
Control: severity -1 important
Control: tags -1 +help
On Mon, 2023-01-23 at 11:04 -0500, Stuart Freeman wrote:
> Calling `xdg-screensaver activate` causes xss-lock to dump core.
Thank you for your report.
>From the logs it looks like xss-lock is actually hitting an assertion
which manifests in
On Sat, 2023-01-21 at 12:09 -0800, Vagrant Cascadian wrote:
> On 2022-12-29, Ian Campbell wrote:
> > On Wed, 2022-12-28 at 16:30 -0800, Vagrant Cascadian wrote:
> > > dreamplug
> >
> > booting u-boot and Debian both from external mmc
> >
> > testing:
On Wed, 2022-12-28 at 16:30 -0800, Vagrant Cascadian wrote:
> jetson-tk1
testing: 2022.04+dfsg-2+b1 ok
unstable: 2022.10+dfsg-2 ok
exp: 2023.01~rc4+dfsg-1 ok
> Bananapi
I don't seem to have a working setup for this any more, sorry.
> Cubieboard2
testing: 2022.04+dfsg-2+b1 ok
On Wed, 2022-12-28 at 16:30 -0800, Vagrant Cascadian wrote:
> On 2022-12-28, Vagrant Cascadian wrote:
> > On 2022-12-22, Vagrant Cascadian wrote:
> > > On 2022-08-20, Vagrant Cascadian wrote:
> > > > On 2022-08-10, Vagrant Cascadian wrote:
> > > > > This bug is just to delay migration to testing
On Thu, 2022-08-25 at 13:27 -0400, Antoine Beaupre wrote:
> I have xss-lock setup to start xsecurelock automatically after the
> delay prescribed by my `xset` configuration.
FWIW I've never seen it used with xsecurelock (I use i3lock) but I do
`xset b off` in my session (but not the `s 60 3`
On Sat, 2022-05-21 at 13:56 +0200, Maximilian Stein wrote:
> I can still observe these error messages in version 2.0.11-1. They are
> AFAIK caused by a missing `delaycompress` stanza in
> `/etc/logrotate.d/mosquitto`. Without `delaycompress` logrotate always
> tries to compress files immediately
On Sun, 2021-12-26 at 19:22 +, Simon McVittie wrote:
>
> I think it might work something like this:
That sounds very plausible.
Ian.
> * it is sufficient to have a single working backned;
>
> * if you're on a "full" GNOME desktop, then you have Tracker, which
> provides a separate
On Tue, 2021-11-30 at 11:03 +, Simon McVittie wrote:
> After this has had some testing in testing/unstable, we can backport
> to stable.
Many thanks!
> It seems that this bug occurs when GtkSearchEngineModel is the only
> backend returning results, so a workaround is to have have a second
>
On Sun, 2021-10-17 at 19:07 -0400, Antoine Beaupré wrote:
> And I can confirm it works, or at least does not warn.
Excellent, thanks.
Is the diff as simple as:
$ git diff
diff --git a/doc/xss-lock.service b/doc/xss-lock.service
index 52086c8..37d733e 100644
---
Control: tag -1 patch
Hello,
I can confirm that upstream commit aca83684ed4c ("searchenginemodel:
finalize search results") from the upstream MR!4030[0] for GTK3 cherry-
picks cleanly onto the dgit/dgit/bullseye branch (commit dd04b9476f67,
AKA archive/debian/3.24.24-4 tag).
I've installed the
(sorry for the delay)
On Mon, 2021-09-27 at 09:27 -0400, Antoine Beaupré wrote:
> > Worth a try I suppose, please let me know if it works and I'll update
> > the service file in the package.
>
> Okay, will try! I do see that XDG_SESSION_ID is a thing here...
Thanks.
> > Out-of-interest how
Package: libgtk-3-0
Version: 3.24.24-4
Followup-For: Bug #976334
Dear Maintainer,
I am also seeing this behaviour when searching for documents in evince's open
dialog when pointing anywhere in my NFS home directory.
Since this bug is present in stable/bullseye and there is an upstream patch
control: tag -1 upstream,help
Thanks for your report!
On Mon, 2021-09-20 at 11:42 -0400, Antoine Beaupre wrote:
> I'm not sure how to use this program.
FWIW I use it by launching from my .i3/config with:
exec --no-startup-id exec xss-lock --transfer-sleep-lock -- i3lock -d
--color 00
On Wed, 2021-05-19 at 00:03 +0200, Philip Hands wrote:
Hi Ian,
Thanks for the patch. It's proven very useful while seting up pipelines on
salsa that can be run when a udeb's git repo is pushed, such that
a mini.iso is produced that will make use of a repository containing
that udeb.
While
Package: mosquitto
Version: 1.5.7-1+deb10u1
Followup-For: Bug #960489
Dear Maintainer,
I'm also seeing this message, nearly every night I think.
I'm running stable (Buster) but I've picked up the change to use invoke-rc.d
instead of killall from #940229 but that hasn't helped, I think this
On Thu, 2021-02-25 at 07:10 +0100, Matthias Klose wrote:
> Package: src:qcontrol
> Version: 0.5.6-4
> Tags: patch
>
> allow to build without the udeb package.
>
> patch at
> http://launchpadlibrarian.net/524968245/qcontrol_0.5.6-4build1_0.5.6-4ubuntu1.diff.gz
I realised I never actually replied
On Fri, 2021-02-26 at 15:41 +0100, Bernhard Übelacker wrote:
> The attached patch is an attempt to grow the buffer size
> if the header changes on a new page.
> This is just tested for the given crash, nothing more, therefore
> there might be side effects on replacing this buffer?
It doesn't look
Control: found -1 3.20.11+dfsg0-2
Control: found -1 3.21.2+dfsg1-1
On Thu, 2021-02-25 at 18:32 +, Ian Campbell wrote:
> I'll see if I can upgrade and repeat.
Confirmed I see this with both the current bullseye and sid versions of
printer-driver-hpcups.
Ian.
Package: printer-driver-hpcups
Version: 3.20.9+dfsg0-4
Severity: serious
Tags: upstream
Justification: #972339
Dear Maintainer,
I have just filed this crash at https://bugs.launchpad.net/hplip/+bug/1904318
dagon:/tmp# /usr/lib/cups/filter/hpcups 1 debian '' 1 ''
print_step_3.hpcups
Control: found -1 2.4.1-1
Hi (again),
I was able to fix the issue by monkey patching in an "except
PermissionError: pass" around line 549
of /usr/lib/picard/picard/tagger.py, in the existing try block around
the os.scandir.
FWIW this issue was already present in 2.4.1-1 but I upgraded to latest
Package: picard
Version: 2.4.4-1
Severity: important
Dear Maintainer,
Picard is aborting when it comes across the lost+found directory in my music
mountpoint:
$ picard /storage/music/
I: 15:52:59,827 /usr/lib/picard/picard/config._backup_settings:274: Backing
up config file to
On Thu, 2020-10-01 at 14:34 +0200, Klaumi Klingsporn wrote:
> But the weird thing is that here on a second system with
> the same depending library-versions installed as Ian
> (gir1.2- and gstreamer-Packages 1.16.2-4 and
> gir1.2-webkit2-4.0 2.28.2-2+b1) all works fine even with
> the
Package: quodlibet
Version: 4.3.0-1
Followup-For: Bug #971280
I am seeing a similar crash to that reported here (on another system to the one
I am writing on, although with the same ql version).
Disabling _both_ the "Discogs Cover Source" and "MusicBrainz Cover Source"
plugins seems to avoid the
Hi all,
I switched from pass to extend for my custom endpoint since the latter
was not disabled with the security update. It's a bit more faff but not
intractable (just lots of boilerplate really) so maybe it's useful to
post here as a sort of recipe while things get sorted out some other
way in
On Sun, 2020-07-26 at 19:26 +0300, Michael Tokarev wrote:
> Control: tag -1 + moreinfo
>
> [ https://bugs.debian.org/916043 ]
>
> On Sun, 09 Dec 2018 15:19:55 +0000 Ian Campbell wrote:
> > Package: qemu-user-static
> > Version: 1:2.12+dfsg-3+b1
> > Severity
On Sat, 2020-06-27 at 12:54 +0200, Gianfranco Costamagna wrote:
> Hello Ian,
>
> > It seems like pybuild has some heuristics for picking the build
> plugin
> > to use, for me (and buildd) it selects plugin_distutils.py but for
> you
> > it is selecting plugin_cmake.py. I can't see why. If you
On Sun, 2020-06-21 at 21:52 +0200, Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
Thanks for the report Lucas.
I tried reproducing locally with:
sbuild -n -A -s --force-orig-source --apt-update -d unstable -v
--no-run-lintian
Package: sbuild
Version: 0.79.1-1
Severity: normal
Dear Maintainer,
I was trying to debug #963294 and therefore needed to build `arch: all` only. I
tried:
sbuild --arch-all --no-arch-any --dist sid --append-to-version=~0.rebuild0
-k <...> -m <...> <...>.dsc
However I got:
E: Neither
Package: wnpp
Severity: wishlist
Owner: Ian Campbell
* Package name: cmake-format
Version : 0.6.10
Upstream Author : Josh Bialkowski
* URL : https://github.com/cheshirekow/cmake_format
* License : GPL-3
Programming Lang: Python
Description : source
On Sat, 2020-03-28 at 14:39 +0100, Tomas Janousek wrote:
>
> (I also opened this as a merge request on salsa a few months ago:
Sorry, it appears I don't get notifications for these (a common problem
with Salsa I believe, since I really only intended to use it as a
simple git server so I never
On Wed, 2020-01-22 at 22:42 +, Witold Baryluk wrote:
> > The age of FTP has long passed.
>
> You think you can fit the scp or ssh then? :D I doubt so.
If you have a network to scp over then you can `anna-install` the ssh
udebs on the fly first, no need to have them in the initrd.
Soon
Package: libxmltv-perl
Version: 0.6.1-1
Severity: important
Tags: upstream
Dear Maintainer,
I have a script which does:
$grabber | tee $raw | tv_grep <...> | tee $filtered > $output
Recently it started failing because tv_grep stopped working:
Couldn't open -:
No such file or
On Wed, 2019-10-02 at 08:59 +0800, Paul Wise wrote:
> On Tue, 2019-10-01 at 11:55 +0100, Steve McIntyre wrote:
>
> > Wouldn't it just be easier to write it one location and replace the
> > other with a symlink to it?
>
> Looks like neither the urandom init script nor systemd-random-seed
> unlink
On Tue, 2019-09-24 at 10:05 +0100, Mark Hindley wrote:
> Ian,
>
> Thanks for this.
>
> On Tue, Sep 24, 2019 at 07:28:29AM +0800, Ian Campbell wrote:
> > On Fri, 2019-09-20 at 10:16 +0100, Mark Hindley wrote:
> > Would it be any help at all of the "dbus client-i
On Fri, 2019-09-20 at 10:16 +0100, Mark Hindley wrote:
> On Fri, Sep 20, 2019 at 09:06:57AM +0200, Laurent Bigonville wrote:
> > Hello,
> >
> > When I looked I elogind a while back I was able to build a package without
> > having a public libelogind0, I basically had that in my debian/rules file:
On Sun, 2019-08-04 at 15:51 +0200, Martin Michlmayr wrote:
> Copying the relevant Debian bug (#933294).
>
> * Matthieu CERDA [2019-08-04 15:42]:
> > In dmesg during boot, which I suspect means that something is wrong in
> > GPIO / PIC communication.
> >
> > I tried to replicate the way Linux
On Sun, 2019-07-28 at 22:14 +0200, Matthieu CERDA wrote:
> Package: qcontrol
> Version: 0.5.6-4~bpo9+1
> Severity: important
> Tags: patch
>
> Hello maintainer!
Hi Matthieu, thank you for the report.
> There seems to be a small typo, related to
>
On Wed, 2019-04-10 at 23:02 +0200, Robert Pommrich wrote:
> Am 10.04.19 um 22:32 schrieb Ben Hutchings:
> > On Wed, 2019-04-10 at 17:26 +0200, Robert Pommrich wrote:
> > > Hi,
> > >
> > > I really don't understand why the severity of this bug was lowered.
> > > Plus, this was the only action
On Sun, 2019-03-17 at 19:06 +0100, Matteo Croce wrote:
> #571590 added the '-f' argument to pidof, which allows to specify an
> arbitrary format string for the PIDs.
> Unfortunately this is broken, because passing plain user input to
> printf() can easily exploited:
What's the attack vector here
On Mon, 2019-02-11 at 12:06 +0200, Adrian Bunk wrote:
> certbot is not in jessie, so nothing to fix/update there.
Oh, I hadn't realised that bit, thanks for clarifying.
I have no advice/suggestions then.
Ian.
[[ Resending to correct debian-lts, I forgot the "lists." bit... ]]
On Fri, 2019-02-08 at 11:18 -0800, Brad Warren wrote:
> To provide a little more information as an upstream maintainer of
> Certbot, the lack of an upgrade here will affect a lot of Debian
> Jessie users.
>
> Let’s Encrypt
On Fri, 2019-02-08 at 11:18 -0800, Brad Warren wrote:
> To provide a little more information as an upstream maintainer of
> Certbot, the lack of an upgrade here will affect a lot of Debian
> Jessie users.
>
> Let’s Encrypt started sending out multiple emails telling affected
> users they needed
On Mon, 2019-01-21 at 16:18 -0300, Martin Michlmayr wrote:
> * Ian Campbell [2019-01-21 19:09]:
> > > Is this supposed to work at the moment or already known,
> > > or should I report it, if yes to which package.
> >
> > I think flash-kernel is probably t
On Mon, 2019-01-21 at 19:36 +0100, Bernhard Übelacker wrote:
> Is this supposed to work at the moment or already known,
> or should I report it, if yes to which package.
I think flash-kernel is probably the right starting point, although it
might turn out to be a kernel issue.
> Which
On Sun, 2019-01-20 at 22:08 +0100, Bernhard Übelacker wrote:
> Dear Maintainer,
> just a confirmation.
> I tested a new Stretch installation and upgraded to current
> Buster/testing and it went through without any issue.
>
> Thank you very much.
Awesome, thanks for letting me know!
Ian.
>
On Wed, 2019-01-16 at 23:03 +, Chris Lamb wrote:
> Hi Ian & Niels,
>
> > I: grub-common binary (2.02+dfsg1-10) [amd64]: hardening-no-bindnow
> usr/
> > bin/grub-editenv
> > I: grub-common binary (2.02+dfsg1-10) [i386]: hardening-no-bindnow
> usr/
> > bin/grub-editenv
>
> TIL we check both
On Tue, 2019-01-15 at 06:19 +, Niels Thykier wrote:
> What you see is that grub-editenv have the tag twice because the tag
> appears on different architectures (i386 vs. amd64). The reporting
> framework was never updated to include this information more smoothly
> than simply adding the tag
Package: lintian
Version: 2.5.121
Severity: normal
Dear Maintainer,
It seems that lintian.d.o lists some (all?) failures in a binary package twice.
Things look ok for the source package report.
For example at
On Sun, 2019-01-06 at 13:32 +0200, Adrian Bunk wrote:
> Package: sunxi-tools
> Version: 1.4.2+git20181114.6d598a-2
> Severity: serious
>
> https://piuparts.debian.org/sid/fail/sunxi-tools_1.4.2+git20181114.6d598a-2.log
Thanks, I was just working on a fix having spotted the report on
On Fri, 2019-01-04 at 18:06 +, Ian Campbell wrote:
> I'll also ping upstream about a possible stable backport shortly.
Sent to https://marc.info/?l=linux-netdev=154662768504311=2 (but I
forgot to Cc the bug, sorry, will update here as I hear back).
Ian.
On Fri, 2018-12-28 at 09:58 +, Ian Campbell wrote:
> I'm next going to reboot into my locally built kernel with the
> (likely/hopeful)
> fix applied. I'll follow up in a few days (maybe a week to be sure) if I don't
> see this issue recurring. If it is looking positive at that poi
On Wed, 2019-01-02 at 15:43 +, Ian Campbell wrote:
> On Wed, 2019-01-02 at 10:32 -0500, Ted To wrote:
> > My experience was that a reboot allowed qcontrol to be installed but it
> > certainly makes sense that reloading devices could fix the install as
> > well. I'm
On Wed, 2019-01-02 at 10:32 -0500, Ted To wrote:
> My experience was that a reboot allowed qcontrol to be installed but it
> certainly makes sense that reloading devices could fix the install as
> well. I'm willing to help test this -- would I install the stretch
> qcontrol (not backported),
On Wed, 2019-01-02 at 15:21 +, Ian Campbell wrote:
> On Wed, 2019-01-02 at 15:14 +0000, Ian Campbell wrote:
> > > But after booting the buster kernel qcontrol could setup
> > > successfully:
> >
> > I wonder if it is the reboot itself, and not necessarily
On Wed, 2019-01-02 at 15:14 +, Ian Campbell wrote:
> > But after booting the buster kernel qcontrol could setup
> > successfully:
>
> I wonder if it is the reboot itself, and not necessarily the switch to
> the buster kernel which is the bandaid here, i.e. if rebooting ba
On Mon, 2018-12-31 at 11:51 +0100, Bernhard Übelacker wrote:
> There I can confirm the installation of the qcontrol package
> failed while running the stretch kernel:
Thanks, unfortunately I would need the same set of things I asked Ted
for in
Package: src:linux
Version: 4.9.130-2
Severity: normal
Tags: upstream
Dear Maintainer,
Every few days rkhunter starts reporting in its daily report:
Warning: Hidden ports found:
Port number: TCP:697
Which corresponds to running unhide-tcp:
# unhide-tcp --lsof
On Sat, 2018-12-22 at 08:00 -0500, Ted To wrote:
> After reverting it and rebooting everything is now working fine.
Excellent, thanks for letting me know.
Ian.
On Fri, 2018-12-21 at 21:30 +0300, Michael Tokarev wrote:
> 09.12.2018 18:19, Ian Campbell wrote:
> > Package: qemu-user-static
> > Version: 1:2.12+dfsg-3+b1
> > Severity: normal
> >
> > Dear Maintainer,
> >
> > While working on a new qcontrol pa
Control: found -1 3.1+dfsg-1
On Fri, 2018-12-21 at 16:38 +0300, Michael Tokarev wrote:
>
> Can you please verify if this is still a problem for version 3.1 currently
> in unstable? (since it is a static binary you can install the package
> directly from unstable or just grab the binary you need
On Fri, 2018-12-21 at 06:25 -0500, Ted To wrote:
> Still broken for me. I used Bernhard's workaround and qcontrol
> starts.
Thank you for letting me know. Unfortunately this works for me locally
so I need more information from an affected system with no workarounds
applied to diagnose.
Please
. (Closes: #916602).
+
+ -- Ian Campbell Sun, 16 Dec 2018 14:05:52 +
+
flexbackup (1.2.1-6.3) unstable; urgency=medium
* Non-maintainer upload.
diff -u flexbackup-1.2.1/debian/patches/00list flexbackup-1.2.1/debian/patches/00list
--- flexbackup-1.2.1/debian/patches/00list
+++ flexbackup
Package: flexbackup
Version: 1.2.1-6.3
Severity: normal
For some time (years) find has been producing a warning when called by
flexbackup
find: warning: you have specified the -xdev option after a non-option
argument -regex, but options are not positional (-xdev affects tests specified
Package: qemu-user-static
Version: 1:2.12+dfsg-3+b1
Severity: normal
Dear Maintainer,
While working on a new qcontrol package, using a cross-schroot via
qemu-arm-static on an amd64 host, I noticed that globs did not appear to be
expanded when running dash. It appears to relate to libc 2.28-2 but
Control: tag -1 +help
Thanks for you report.
On Sat, 2018-11-24 at 18:26 +0200, Teemu Ikonen wrote:
> I think the correct behaviour in the case of cycle time = 0 would be
> to run the notification and locker commands one after the other.
I suppose when cycle time = 0 the
On Thu, 2018-07-19 at 04:58 +1000, Paul "TBBle" Hampson wrote:
> Just in case this bug report was unexpected, I've gotten a local
> backport build working.
Excellent thanks, sorry for completely missing this bug when you filed
it.
> However, I had to take a couple of extra steps to get it fully
On Tue, 2018-11-20 at 02:46 +0100, Bernhard Übelacker wrote:
> Package: qcontrol
> Version: 0.5.6-1
> Severity: important
Thank you for your report.
> Therefore I made following change and qcontrol started up
> successfully, as far as I can see:
> root@qnap-119p-ii:~# nano
I think this might be the same as 914495.
On Sat, 2018-12-01 at 17:33 -0800, Bill Brelsford wrote:
> I get the same behavior (except at 0004) with
> linux-image-4.18.0-3-686-pae. 4.18.0-2 was ok.
On my system I observed that `modprobe i915` had hung (it was killable
and I could try again,
On Thu, 2018-11-15 at 14:42 +0100, Andreas Henriksson wrote:
> On Thu, Nov 15, 2018 at 01:07:20PM +0000, Ian Campbell wrote:
> > Would it make sense for d-i to take responsibility for adding the `
> > --force` when setting up in `sudo`-only mode (i.e. when locking the
> > ro
On Thu, 2018-11-15 at 13:35 +0100, Andreas Henriksson wrote:
> Hello,
>
> On Thu, Nov 15, 2018 at 05:47:03PM +0800, Benda Xu wrote:
> [...]
> > I think it a common Debian practice to set root
> > passwords. Disabling
> > root login and put everything on `sudo` feels very Ubuntu.
>
> The
On Wed, 2018-10-31 at 13:42 +0100, Mathias F. wrote:
> Hi Ian,
>
> Am 31.10.2018 um 13:12 schrieb Ian Campbell:
> >
> > Are you able to confirm that things work with 0.5.6-1~bpo9+1 if you
> > manually create /lib/udev/rules.d/60-qcontrol.rules containing:
> >
&g
Control: found -1 0.5.6-1
Control: found -1 0.5.6-1~bpo9+1
On Wed, 2018-10-31 at 12:48 +0100, Mathias F. wrote:
> But it does not provide the mentioned udev rules file:
Indeed, there is a typo in my debian/rules so it doesn't actually get
included, even in the non-bpo version, sorry :-(.
I
Control: found -1 0.5.5-2
On Wed, 2018-10-31 at 08:19 +0100, Michael Biebl wrote:
> Control: reassign -1 qcontrol
Thanks Michael!
> Am 31.10.18 um 07:24 schrieb Mathias F.:
> > On Tue, 30 Oct 2018 21:36:16 +0100 Michael Biebl wrote:
>
> > Package: qcontrol
> [...]
> > Version: 0.5.5-2
>
>
On Mon, 2018-09-10 at 21:59 +0200, Helmut Grohne wrote:
> qcontrol fails to cross build from source, because the upstream
> Makefile
> hard codes the build architecture pkg-config. After making it
> substitutable it gets substituted by dh_auto_build and qcontrol cross
> builds successfully. Please
On Thu, 2018-10-18 at 11:48 +0800, Shengjing Zhu wrote:
> Package: awscli
> Followup-For: Bug #907298
>
> The corresponding bug on Redhat is closed as
>
> > Closing this bug as NOTABUG and asked MITRE for rejection, since the issue
> > does not seem to be in AWS CLI but in Packer.
>
> Can we
On Fri, 2018-08-31 at 14:52 -0700, Geoff Levand wrote:
> In summary, the latest released m400 firmware
> did not support APEI, and so no special work-around or kernel quirk
> support is needed.
That seems reasonable enough to me, no reason to support random back-
channel (un)released firmware.
On Thu, 2018-08-30 at 13:23 +0100, Martín Ferrari wrote:
> > Unless the tests are run in their own network namespace (which provides
> > some guarantees over what else might be bound to a port, I can't seem
> > to find logs which would confirm or deny if a netns was in use here
> > though)
On Mon, 2018-08-27 at 19:18 +0100, Martín Ferrari wrote:
> On 27/08/18 17:08, Adrian Bunk wrote:
>
> > How often did you try?
> >
> > I would say the probability to hit is somewhere around 50%:
> > https://tests.reproducible-builds.org/debian/history/prometheus.html
>
> I just tried 20 builds,
On Fri, 2018-08-17 at 10:22 +0200, Somebody else wrote:
> Any pointers?
Have you seen https://wiki.debian.org/SecureBoot ? I'm not involved in
that effort but AIUI it describes the plan for what (and why) is going
through at the moment WRT enabling secure boot out of the box in Debian
(which,
On Mon, 2018-08-06 at 23:47 +0800, Ben Hutchings wrote:
> On Mon, 2018-08-06 at 14:40 +0100, Ian Campbell wrote:
> > On Mon, 2018-08-06 at 21:15 +0800, Ben Hutchings wrote:
> > > > Inspecting the initramfs shows that the cryptsetup related
> > > > parts are
&g
On Mon, 2018-08-06 at 21:15 +0800, Ben Hutchings wrote:
> > Inspecting the initramfs shows that the cryptsetup related parts are
> > missing for 4.17, but still in the 4.16 kernel.
> >
> > I was able to mitigate the issue by use the cryptsetup packages from
> > buster.
>
> This is strange.
Package: duck
Severity: normal
http://duck.debian.net/static/sp/q/qcontrol.html reports:
Homepage http://www.hellion.org.uk/qcontrol/
Curl:0 HTTP:200 No error
Website seems to be outdated, is probably a parked domain or for sale.
Please update your links!
However this is a correct
Package: duck
Severity: normal
The footer of e.g. [0] contains:
Source code is https://anonscm.debian.org/cgit/collab-maint/duck-website.git;>available
Which is a 404 link[1]. I tried to search[2] on Salsa for a replacement but
couldn't find anything.
Ian.
[0]
Sorry for the unexplained reopen, I expected `bts reopen` to give me
the opportunity to write something.
AFAICT the upstream bug remains open and [0] indicates that the
workaround is only temporary. Neither [1] nor any of the issues it
links to as closed seem related and [2] does show any changes
On Fri, 2018-06-29 at 16:27 +0100, Ian Campbell wrote:
> The patch there is ok as a local workaround, I think, but maybe not
> appropriate
> for the package, I'd guess either creating /var/run/mythtv-status.motd and
> having a snippet produce that or just having a snippet produce
Package: mythtv-status
Version: 0.10.8-1
Severity: normal
Hello,
I just installed this package and the motd updating functionality is not
working. I can see that it is correctly populating /var/run/motd.dynamic but
that is not being incorporated into the actual motd (wherever that is/however
On Wed, 2018-06-13 at 12:25 -0700, Geoff Levand wrote:
> On 06/09/2018 05:15 AM, Ian Campbell wrote:
>
> > I think this is probably something for the arch (or perhaps
> > platform)
> > code to deal with. See for example all the various platform quirks
> > in
> >
On Fri, 2018-06-08 at 12:33 -0700, Geoff Levand wrote:
> On 06/05/2018 12:28 AM, Ian Campbell wrote:
> > On Tue, 2018-06-05 at 02:14 +0100, Ben Hutchings wrote:
> >
> >> I don't think it's OK to cause a regression like this. Since this
> is
> >> probl
openjdk has been removed but I am seeing something similar with openjdk
to, so reopened + reassigned.
With 10 installed:
$ ./Minecraft.jar
invalid file (bad magic number): Exec format error
$ /usr/lib/jvm/java-10-openjdk-amd64/lib/jexec Minecraft.jar
invalid file (bad magic
On Tue, 2018-06-05 at 02:14 +0100, Ben Hutchings wrote:
> I don't think it's OK to cause a regression like this. Since this is
> problem affects a specific known platform, the driver ought to
> recognise it and disable itself automatically.
Indeed, while the Fedora bug upthread claims such a
On Thu, 2018-05-24 at 09:27 +0100, Ian Campbell wrote:
> So I think removing ivtv-utils from Debian is probably the best
> answer.
> Unless someone from the X-Debbugs-Cc line suggests oherwise I will do
> so, lets say on or after 1 June 2018 (a bit over a week from today).
Package: ftp.debian.org
Severity: normal
Although the package is currently orphaned I was the maintainer (when I was a
DM with my i...@hellion.org.uk address, with Mark Purcell's sponsorship) so
doing a ROM request, I hope that's not too out of line.
I believe the package is no longer of use
1 - 100 of 1693 matches
Mail list logo
