Alban Browaeys (2024-03-21):
> On Thu, 14 Mar 2024 22:04:33 +0100 intrigeri
> wrote:
> https://gitlab.gnome.org/GNOME/tracker-miners/-/merge_requests/516/diffs
>> … which I understand will be included in 3.7 stable.
>
>
> Should be fixed by 3.7.0-1 which is available
dditional context, all this stuff has never been really
maintained in Debian proper; it was once used by Ubuntu, together with
their own AppArmor profile for Chromium, but since they moved to
shipping Chromium as a Snap and don't use this AppArmor
policy anymore.
Cheers,
--
intrigeri
ase.
If I misunderstood something important, please let me know.
Cheers,
--
intrigeri
ect the
right people.
Cheers,
--
intrigeri
20 magit-toplevel:tramp (1.286620 sec)
passed 20/20 magit-utils:add-face-text-property (0.000050 sec)
Ran 20 tests, 18 results as expected, 2 unexpected (2022-11-22 08:13:31+,
6.072702 sec)
2 unexpected results:
FAILED magit-get
FAILED magit-toplevel:submodule
I feel I'm out o
Package: pdf-redact-tools
Version: 0.1.2-4
Severity: serious
Hi,
At least on Bullseye and sid, any pdf-redact-tools operation fails
with an error like:
convert-im6.q16: attempt to perform an operation not allowed by the security
policy `PDF' @ error/constitute.c/IsCoderAuthorized/421.
Feel free to downgrade severity if this does not affect all systems :)
Thanks for maintaining Dino in Debian!
--
intrigeri
Package: elpa-ledger
Version: 3.1.2~pre3+g5067e408-2
Severity: serious
Hi,
When upgrading my sid system today, which included the upgrade to
Emacs 28.1, byte-compilation of the ledger .el files failed,
which broke the upgrade. See log below.
I understand that's because
Package: elpa-dimmer
Version: 0.4.2+repack-2
Severity: serious
Forwarded: https://github.com/gonewest818/dimmer.el/issues/50
Hi,
When upgrading my sid system today, which included the upgrade to
Emacs 28.1, this broke:
Install emacsen-common for emacs
emacsen-common: Handling install of
Package: hiera-eyaml
Version: 3.2.2-2
Severity: serious
Hi,
I usually use "eyaml edit FILE.eyaml" to edit files.
It's currently broken for me on sid.
Even this simpler command fails:
$ eyaml version
Traceback (most recent call last):
7: from /bin/eyaml:25:in `'
6: from
Hi,
Dr. Tobias Quathamer (2021-12-13):
> thanks a lot for your work! I've added some more tweaks and uploaded the
> new version to unstable.
Thanks!
> As a side note: in your local repository, there's probably a tag for
> upstream/1.20.1, which is missing on salsa. Could you please push that
Hi,
intrigeri (2021-12-05):
>> I understand this is upstream bug
>> https://github.com/beancount/fava/issues/1266,
>> that's been fixed in the 1.19 release.
>
> Upgrading fava requires python3-flask-babel (>= 1).
>
> I'll try to update it.
I've uploaded p
Hi,
> I understand this is upstream bug
> https://github.com/beancount/fava/issues/1266,
> that's been fixed in the 1.19 release.
Upgrading fava requires python3-flask-babel (>= 1).
I'll try to update it.
Control: tag 995909 + ftbfs
Control: tag 995909 + bookworm
Control: tag 995909 + sid
Control: severity 995909 serious
Control: reassign 995909 src:fava
Control: merge -1 995909
Hi,
Lucas Nussbaum (2021-10-24):
>> help2man: can't get `--help' info from PYTHONPATH="/<>/src"
>> python3 -m fava.cli
Hi,
intrig...@debian.org (2020-10-25):
> Any objection to removing the package from testing & sid?
I've requested the removal of this package from sid: #996441.
Cheers!
Hi,
intrig...@debian.org (2018-11-14):
> Unless upstream and package maintenance are taken over by July 2019,
> I'll orphan the package or request it to be removed from sid (I'm
> undecided yet, opinions welcome).
I'm going to orphan this package.
Cheers!
Control: severity -1 important
intrigeri (2021-06-02):
> I see you've made this bug RC. I'd like to better understand the
> severity, so I can figure out what I should do for Bullseye.
> I'm wondering because I'm using this AppArmor policy on sid with
> apt-cacher-ng myself, and
and I can't find traces of such denials in
my logs.
Could you please help me understand what kind of apt-cacher-ng
operations (or configuration) trigger these denials and are broken by
the current AppArmor policy?
Thanks in advance,
cheers!
--
intrigeri
the copied abstraction with
a dependency on apparmor-profiles-extra at some point, let me know if
there's anything you need from me.)
Cheers,
--
intrigeri
Hi,
FYI, after a 28 months long process, I've just requested the removal
from unstable of libgtk2-perl and its reverse-dependencies, which
includes this package: #986109.
If you, or someone else, still cares about this package, I hope
they'll succeed in porting it to a current GUI toolkit, such
Package: libparse-keyword-perl
Version: 0.09-1
Severity: serious
As pointed out by Jonas Smedegaard a month ago¹, this module is
deprecated upstream: the upstream homepage² explicitly states "DO NOT
USE!".
Jonas analysis lead him to conclude that we can, and should, remove
this package and its
Hi,
James Henstridge (2021-02-16):
> 2. As for why Debian is not being considered for "full" support,
> I suspect this is down to the out-of-tree patches to enable access
> control for unix domain sockets. This will likely resolve itself
> when snapd moves to use the new AppArmor 3.0 network
Hi,
Dominic Hargreaves (2020-11-10):
> On Tue, Nov 10, 2020 at 09:03:42AM +0100, intrigeri wrote:
>> Dominic Hargreaves (2020-11-09):
>> > A year on, it seems there's almost no realistic prospect of this
>> > package coming back. Shall we remove it from sid?
Hi,
Dominic Hargreaves (2020-11-09):
> A year on, it seems there's almost no realistic prospect of this
> package coming back. Shall we remove it from sid?
Thank you for caring!
Quoting the plan I proposed #912860: "I intend to remove libgtk2-perl
from testing soon after the Buster release, and
Control: severity -1 normal
Control: retitle -1 Inactive upstream
Hi Mike,
Mike Gabriel (2020-10-26):
> I don't think that libgstreamer1-perl as found in Debian is the one
> provided by GNOME/Gtk / referenced in the given URL / deprecation
> announcement.
You're right!
This one is
Source: libclutter-perl
Severity: serious
User: debian-p...@lists.debian.org
Usertags: rm-candidate
Hi,
upstream announced¹ that the Clutter Perl module would be deprecated
in December 2020. It is actually already archived on their GitLab,
so:
- The module will no longer be updated with
Source: libgstreamer1-perl
Severity: serious
X-Debbugs-Cc: Mike Gabriel
User: debian-p...@lists.debian.org
Usertags: rm-candidate
Hi,
upstream announced¹ that the GStreamer Perl module would be deprecated
and archived in December 2020:
- The module will no longer be updated with security
Hi,
gregor herrmann (2020-09-26):
> All reverse build dependencies are fixed
Congrats to everyone who helped make this happen ! \o/
> Any last words before we file an RM bug?
None from me.
Cheers!
Hi Uli!
Uli Scholler (2020-09-01):
> When I received your initial bug report, I followed the advice given in
> Perl's Gtk3 module documentation to "run s/Gtk2/Gtk3/ on [the]
> application." Unfortunately, that didn't work at all and I put it aside.
Yeah, a mere s/Gtk2/Gtk3/ suffices only for
Richard Hansen (2020-08-23):
> On 2020-08-23 05:59, intrigeri wrote:
>> - libtitanium-perl: webapp framework, overlay on top of
>>CGI::Application, last upstream release in 2009, tiny popcon, but
>>I see Richard Hansen added themselves to Uploaders a few days ago,
&g
Hi,
intrig...@debian.org (2019-07-26):
> libcgi-application-perl build-depends on pkg-components. The Debian
> Perl group has decided today that we don't want pkg-components to be
> included in the Bullseye release, unless someone steps up and
> volunteers to be its upstream maintainer:
>
Hi,
intrigeri (2020-08-20):
> Simon McVittie (2020-08-20):
>>> I'll file bugs against all reverse-dependencies to alert their
>>> maintainer about this situation.
>>
>> Should the bugs against rdeps be escalated to serious at this point,
>> potentially t
Hi David,
David Paleino (2020-08-21):
> Yes, please go ahead, and sorry for not reacting before.
No problem! I've filed a RFH: #968843.
Cheers!
Hi David,
intrigeri (2019-09-16):
> In case you've missed it, here's my message from 2 months ago:
>
> intrigeri:
>> as announced on this bug report and on debian-devel@ in November 2018,
>> GTK 2 is going away in Bullseye, so I'm hereby bumping severity of
>> t
Hi!
intrigeri (2019-07-16):
> as announced on this bug report and on debian-devel@ in November 2018,
> GTK 2 is going away in Bullseye, so I'm hereby bumping severity of
> these bugs, on every reverse-dependency of libgtk2-perl, to RC.
>
> I hope that upstream will port the code t
Hi Marvin,
intrigeri (2019-07-16):
> as announced on this bug report and on debian-devel@ in November 2018,
> GTK 2 is going away in Bullseye, so I'm hereby bumping severity of
> these bugs, on every reverse-dependency of libgtk2-perl, to RC.
>
> I hope that upstream will port th
Hi,
I've requested removal: #968725
Control: severity 933111 serious
Control: severity 933112 serious
Control: severity 933113 serious
Control: severity 933114 serious
Control: severity 933115 serious
Control: severity 933116 serious
Control: severity 933118 serious
Hi,
Simon McVittie (2020-08-20):
> It's been over a year and this
Control: severity -1 important
Control: tag -1 + moreinfo
Control: user pkg-apparmor-t...@lists.alioth.debian.org
Control: usertags + buggy-profile
Hi,
> I installed lxc on a freshly installed debian 10 (standard iso + the tasks:
> desktop, kde, print-server, laptop).
First, I'd like to ensure
Hi,
Wilmer van der Gaast (2020-06-12):
> wilmer@veer:~/adsb$ sudo puppet agent --waitforcert 60 -t
> /usr/lib/ruby/vendor_ruby/puppet/util.rb:461: warning: URI.escape is
> obsolete
> /usr/lib/ruby/vendor_ruby/puppet/file_system/file_impl.rb:80: warning: Using
> the last argument as keyword
Hi,
Axel Beckert (2020-06-07):
> Since Guillem cleared up this and even provided a patch for aptitude
> (which is applied and in testing for a week or two), I changed my
> opinion on this topic completely.
>
>> If another team member +1's the package removal, I'll happily proceed.
>
> Seconded.
Hi,
I've just filed a removal request: #962520
Cheers!
Hi,
gregor herrmann (2020-05-22):
> On Fri, 22 May 2020 09:58:12 +0200, intrigeri wrote:
>
>> So, once aptitude >= 0.8.13-1 has migrated to testing, we'll need to
>> ask (presumably the release team) for libparse-debianchangelog-perl to
>> lose its "key pac
Hi,
intrig...@debian.org (2019-07-26):
> Therefore, at the pkg-perl BoF today at DebConf, after pondering other
> options such as orphaning this package, we decided that we don't want
> this package to be included in Bullseye (at least, maintained under
> the Perl team umbrella) unless someone
Hi,
Niko Tyni (2020-05-21):
> So IMO we should either to package Graphics::ColorNames::HTML even though
> it's deprecated, or drop Color::Calc from Debian.
> libcolor-calc-perl has just one reverse dependency AFAICS:
> libcgi-application-plugin-authentication-perl.
I took a quick look.
At
https://rt.cpan.org/Ticket/Display.html?id=119351 >
Dear Maintainer,
The Debian perl group is reviewing packages with bugs which make them
un-releasable; in particular when they are not heavily used by Debian users.
We would like to remove such modules from Debian if we don't think they are
I've filed a removal bug: https://bugs.debian.org/960794
Hi Graham & pkg-privacy-team,
Graham Inggs (2020-03-15):
> The autopkgtests of onioncircuits started to fail with Python 3.8 as
> the default Python3 interpreter [1].
> […]
> File "/usr/lib/python3/dist-packages/stem/control.py", line 2170, in
> get_conf
> entries =
Package: python3-stem
Version: 1.7.1-1.1
Severity: serious
Hi,
onioncircuits fails to start on current sid:
Traceback (most recent call last):
File "/bin/onioncircuits", line 657, in
app = OnionCircuitsApplication()
File "/bin/onioncircuits", line 633, in __init__
ting them as conffiles, that outweigh
this drawback?
Cheers,
--
intrigeri
Hi,
Antoine Beaupré:
> I also had to add:
> owner @{torbrowser_home_dir}/updater ix,
FWIW, this one is fixed in upstream Git (too):
https://github.com/micahflee/torbrowser-launcher/pull/442
Hi!,
Guillem Jover:
> Ah! Thanks for the info. How about the following clarification then? :)
Perfect! That's exactly what I would have needed :)
Cheers,
--
intrigeri
Hi,
Guillem Jover:
> On Sat, 2019-07-27 at 12:20:00 -0300, intrigeri wrote:
>> gregor herrmann:
>> > In dpt-new-upstream we're using Dpkg::Changelog::Debian from
>> > libdpkg-perl, which might help here as well.
>> Oh, this is very interesting, thanks! I h
'm very much inclined to trust your
expertise on this front, so I've applied your suggestion (locally for
now).
I would greatly appreciate a practical example in which "set -e &&
" does not behave as I thought it would :)
Thanks!
Cheers,
--
intrigeri
ething that works really
nicely already.
This includes Rust packages and therefore, we're affected by this bug.
Cheers,
--
intrigeri
Control: retitle -1 libmoox-options-perl: test regression with
librole-tiny-perl 2.001003-1
Control: forwarded -1 https://github.com/celogeek/MooX-Options/pull/69
Hi again,
intrigeri:
>> Maybe yesterday's upload of libnamespace-autoclean-perl?
> Hmm, AFAICT libmoox-options-perl does n
coding — facepalm).
> Maybe yesterday's upload of libnamespace-autoclean-perl?
Hmm, AFAICT libmoox-options-perl does not depend (even transitively)
on libnamespace-autoclean-perl, so I have a doubt. But who knows :)
Cheers,
--
intrigeri
y. I believe the actions Jeremy
suggested on #891877 will solve the problem shirish is raising here,
improve the life of Synaptic's users, and make it clearer what is the
status of libgtk2-perl in the archive.
Thoughts?
(Oh my, so many words for a bug that can be fixed by s/2/3/ in one
single place :)
Cheers,
--
intrigeri
ers,
--
intrigeri
it would
be fine to remove libgtk2-perl and its reverse-dependencies from
testing. Some might see this as a heavy hammer approach, but this was
announced a year ago to all affected maintainers; either way, it will
happen during the Bullseye cycle, eventually.
Cheers,
--
intrigeri
intrigeri:
> next step here is to remove this package from sid,
> as it blocks the removal of libgtk2-perl (#912860).
All the blockers were resolved so I've just requested the removal of
libgtk2-gladexml-perl from sid: #940499.
Cheers,
--
intrigeri
Hi David,
In case you've missed it, here's my message from 2 months ago:
intrigeri:
> as announced on this bug report and on debian-devel@ in November 2018,
> GTK 2 is going away in Bullseye, so I'm hereby bumping severity of
> these bugs, on every reverse-dependency of libgtk2-perl, to
Hi again,
intrigeri:
> I'm very glad I was mislead. It looks like Dpkg::Changelog{,::*} are
> sufficient for many, if not most, use cases of Parse::DebianChangelog :)
Hoping it will help other affected folks go through this transition,
here are MRs that give examples about how some co
he documentation accordingly: for example, the "load" method that
our new-upstream script uses does not seem to be documented anywhere.
Cheers,
--
intrigeri
Control: tag -1 pending
Hello,
Bug #933069 in libglib-perl reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
version of GLib we're using at runtime. I'm preparing a fix that I'll
submit upstream.
Cheers,
--
intrigeri
intrigeri:
> https://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=libparse-debian-changelog-removal=debian-perl%40lists.debian.org
Scratch that (typo), it is actually:
https://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=libparse-debian-changelog-perl-removal=debian-perl%40lists.debian.org
be reimplemented using dpkg-parsechangelog(1),
either in Parse::DebianChangelog itself or in a brand new module.
Cheers,
--
intrigeri
packages¹ so this RC bug won't trigger the autoremoval machinery for
it, nor for any of its reverse dependencies.
[1] https://udd.debian.org/cgi-bin/key_packages.yaml.cgi
Cheers,
--
intrigeri
,
--
intrigeri
oval=debian-perl%40lists.debian.org
Cheers,
--
intrigeri
.
Cheers,
--
intrigeri
Hi,
intrigeri:
> I'll try to reproduce with the package that's in the archive.
Reproduced ⇒ I'll request a binNMU unless I find a good reason to do
a sourcefull upload today.
Cheers,
--
intrigeri
age that's in the archive.
Cheers,
--
intrigeri
p; understand
why it's not sufficient.
[1]
https://salsa.debian.org/perl-team/modules/packages/libglib-perl/merge_requests/1
Cheers,
--
intrigeri
in a way that leaves the old passphrase
working, which is better than making the device totally unusable.
Guilhem (Cc'ed) and I are investigating this possible problems and
potential solutions.
Cheers,
--
intrigeri
diff --git a/debian/changelog b/debian/changelog
index c9bfefa..a5a8c2c 100644
Hi,
intrigeri:
> Dmitry Smirnov:
>>> If one of you feels responsible for maintaining this package but
>>> temporarily lacks time, I (or one of the attendees to one of the many
>>> upcoming BSPs) will gladly fix this with a NMU.
>> Please, please. That would
Hi,
first, thanks for the fast reply :)
Alejandro Garrido Mota:
> Let's remove it from the archive.
OK.
> Let me know if you need something from my side.
I'll file the RM bug right away, so we should be good.
Cheers,
--
intrigeri
olly just nicely explained me on IRC a few things about the
autoremoval machinery and how it affects removing from testing
libgtk2-perl and its reverse-dependencies:
- A set of RC buggy packages that have no reverse-deps outside of
this set, should all be autoremoved together at some point,
e
maintainer; if I still get no reply, I'll go through whatever process
is needed in order to request the removal.
Cheers,
--
intrigeri
to be?
Cheers,
--
intrigeri
Hi,
Antoine Beaupré:
> On 2019-05-03 17:15:59, intrigeri wrote:
>>> 1. maintain through backports (seems to have been the option taken for
>>> stretch)
>>
>> That might be viable if the AppArmor profiles are disabled by default.
> Why would we disable a
d in GNOME Software
as a Flatpak or Snap
This would cover the initial installation via usual means for
non-technical users (GNOME Software). It provides sandboxing at
least as good as AppArmor's, without the UX cost.
Cheers,
--
intrigeri
intrigeri:
> Would you be interested in testing whether
> https://gitlab.gnome.org/GNOME/gnome-settings-daemon/merge_requests/84
> fixes this problem for you?
FWIW the patch proposed upstream applies nicely on top of our
debian/unstable branch:
https://salsa.debian.org/gnome-team/gnome
ome-settings-daemon/merge_requests/84
fixes this problem for you?
Cheers,
--
intrigeri
m
Iain found.)
Cheers,
--
intrigeri
gtk2 to Qt5, and from twisted to
requests/socks.
If my team-mates disagree and want to give it a try anyway, fine.
Then, I would strongly recommend disabling the AppArmor profiles in
Buster by default.
Cheers!
--
intrigeri
t. reading the
blockresize's documentation before using it and wrt. having proper
backups, which makes the "causes serious data loss" justification
disputable IMHO.
Cheers,
--
intrigeri
ot Buster once it's released)
- one has not disabled automatic installation of Recommends
Cheers,
--
intrigeri
n
apparmor_parser -r -T -W "$APP_PROFILE" || true
fi
This is clearly not ideal, because depending on package configuration
ordering, some profiles may be loaded and some might not be.
I've not thought much about this problem yet, but I suspect that for
service packages such as LXC, handling this sort of things at the
systemd unit level might give us more robust ordering than what we're
currently doing via postinst. Food for thought :)
Cheers,
--
intrigeri
already but I'm
not familiar with LXC and I don't know if they'll apply to
pre-existing containers.)
Thanks in advance!
Also, I'm setting severity to non-RC as it would be unfortunate to
block the migration to testing of… the very version that likely fixes
this bug. Once it's clarified that this is #916639, I'll fix
the metadata.
Cheers,
--
intrigeri
execute' for nil:NilClass
# ./spec/functions/ensure_packages_spec.rb:4:in `block (2 levels) in '
Cheers,
--
intrigeri
q=%40%7BXDG_
[3]
https://codesearch.debian.net/search?q=abstractions%2Fuser-%28download%7Cwrite%29
Cheers,
--
intrigeri
intrigeri:
> Michael Biebl:
>> Please let us know about the results of those tests.
> Will do!
All green from the perspective of Tails' integration test suite :)
I'll let you know if the reviewer for this Tails proposed change (most
likely lamby) finds issues relevant to Debian.
Hi Michael!
Thanks for the quick answer.
Michael Biebl:
> Am 13.01.19 um 10:46 schrieb intrigeri:
>> What's your plan wrt. stretch-backports?
> I do think we nailed the worst regressions by now, so my plan was to
> wait until 240-4 has migrated to testing and then upload th
on the systemd package!
Cheers,
--
intrigeri
gregor herrmann:
> Sounds like a removal candidate?
Agreed ⇒ usertagged as such :)
/bugreport.cgi?bug=878193;msg=7)
So I don't understand why this bug should be RC for Buster: it does
not actually affect Buster and there's no supported upgrade path given
PuppetDB was not part of any Debian stable release yet.
Adrian, what do you think? Thanks in advance!
Cheers,
--
intrigeri
h the AppArmor-related bugs, probably
in a few weeks or so.
Cheers,
--
intrigeri
tls protect
Debian users against exploitation, so I find RC severity hard to
justify given this only affects users who manually pass --debug under
a non-default sysctl/kernel configuration.
In any case, this should be fixed :)
Cheers,
--
intrigeri
1 - 100 of 612 matches
Mail list logo
