I can confirm this version of systemd breaks my system's boot as well. I don't
have any
modified journald.conf settings.
I'm running dracut, and the image that is built fails to start
systemd-modules-load.service
Running systemd-modules-load (rd.shell=1 rd.break=cmdline) at the (dracut)
shell
that dpkg-dev version 1.22.5 (or later) allows you to use
Provides: ${t64:Provides}
to automatically generate the versioned Provides: line.
Best,
Antonio Russo
OpenPGP_0xB01C53D5DED4A4EE.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
nd trigger another build attempt.
So, I'm asking for someone to please "give back" the build to the buildds, so
that
we can spin the roulette wheel and hopefully get a buildd with an ipv4 address.
Best,
Antonio Russo
[1] https://tracker.debian.org/pkg/krb5
OpenPGP_0xB01C53D5DED4A4EE.asc
control: tag -1 patch
This breaks builds of many things including, e.g., kwin.
I'm attaching couc...@debian.org 's patch, which fixed 5.103.0-3, but
apparently never got into the git repository.
Best,
Antonio Russo
(hello other Antonio!)
--- ../kcmutils/debian/libkf5kcmutils-bin.install 2023-06
the unavailable class.
Matthew Ahrens has fixed this with upstream commit b72efb751 [1].
Best,
Antonio Russo
[1]
https://github.com/openzfs/zfs/commit/b72efb751147ab57afd1588a15910f547cb22600
Source: zfs-linux
Version: 2.0.1-1
Severity: grave
Tags: upstream
Justification: causes data loss
X-Debbugs-Cc: aeru...@aerusso.net
See Brian Behlendof's comment at [1], in the merge request for commit
3f81aba76, referencing the analysis of the bug report [2].
In summary: a kernel buffer
Package: chromium
Version: 89.0.4389.82-1
Severity: grave
Tags: upstream security
Justification: user security hole
X-Debbugs-Cc: aeru...@aerusso.net, Debian Security Team
Per [1] (or [2], and allegedly [3] which I cannot access):
> A use after free security issue was found in the Blink
control: tag -1 patch
On 2/5/21 3:22 AM, Gianfranco Costamagna wrote:
> control: reopen -1
> control: notfixed -1 3.0.9+dfsg1-1.1
>
> Hello, I reuse this bug, to point out that now the package has an autopkgtest
> failure on armhf, probably due to an incomplete patch or a missing xvfb
>
* hardware to test this on, so, while I can
confirm that this builds (and works) on amd64, it would be nice if someone
could check that it works correctly on arm.
Best,
Antonio Russo
[1] https://tracker.debian.org/pkg/xpra
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956822
The patch I submitted builds and runs fine on amd64. It should
also trivially get past the assertion failure in the referenced
buildd log.
I can prepare an NMU---but I'd feel better if someone with an
actual arm* machine could test it.
Also, maybe
-if not
) there's no need to upstream this change.
Author: Simon Ruderich
Author: Antonio Russo
Bug-Debian: https://bugs.debian.org/863891
Forwarded: not-needed
Last-Update: 2020-12-18
Index: xpra-2.4.3+dfsg1/setup.py
===
--- xpra-2.4.3+dfsg1.orig
Yes, and this is partly my fault. I've prepared a version of this
patch [1] and forwarding it to upstream [2]. [1] Also includes
some other fixes that should get in, but weren't worth delaying
the upload for. (But this certainly is!)
/sbin is the correct place for this, right?
Antonio
[1]
tag -1 upstream
thanks
Giving an update here, since many people may be interested in a status
report on this:
- There is *no released version* of ZoL/OpenZFS that supports 5.10.
- 5.10 appears to have been slightly more work for OpenZFS to adjust to.
- As of e1d9228b0 (on their 2.0.1-staging
Control: tag -1 patch
I have opened an MR on salsa [1] that addresses this by relaxing the version
constraints. I'd appreciate feedback if this is an appropriate way to solve
the problem.
Antonio
[1] https://salsa.debian.org/zfsonlinux-team/zfs/-/merge_requests/28
Control: tag -1 patch
I've created an MR on salsa that should address this
https://salsa.debian.org/ahs3/rasdaemon/-/merge_requests/2
Best,
Antonio
Control: severity -1 wishlist
Control: tag -1 -moreinfo
On 2020-07-03 09:49, Wxcafé wrote:
> My problem is that canmount=noauto datasets should not be mounted
> automatically (I mean it’s in the name, isn’t it?) and right now they are
> being mounted automatically (through systemd)
systemd
Can you confirm that
zfs set org.openzfs.systemd:ignore=on rpool/backups
resolves your issue? Right now, you've got backup datasets that are
canmount=noauto, but presumably
should never be mounted at those mountpoints. Other options are
- change your mountpoint on your backup root, and have
Control: tags -1 +moreinfo
Hello!
Is that attached file literally what is in /etc/zfs/zfs-list.cache ? How was
it generated, and how did it get there?
Because it's wrong---it's space separated, and must be tab separated. Use -H,
per man zfs-mount-generator, if it must be done by hand.
Control: tag -1 patch
I've opened a merge request [1] addressing this.
[1] https://salsa.debian.org/debian/dracut/-/merge_requests/1
Package: dracut
Version: 050+35-2
Severity: serious
This newest version of dracut is not loading Intel microcode updates, and
reverting to 048+80-2 resolves the issue.
lsinitrd in 048 shows an early cpio archive with the microcode. that cpio is
missing in 050, so maybe that is related?
I've
Sorry for the noise here. I understand that these are two separate issues, and
I believe
that upstream has addressed the libiptc -> libip4tc name change in their 5.10.0
release.
My MR has been updated to only pull in libip4tc-dev and libip6tc-dev, and not
libiptc-dev
in a third patch, so there
merged 946152 and 951088?) Or is the removal of the dependency on libiptc0 (by
rebuilding) sufficient to
address your original bug report?
Thanks,
Antonio Russo
[1] https://salsa.debian.org/debian/pkg-collectd/-/merge_requests/2
Control: forcemerge -1 946152
Control: tag -1 patch
Please see my MR on salsa [1]. With that patch, collectd builds locally
without the obsolete build-dep.
Antonio
[1] https://salsa.debian.org/debian/pkg-collectd/-/merge_requests/2
Package: zfs-zed
Version: 0.8.3-1
Severity: serious
Tags: patch
Justification: Policy 10.7.3
Please see my MR on salsa [1], which should address this policy violation. In
short: the symlinks shipped
by zfs-zed in /etc/zfs/zed.d are not tracked as conffiles by dpkg, so they
re-appear even after
please include your
NetworkManager.conf file? (Make sure there are no secrets in it!)
Best,
Antonio Russo
[1] https://www.debian.org/Bugs/server-control#found
verbose, and csv). They are identical.
Antonio
Description: Port simg_dump to Python 3.
Author: Antonio Russo
Forwarded: no
Last-Update: 2019-01-05
Index: android-platform-system-core/libsparse/simg_dump.py
===
--- android-platform
Control: severity -1 wishlist
A firmware upgrade on my X470 Taichi Ultimate to P3.4 (from P3.2)
resolved the UUID collisions (AMD Ryzen 3700X).
As terrifying as this was for me, the solution is to have hardware
that functions properly. I think there is merit in leaving this open
so that other
Control: retitle -1 KeePassXC does not warn about groups and entries with same
UUID
This may be a firmware issue:
https://github.com/keepassxreboot/keepassxc/issues/3569
However, there is still an underlying defect:
https://github.com/keepassxreboot/keepassxc/issues/3415
Package: keepassxc
Version: 2.4.3+dfsg.1-1
Severity: grave
--- Please enter the report below this line. ---
Steps to reproduce:
1. Create a new database
2. Create an entry and save it. Its UUID is
4fffbfff
3. Create another entry, notice it has the same UUID.
Bonus
On 9/29/19 2:30 PM, Alberto Berti wrote:
> Hi Antonio,
>
> thanks for answering.
No problem! :-)
>
>>>>>> "Antonio" == Antonio Russo writes:
>
> Antonio> Could you please clarify: did you experience any data loss,
> Antonio> or
Could you please clarify: did you experience any data loss, or were you simply
unable to import your pool at one point?
As a second note, you should have done something like
zpool import -d /dev/disks/by-id -a
so that your import is done by labels that are stable across boots (names like
I couldn't find a bug report on the zfsonlinux bug tracker, so I opened one for
this issue [1].
Thanks for looking into this,
Antonio
[1] https://github.com/zfsonlinux/zfs/issues/9346
Package: firefox
Version: 66.0.1-1
Severity: grave
Tags: security
--- Please enter the report below this line. ---
See [1]: "All extensions are disabled due to expiration of intermediate signing
cert"
This presumably affects all versions of Firefox, but I can only personally
confirm
my
Package: xpra
Version: 2.5+dfsg1-1
Severity: grave
--- Please enter the report below this line. ---
Thanks for packaging the new xpra release! It does not start, because
LOCAL_MODIFICATIONS in /usr/lib/python3/dist-packages/xpra/src_info.py
is a string, but
Package: xpra
Version: 2.4.3+dfsg1-1
Severity: serious
Tags: patch
--- Please enter the report below this line. ---
At least on my setup, detect_xorg_setup(install_dir) in setup.py already
produces
xvfb_command[0] == '/usr/lib/xorg/Xorg'
(around line 822 in setup.py).
The assertion
On 9/24/18 6:45 AM, Steven De Herdt wrote:
> Hello folks
>
> At the moment, this bug prevents a freshly installed buster with KDE as
> desktop to have its printers configured. If the message asking for
> authentication is clarified, would that be enough to at least lower the
> severity of this
Control: severity -1 wishlist
Control: retitle -1 Please add correct versioned dependencies
The bug originally presented on a machine that was running testing (and not
unstable).
I had used aptitude to pull a (presumably minimal) set of dependencies allowing
kwin-x11
from unstable to be
Package: kwin-x11
Version: 4:5.13.1-1
Severity: grave
--- Please enter the report below this line. ---
I am writing this on a machine that's been downgraded back to 5.12.5-1, where
kwin works fine.
kwin_x11 doesn't seem to have a verbose output option. I'll try to capture a
useful log,
but in
Package: print-manager
Version: 4:18.04.1-1
Severity: critical
Tags: security
X-Debbugs-CC: secure-testing-t...@lists.alioth.debian.org
--- Please enter the report below this line. ---
When on a (possibly untrusted) network with a cups server, opening the KDE
configuration panel,
and going to
Control: severity -1 wishlist
I think everyone can agree this is at most a wishlist bug.
I also agree that making Debian packaging easier for others in the greater
Debian ecosystem would be nice.
However, your point of contact for a build issue on another distribution should
be that
What is the output of
# lsb_release -is
?
Control: tag -1 patch
I've updated my MR [1] to add the Breaks/Conflicts to complete
the migration of the testing infrastructure. (The earlier
version should have already addressed the duplicate man page issue.)
Antonio
[1] https://salsa.debian.org/zfsonlinux-team/zfs/merge_requests/2
In the process of fixing another bug [1], I had no problem
building from source. Could you try to reproduce with the
patch I've included with that bug? It should change the svg
importer to not try to use rsvg (though, I don't understand
why it would try and fail).
Does /convert ultimately point
Control: severity 889795 serious
Control: merge 889795 891026
I've raised the severity of the existing bug given the presence of Linux 4.15
in the repository.
Both spl and zfs packages are pulled into, and merged with, the existing
Debian packaging in
Control: reassign -1 spl-linux 0.7.4-1
The bug affects building spl.
Also for anyone trying to build this, you can build objtool in the
tools/objtool directory of the linux source (apt source linux). Then
copy it to
/usr/src/linux-headers-4.14.0-3-amd64/tools/objtool/objtool
Package: src:zfs-linux
Version: 0.7.4-1
Severity: grave
--- Please enter the report below this line. ---
Building spl with linux 4.14.0-3 fails, due to a missing dependency on
libelf-dev.
(installing the package allows the build to proceed).
Additionally, objtool is missing from the kernel
The body of the last email interchanged > and < signs. The attached patch
does not have that mistake, but a double check of my understanding of the
Debian version comparison algorithm [1] might still be a good idea.
[1] http://www.fifi.org/doc/debian-policy/policy.html/ch-versions.html
pares less than the '.',
rather than requiring
the exact version ${source:Upstream-Version}, which will never be in the
archives.
commit cfb50102c8864ba59a67a25e772efe8d0c73e996
Author: Antonio Russo <antonio.e.ru...@gmail.com>
Date: Sun Nov 19 17:03:47 2017 -0500
Add maximum version dependency on
The package should also
Recommends: gir1.2-appindicator3-0.1
so that by default people can get a tray icon.
Sorry, there is no 0.6.5.8 release. The fix does exist in the master branch,
however.
(bc77ba7: OpenZFS 6513 - partially filled holes lose birth time)
Package: zfs-dkms
Version: 0.6.5.7-1
Severity: grave
--- Please enter the report below this line. ---
See ZoL bug report.
https://github.com/zfsonlinux/zfs/issues/4809
aka Illumos 6513
Short summary: Pools with hole_birth feature enabled are susceptible to
irreversible damage interfering
Package: libwine-unstable:i386
Version: 1.7.14-4
Severity: grave
--- Please enter the report below this line. ---
I just upgraded from 1.7.14-2, installed libgstreamer1.0-0-plugins-base1.0-0,
(which _should_ be in the depends, right?) and now I get the error in the title
whenever calling the wine
52 matches
Mail list logo