Package: linux-perf
X-Debbugs-Cc: io...@ionic.de
Version: 6.11.10-1
Severity: minor
Hi
perf can't load its tip.txt file because it's installed in a compressed
state.
While unfortunately it looks for the file in $docdir/linux-perf and
documentation is mostly compressed, an exception should be m
* On 12/15/22 18:42, Sven Joachim wrote:
> It seems you are slightly mistaken here, as the same problem had been
> reported for 2:1.20.4-1+deb10u3 already. It has been fixed post-buster
> in 2:1.20.6-1.
Oh, sorry, that bug report didn't show up for me. I did search for bug reports
against xorg-ser
[Resent to the bug tracker as well]
* On 12/15/22 19:15, Emilio Pozuelo Monfort wrote:
> I'm not sure I understand what the problem is. The patches are in
> debian/patches/ and are applied during build using quilt.
Thank you for looking into it.
> From the amd64's build log [1]:
It won't sho
Package: xorg-server-source
Version: 2:1.20.4-1+deb10u6
Severity: normal
Hi
It looks like the content of debian/patches/ has not been applied when packaging
xorg-server-source.
This at least one patch contains a FTBFS fix, it's impossible to build
xorg-server out of the box.
This is a regressi
* On 2/12/22 8:51 PM, Enrico Zini wrote:
> On Sat, Feb 12, 2022 at 06:51:26PM +0100, Mihai Moldovan wrote:
> That's even better, then: it becomes a matter of documenting the
> procedure to bootstrap an rpm-based distro from Debian: I can test it
> and produce a draft HOWTO.
In th
* On 2/11/22 1:57 PM, Holger Levsen wrote:
> On Fri, Feb 11, 2022 at 01:33:08PM +0100, Enrico Zini wrote:
>>> However I've downgraded it to important as eg Qubes 4.1 uses dnf on Debian
>>> to
>>> download upgrades for dom0, which is Fedora based. So the package is
>>> certainly
>>> not unusable f
* On 2/2/22 6:05 PM, Enrico Zini wrote:
> I'm trying to use dnf to bootstrap rpm-based chroots, which seems to
> work, but the rpm package database on the resulting distribution is
> empty, as in, `rpm -qa` returns no output, and `rpm -q` on any package
> complains that it is not installed. The act
* On 5/21/21 7:32 PM, Frédéric Pierret wrote:
> I'll try to fix that quickly, thank you.
Yep, just a matter of adding libjs-jquery and libjs-underscore to Depends on
python3-hawkey-doc. I've done that on my weird, stretch-based setup with the
initial dnf 4.0.9 version.
> BTW, Mihai may I change
* On 5/19/21 1:46 PM, Andreas Beckmann wrote:
> Package: python3-hawkey-doc
> Version: 0.55.2-6
> [...]
> during a test with piuparts I noticed your package ships (or creates)
> a broken symlink.
> [...]
> Is python3-hawkey-doc missing a Depends/Recommends/Suggests: libjs-jquery,
> libjs-underscor
Control: close -1
Turns out I'm just stupid.
This escape sequence is only allowed in tandem with the "%b" format specifier.
Otherwise, only the '\ddd' syntax is supported.
dash is behaving correctly:
# /bin/dash -c 'printf '"'"'%b\n'"'"' '"'"'\0056'"'"
.
Closing up here, sorry for the noise.
Package: dash
Version: 0.5.11+git20210120+802ebd4-1
Quoting from
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/printf.html :
"[...] The following -escape sequences shall be supported:
[...] o "\0ddd", where ddd is a zero, one, two, or three-digit octal number
that shall be
* On 3/22/21 9:40 AM, Bastian Blank wrote:
> Control: tags -1 moreinfo
>
> On Mon, Mar 22, 2021 at 08:40:34AM +0100, Mihai Moldovan wrote:
>> Currently, mounting an EXT4-formatted volume with the case-insensitivity
>> feature
>> is impossible since CONFIG_UNICODE i
e the missing feature isn't just
convenience, but actually has negative implications when mounting file systems.
If that is any argument, Ubuntu 21.04 enables the feature, too.
My best guess is that the chance of regressions is very low.
Best regards
Mihai Moldovan
OpenPGP_signature
D
Package: debhelper
Version: 12.10
dh_install* takes a --sourcedir parameter which can be leveraged to pick data
from a specific destroot, which is very handy when building a package multiple
times with different features and creating conflicting binary packages.
Short example (pseudo-Makefile-co
* On 1/31/20 8:57 PM, Neal Gompa wrote:
> As for yum and yum-utils, their replacements are dnf and
> dnf-plugins-core (which have subpackages yum and yum-utils
> respectively to act as legacy interfaces).
>
> My understanding is that Mihai Moldovan was working on this for Debian
my other work).
These patches merely introduce support for new three new tags and should be very
safe to apply.
When applying the debdiff, please remove the NMU entry, which is only there to
make lintian (more or less) happy!
Best regards,
Mihai Moldovan
diffstat for rpm-4.14.2.1+dfsg1 rpm
* On 9/6/19 4:43 AM, Mihai Moldovan wrote:
> Rebased everything and bumped up to 0.6.36, which also fixes the 3 CVE's
> attached to this package. Will upload a new debdiff soon, need to build these
> packages for sid and test them for a bit, including the updated dnf stuff.
> S
> With the greatest embarrased... may I ask you to rebase your .debdiff?
Rebased everything and bumped up to 0.6.36, which also fixes the 3 CVE's
attached to this package. Will upload a new debdiff soon, need to build these
packages for sid and test them for a bit, including the updated dnf stuff.
Hi Michal
I don't want to be condescending, but can we please, pretty-please stop breaking
rpm in Debian?
I understand that rpm is not intended to be used as a package manager on Debian
systems, but the rpmdb-in-homedir patch does more harm than good, causing
trouble in totally legitimate use ca
* On 6/18/19 3:22 PM, Bastian Blank wrote:
> See #847154 for the workaround.
Thanks. Seems to work fine.
This triggered another question, though: can I assume that buster kernels are
also affected by that problem by default? Given that the shipped user space is
new enough, I figure that option wil
Package: linux-image-amd64
Version: 4.19.37-3~bpo9+1
Steps to reproduce:
1.) apt-get install mock
2.) [0] /usr/bin/mock -r /etc/mock/epel-6-x86_64.cfg --init
3.) chroot /var/lib/mock/epel-6-x86_64/root/
=> Segmentation fault
=> [53880.200376] bash[25554] vsyscall attempted with vsyscall=none
ip:f
Package: firefox-esr
Version: 60.3.0esr-1~deb9u1
Severity: important
This is essentially a downstream bug report of bz#1477176 (
https://bugzilla.mozilla.org/show_bug.cgi?id=1477176 ).
firefox-esr currently segfaults right on startup on ppc64le during the first
memory allocation call.
I cannot
related to libsolvext0.
+ * debian/libsolvext0.symbols:
++ Update.
+ * debian/control:
++ Add BD: dh-python.
+
+ -- Mihai Moldovan Fri, 02 Feb 2018 14:33:28 +0100
+
libsolv (0.6.30-1) unstable; urgency=medium
[ Héctor Orón MartÃnez ]
diff -Nru libsolv-0.6.30/debian/control libsolv-0.6
On 10/24/2017 06:40 PM, Niels Thykier wrote:
> I have attached a patch that I hope you can test to see if it fixes your
> problem.
I've rebuilt the debhelper package in sid with the patch applied and inserted it
forcefully into an sbuild build environment.
Seems to work, the dbgsym packages now a
FWIW, this might be a consequence of running dh_gencontrol in parallel mode.
I'm not really able to explain what is going on, though, since only the
autogenerated dbgsym packages seem to be affected. The only way this could
happen is if package_section($package) is returning something invalid (lik
Package: debhelper
Version: 10.10.3
While building packages for Debian sid, I noticed that dbgsym packages for
non-main components got uploaded to the main component in my reprepro-managed
repository.
reprepro isn't at fault, since a build with sbuild reveals this in the dbgsym
packages generated
Package: qemu-user-static
Version: 1:2.8+dfsg-6+deb9u2
Steps to reproduce:
qemu-debootstrap --arch=armhf --variant=minbase --verbose --components=main
--resolve-deps stretch /tmp/stretch-armhf
chroot /tmp/stretch-armhf/ apt-get install -y aptitude
chroot /tmp/stretch-armhf/ aptitude update
=> Se
Open points (also RFC!):
- db/ix/full.html
o list of all non-archived bugs
o no alternative (needs implementation)
- db/ix/maintainers.html
o list of maintainers (broken, does not consider Maintainers.override)
o RewriteRule ^/db/ix/maintainers\.html /cgi-bin/pkgindex.cgi?index
FWIW, changing the BD of libssh to "libssl1.0-dev |
libssl-dev (< 1.1)" would probably also be a good idea.
I have tested these changes in the X2Go repository and with my suggested changes
the conflict is finally gone.
Mihai
signature.asc
Description: OpenPGP digital signature
Package: libssh-4
Version: 0.7.3-1
Source: libssh
On Debian Unstable, libssh-4 is built against and (automatically) depends upon
libssl1.0.2 - the corresponding dev-package for libssl1.0.2 is libssl1.0-dev.
Its corresponding dev-package libbsh-dev hard-depends upon libssl-dev (which is
OpenSSL 1.
27;/etc/mail//etc/spf-milter-python/spfmilter.cfg'])
Should really be:
config =
read_config(['spfmilter.cfg','/etc/mail/spfmilter.cfg','/etc/spf-milter-python/spfmilter.cfg'])
When packaging the new version, please take care of correctly adding the
Debian config fi
31 matches
Mail list logo
