Thanks for reporting this...
I have a patch[1] pending in the 'dev' branch that I can merge now that
the transition is over. I'll try to upload a new version in the coming
days.
[1]
https://salsa.debian.org/debian/libcdio/-/commit/e9d3d7b5a5e5efa1c2c0cbe1ed5d63a2e63f02e1
Emilio,
My recommendation is that we indeed stop this transition and resume
once trixie is released.
I have a few updates below:
* Gabriel F. T. Gomes:
>
> the problem does not seem to be related to libdevice-cdio-perl, but a
> problem with libcdio itself.
I was able to remove libde
* Emilio Pozuelo Monfort:
>
> Can't we fix this by using breaks, as I suggested? That'd be way simpler than
> reverting the transition.
Yes, we can.
It would be a breaks between libcdio sub-packages, though, e.g.:
libcdio19 (>= 2.2.0) breaks libiso9660 (< 2.2.0)
since the mixing of these tw
Thanks for reporting this...
I have a patch[1] pending in the 'dev' branch that I can merge now that
the transition is over. I'll try to upload a new version in the coming
days.
[1]
https://salsa.debian.org/debian/libcdio/-/commit/e9d3d7b5a5e5efa1c2c0cbe1ed5d63a2e63f02e1
I thought about it a little bit more and I prefer adding breaks against
the old version of libiso9660, instead of libdevice-cdio-perl. I think
it makes more sense, because even though libdevice-cdio-perl is the
only package, in Debian, that is affected by the issue, other software
(that are not Deb
I thought about it a little bit more and I prefer adding breaks against
the old version of libiso9660, instead of libdevice-cdio-perl. I think
it makes more sense, because even though libdevice-cdio-perl is the
only package, in Debian, that is affected by the issue, other software
(that are not Deb
Dear Libcdio developers,
I need your help with the recent ABI changes in libiso9660.
The 2.2.0 release contains the ABI bump for libiso9660 due to the
addition of new fields/members in a few structs. I understand that
previous versions (also recently released) did not have the bump which
was rect
* Gabriel F. T. Gomes:
>
> libcdio19 (>= 2.2.0) breaks libiso9660 (< 2.2.0)
On second thought... This will make it impossible to have both
libiso9660 versions (libiso9660-12 and libiso9660-11t64) at the same
time.
We could have a breaks against libdevice-cdio-perl as you suggest
* Gabriel F. T. Gomes:
>
> libcdio19 (>= 2.2.0) breaks libiso9660 (< 2.2.0)
On second thought... This will make it impossible to have both
libiso9660 versions (libiso9660-12 and libiso9660-11t64) at the same
time.
We could have a breaks against libdevice-cdio-perl as you suggest
* Emilio Pozuelo Monfort:
>
> Can't we fix this by using breaks, as I suggested? That'd be way simpler than
> reverting the transition.
Yes, we can.
It would be a breaks between libcdio sub-packages, though, e.g.:
libcdio19 (>= 2.2.0) breaks libiso9660 (< 2.2.0)
since the mixing of these tw
Emilio,
My recommendation is that we indeed stop this transition and resume
once trixie is released.
I have a few updates below:
* Gabriel F. T. Gomes:
>
> the problem does not seem to be related to libdevice-cdio-perl, but a
> problem with libcdio itself.
I was able to remove libde
I like the fact that autopkgtests are detecting this issue. The older
libiso9660 should work with the newer libcdio, because libcdio did not
break its ABI. I was thinking of investigating this further (e.g. with
a minimal reproducer, if I can make one) and even involve upstream if
something is inde
I like the fact that autopkgtests are detecting this issue. The older
libiso9660 should work with the newer libcdio, because libcdio did not
break its ABI. I was thinking of investigating this further (e.g. with
a minimal reproducer, if I can make one) and even involve upstream if
something is inde
* Gabriel F. T. Gomes:
>
> Alternatively, we could make libiso9660 (and libiso9660++) explicitly
> depend on the newer version of libcdio.
This did not help the test. :/
libdevice-cdio-perl in testing (i.e.: libdevice-cdio-perl i386
2.0.0-2+b4) owns /usr/lib/i386-linux-gnu/p
* Gabriel F. T. Gomes:
>
> Alternatively, we could make libiso9660 (and libiso9660++) explicitly
> depend on the newer version of libcdio.
This did not help the test. :/
libdevice-cdio-perl in testing (i.e.: libdevice-cdio-perl i386
2.0.0-2+b4) owns /usr/lib/i386-linux-gnu/p
* Emilio Pozuelo Monfort:
>
> I assume at this point that means bumping the shlibs to get proper
> dependencies.
That was my initial idea, too, but I have given additional thought to
this and I think that this is not the right thing to do. Just to make
sure we are all discussing the same thing, th
* Emilio Pozuelo Monfort:
>
> I assume at this point that means bumping the shlibs to get proper
> dependencies.
That was my initial idea, too, but I have given additional thought to
this and I think that this is not the right thing to do. Just to make
sure we are all discussing the same thing, th
* Gabriel F. T. Gomes:
>
> This is probably due to the fact that libiso9660 is built from the same
> source as libcdio; thus, when libiso9660 is built, it is linked against
> the version of libcdio installed on the build system, which is version
> 2.1.0-5.
This is wrong. libcdio
* Gabriel F. T. Gomes:
>
> This is probably due to the fact that libiso9660 is built from the same
> source as libcdio; thus, when libiso9660 is built, it is linked against
> the version of libcdio installed on the build system, which is version
> 2.1.0-5.
This is wrong. libcdio
* gregor herrmann:
>
> % apt-cache --no-all-versions show libiso9660-12
> Package: libiso9660-12
>
> Source: libcdio
> Version: 2.2.0-1
> Installed-Size: 76
> Maintainer: Gabriel F. T. Gome
* gregor herrmann:
>
> % apt-cache --no-all-versions show libiso9660-12
> Package: libiso9660-12
>
> Source: libcdio
> Version: 2.2.0-1
> Installed-Size: 76
> Maintainer: Gabriel F. T. Gome
* Gabriel F. T. Gomes:
>
> I said this before, but I found this hacky way of doing it to pin-point
> (somewhat) the source of the test failures.
With this hacky setup, where libcdio.so.19 is from version 2.1.0-5, the
segmentation fault is caused by the ABI change, as can be seen in the
* Gabriel F. T. Gomes:
>
> I said this before, but I found this hacky way of doing it to pin-point
> (somewhat) the source of the test failures.
With this hacky setup, where libcdio.so.19 is from version 2.1.0-5, the
segmentation fault is caused by the ABI change, as can be seen in the
u/libcdio.so.19.0.0
Re-run `autopkgtest -B . -- null' and check that it now fails!
Finally, installing a freshly built version of libdevice-cdio-perl (one
that is linked against the new version of libcdio (2.2.0-1)), makes the
test pass again.
* Gabriel F. T. Gomes:
> I think it is imposs
u/libcdio.so.19.0.0
Re-run `autopkgtest -B . -- null' and check that it now fails!
Finally, installing a freshly built version of libdevice-cdio-perl (one
that is linked against the new version of libcdio (2.2.0-1)), makes the
test pass again.
* Gabriel F. T. Gomes:
> I think it is imposs
* Emilio Pozuelo Monfort:
>
> Did you run it against testing packages, except for libcdio from unstable?
If I install libdevice-cdio-perl from testing, it will automatically
install libcdio from testing, as well, because of the dependency on the
old SONAME.
$ apt depends libdevice-cdio-perl
<...>
* Emilio Pozuelo Monfort:
>
> Did you run it against testing packages, except for libcdio from unstable?
If I install libdevice-cdio-perl from testing, it will automatically
install libcdio from testing, as well, because of the dependency on the
old SONAME.
$ apt depends libdevice-cdio-perl
<...>
I'm seeing autopkgtest failures for libdevice-cdio-perl in the tracker
for libcdio (excuses panel):
https://tracker.debian.org/pkg/libcdio
The failures are in 32-bits architectures, e.g., for i386:
https://ci.debian.net/packages/libd/libdevice-cdio-perl/testing/i386/58673931/
Since it's so
I'm seeing autopkgtest failures for libdevice-cdio-perl in the tracker
for libcdio (excuses panel):
https://tracker.debian.org/pkg/libcdio
The failures are in 32-bits architectures, e.g., for i386:
https://ci.debian.net/packages/libd/libdevice-cdio-perl/testing/i386/58673931/
Since it's so
17.
In my opinion, my concerns about this transition for libdevice-cdio-perl were
too conservative, and the transition should be allowed.
Cheers.
Gabriel
From: Emilio Pozuelo Monfort on behalf of Emilio Pozuelo
Monfort
Sent: 05 March 2025 00:31
To: Gabriel F
17.
In my opinion, my concerns about this transition for libdevice-cdio-perl were
too conservative, and the transition should be allowed.
Cheers.
Gabriel
From: Emilio Pozuelo Monfort on behalf of Emilio Pozuelo
Monfort
Sent: 05 March 2025 00:31
To: Gabriel F
I sent a new message to the perl team, now to the right mailing list:
https://lists.debian.org/debian-perl/2025/02/msg6.html
I sent a new message to the perl team, now to the right mailing list:
https://lists.debian.org/debian-perl/2025/02/msg6.html
I just submitted a merge request[1] against the packaging repository.
If the maintainers can either use it, or write a different fix, that
would be preferred in my opinion. Otherwise, I'll upload the fix to the
archive as a NMU.
Cheers,
Gabriel
[1] https://salsa.debian.org/multimedia-team/glyr/-/
I just submitted a merge request[1] against the packaging repository.
If the maintainers can either use it, or write a different fix, that
would be preferred in my opinion. Otherwise, I'll upload the fix to the
archive as a NMU.
Cheers,
Gabriel
[1] https://salsa.debian.org/multimedia-team/glyr/-/
I just submitted a merge request[1] against the packaging repository.
If the maintainers can either use it, or write a different fix, that
would be preferred in my opinion. Otherwise, I'll upload the fix to the
archive as a NMU.
Cheers,
Gabriel
[1] https://salsa.debian.org/multimedia-team/glyr/-/
* Gabriel F. T. Gomes:
> That I did and the tests pass. However, since I'm not sure that the
> tests test the changed ABI, let's wait for the Perl Team opinion.
Though we can still wait for the Perl Team's opinion, I recently
learned more about SWIG and taking care of thes
* Gabriel F. T. Gomes:
> That I did and the tests pass. However, since I'm not sure that the
> tests test the changed ABI, let's wait for the Perl Team opinion.
Though we can still wait for the Perl Team's opinion, I recently
learned more about SWIG and taking care of thes
* Emilio Pozuelo Monfort:
>
> Have you contacted them?
I hadn't, but I did now
https://alioth-lists.debian.net/pipermail/pkg-perl-maintainers/2025-January/180083.html
> Maybe you can run libdevice-cdio-perl's autopkgtest after it is
> rebuilt?
That I did and the tests pass. However, since I'm n
* Emilio Pozuelo Monfort:
>
> Have you contacted them?
I hadn't, but I did now
https://alioth-lists.debian.net/pipermail/pkg-perl-maintainers/2025-January/180083.html
> Maybe you can run libdevice-cdio-perl's autopkgtest after it is
> rebuilt?
That I did and the tests pass. However, since I'm n
Package: release.debian.org
Severity: normal
X-Debbugs-Cc: libc...@packages.debian.org, gabr...@inconstante.net.br,
gabr...@debian.org
Control: affects -1 + src:libcdio
User: release.debian@packages.debian.org
Usertags: transition
Dear Debian Release Team,
I would like to have a transition f
Package: release.debian.org
Severity: normal
X-Debbugs-Cc: libc...@packages.debian.org, gabr...@inconstante.net.br,
gabr...@debian.org
Control: affects -1 + src:libcdio
User: release.debian@packages.debian.org
Usertags: transition
Dear Debian Release Team,
I would like to have a transition f
Control: fixed -1 2.2.0-1~exp1
Control: stop
The [upstream] commit[1]:
commit 81739d8653988a5cc59fd0ac79ed57f3a4232995
Author: R. Bernstein
* Gabriel F. T. Gomes wrote:
> Though I can certainly do it. If Debian's libsecret maintainers are
> fine with waiting for a new release of bash-completion, then I'll
> wait, as well, and avoid the backport.
Sorry for the weird punctuation. What I meant is that I can ba
* Jeremy Bícha wrote:
> I suggest doing the bash-completion backport and then we can follow
> with a libsecret upload to include the bash-completion file (with
> appropriate Breaks/Replaces) and then we don't have to think about
> this issue later.
Yeah, not thinking about it in the future makes
Upstream bash-completion has a patch to deprecate the completion for
libsecret in their master branch[1]. This has not been release, yet, so
it's not on Debian's package.
Likewise, upstream libsecret incorporate the completion file from
upstream bash-completion, since the latter was ruled better[2
Control: tags + upstream
https://github.com/scop/bash-completion/issues/316
tags -1 + wontfix
close -1
stop
While I understand the preference, hostnames defined in Hostname lines
could be reachable.
Initial packaging files on salsa at https://salsa.debian.org/debian/libpulp
I'm still thinking whether this should go into experimental first. I'm inclined
to push directly to unstable.
Initial packaging files on salsa at https://salsa.debian.org/debian/libpulp
I'm still thinking whether this should go into experimental first. I'm inclined
to push directly to unstable.
* Lionel Elie Mamane:
> bug might be in bash itself, not in bash-completion, I'm not sure.
Looks like it is, because it is reproducible with bash-completion uninstalled.
> meaning the '$' gets retroactively escaped and all goes correctly. But
> really at the end of "STEP 2", the final '$' should
Package: wnpp
Severity: wishlist
Libpulp is composed of two parts:
1. a library (libpulp.so) that enables live-patching of user-space processes,
provided that to-be-patched binaries and libraries have been prepared/compiled
with live-patching in mind, and that the process has been started with
Hi, Ivan and Alban,
Thank you very much for your reports. They certainly help me debug this large
update.
I see two different issues:
1. Missing _comp_deprecate* functions
Bash-completion 2.12 adds a new file to /etc/bash_completion.d
(/etc/bash_completion.d/000_bash_completion_compat.bash), a
Upstream does not want this change
(https://github.com/scop/bash-completion/issues/442).
* Philipp Marek wrote:
> This sequence runs chromium and blocks the shell until the browser is closed
> again:
>
> $ chromium --
That doesn't happen on my system, either with or without chromium installed.
The completion file runs 'chromium --help' and that exits quickly. What happens
for
Hi again,
One of the project maintainers said [1] that the plan for a release is
still up. I'll try to help them with whatever spare time I can find.
Not sure if you are interested in doing that as well, but I wanted to
make a point that bash-completion is a very friendly community and
welcomes ev
Hi, Richy,
Erring on the side of caution, I just posted a comment [1] to the upstream
project, asking if the plan to release 2.12 is still alive. If they say yes,
then we might give them a hand with the remaining tasks to speed it up.
Otherwise, I'll plan some debian-only update in the lines of
Control: reassign -1 libreoffice
Hi, I believe the libreoffice package produces its own completion files
(which is awesome), thus reassigning.
A patch for this would probably look like:
--- bin/generate-bash-completion.py 2023-06-19 18:32:31.988021669 -0700
+++ bin/generate-bash-completion.p
On Wed, 19 Apr 2023 22:45:21 +0300
Askar Safin wrote:
>
> (But I still think we should just make /etc/skel/.bashrc to be default
> /root/.bashrc . This will fix other possible "user vs root" bugs.
> Currently /root/.bashrc doesn't have any non-comment lines, i. e. it
> doesn't contain anything use
On Wed, 19 Apr 2023 17:10:06 +0300
Askar Safin wrote:
> If I copy /etc/skel/.bashrc to /root/.bashrc , the bug disappears.
That's because /etc/skel/.bashrc directly source /etc/bash_completion.
With login shells, /etc/bash_completion gets sourced by something else.
I think we need to dig deeper
Control: tags -1 confirmed
Steps to reproduce
$ su -# become root
# echo $0
-bash # this is a login shell
# apt-get inst
(completes)
# su root
# echo $0
bash # this is a non-login shell
# apt-get inst
(nothing happens)
I don't currently know what sources /etc
Thanks, Sergio.
You're the best archaeologist! S2
On Mon, 10 Apr 2023 13:55:27 -0400
Sergio Durigan Junior wrote:
> On Monday, April 10 2023, Gabriel F. T. Gomes wrote:
>
> > When I took the maintainer role for bash-completion, I did a lot of bug
> > archaeology, but
On Mon, 10 Apr 2023 14:04:06 +0200
"Richard B. Kreckel" wrote:
>
> Regarding my hangs: It is because something's broken in my NIS
> (yellow-pages) setup (haven't fully analyzed yet). It turns out that,
> when doing tab completion, your patch 00-fix_quote_readline_by_ref.patch
> tries to match a
Thanks, Matthias,
I submitted a patch upstream to get the feedback from the upstream [1]
developers. I hope they accept it; if they do, it's easier for me to
backport. Cheers, Gabriel.
[1] https://github.com/scop/bash-completion/pull/922
On Wed, 29 Mar 2023 11:40:09 +0200
Matthias Geerdsen wrot
Hi Richard,
thanks for your report.
With respect to the package being outdated, I realize that the sources
have not been sync'd with upstream for a long while, but that's because
upstream has not released any versions (no tags) since 2.11; and I
always wait for upstream releases before syncing. F
wrote:
On Tue, 4 Feb 2020 23:10:06 -0300 "Gabriel F. T. Gomes" wrote:
I maintain pragha, which depends on this package, so I'll adopt it.
It is now 1.5 years since you filed the ITA. There is a new upstream version
that is unpackaged. Do you still want to take over maintainership?
wrote:
On Tue, 4 Feb 2020 23:10:06 -0300 "Gabriel F. T. Gomes" wrote:
I maintain pragha, which depends on this package, so I'll adopt it.
It is now 1.5 years since you filed the ITA. There is a new upstream version
that is unpackaged. Do you still want to take over maintainership?
gftg added a comment.
This patch as-is doesn't build. To build it needs another change that I know is
wrong, so I'm posting it below to ask for your help:
[RFC] How to add more bits to the Type class?
After reading https://reviews.llvm.org/D50630, I learned that keeping
the
gftg created this revision.
gftg added reviewers: xiangzhangllvm, pengfei, erichkeane, joaomoreira.
Herald added subscribers: ormris, dexonsmith, dang, jdoerfert, steven_wu,
martong, hiraditya.
Herald added a reviewer: aaron.ballman.
gftg requested review of this revision.
Herald added projects: c
Hi, Rocky,
On Tue, 2 Nov 2021 13:11:07 -0400
Rocky Bernstein wrote:
>
> Hmm - as best as I can tell this patches things a little differently than
> what was done in the git codebase.
That was not my intention.
Actually, I don't understand why you say that.
The patch that I backported to Debian
Hi, Rocky,
On Tue, 2 Nov 2021 13:11:07 -0400
Rocky Bernstein wrote:
>
> Hmm - as best as I can tell this patches things a little differently than
> what was done in the git codebase.
That was not my intention.
Actually, I don't understand why you say that.
The patch that I backported to Debian
Hi, Rocky, Lucas,
Thanks for doing all the hard work of reporting and fixing the bug.
I have just uploaded a new version o libcdio with the fix.
Cheers,
Gabriel
Hi, Rocky, Lucas,
Thanks for doing all the hard work of reporting and fixing the bug.
I have just uploaded a new version o libcdio with the fix.
Cheers,
Gabriel
On Mon, 04 Oct 2021 04:28:27 +0800
積丹尼 Dan Jacobson wrote:
>
> perltidy debian
> perltidy upstream
> bash-completion debian
> bash-completion upstream
Yeah, I know it's sometimes hard to tell where to submit bug reports
to. On the other hand, it looks like you are doing a good job of it.
Reporti
On Mon, 04 Oct 2021 09:01:55 +0200
Philipp Marek wrote:
>
> Perhaps I can find out what went wrong...
> do you have any ideas? readline settings,
> some shell function interfering (wrong completion load order?), ...??
I don't. There are too many variables. :/
> Next time that happens, I'll dump
Control: tags -1 + unreproducible
Hi,
I could not reproduce this bug, even though I tried every version all
the way down to 1:2.10-2. Here's what I get:
$ apt-get u
$ apt-get up
update upgrade
$ apt-get a
$ apt-get auto
autoclean autoremove
If you have more information, I'd
Hi,
thanks for reporting...
A fix is on its way to the Debian Archive and already in VCS [1].
Cheers,
Gabriel
[1]
https://salsa.debian.org/debian/bash-completion/-/commit/65534d18c5b0c5bf496af7a921ada56aa2a4375c
Control: forwarded -1 https://github.com/scop/bash-completion/issues/518
Control: tags -1 confirmed upstream fixed-upstream
Hello,
Hey, you could have mentioned that you submitted the bug upstream! :)
For future reference, here is is:
https://github.com/scop/bash-completion/issues/518
There
Control: tags -1 + fixed-upstream
Koichi Murase kindly pointed out that this has already been fixed upstream:
https://github.com/scop/bash-completion/issues/590#issuecomment-906045204
This patch has not been integrated into a release, yet:
$ git describe --tags 79a504a
2.11-81-g79a504a4
Control: tags -1 + confirmed upstream
The change in behavior is caused by the following upstream commit:
https://github.com/scop/bash-completion/commit/d1756f06ef9bffb1b4621c4e63e47e181ddf1086
which got released in upstream version 2.10.
Bug reported submitted upstream as
https://github.com
Thanks for the update.
I'll close the bug report now. Feel free to reopen it if anything else pops-up.
On Mon, 23 Aug 2021 19:36:34 -0300
"Gabriel F. T. Gomes" wrote:
>
> I will create a chroot with old-stable (buster) to check if older
> versions of bash-completion have this problem.
Indeed, now I was able to reproduce it.
And yes, using _have instead of have does fix the
Hello Jürgen,
thanks for following up on this bug.
On Mon, 23 Aug 2021 13:11:28 +0200
Jürgen Kuri wrote:
>
> If have() is used AND bash-completion script is stored into directory
>
> /usr/share/bash-completion/completions
I'm still trying to reproduce the problem, so...
I copied the fil
Hello again, Pelle,
I just tested it under sway and the column selection pop up showed up
normally. Perhaps I'm using Sway the wrong way?
I simply installed it with apt install sway; logged in from lightdm,
learned how to open a terminal, and launched pragha from it. Then, when
I right click on t
Hi, Pelle,
On Tue, 13 Apr 2021 11:00:15 +0200
Pelle wrote:
>
> When I right-click on a column header, no list appears, when running
> Pragha in Sway (a Wayland compositor). However, that list appears when
> Pragha is run in Weston (another Wayland compositor).
>
> I had only been running Prag
Hello, Pelle,
On Tue, 13 Apr 2021 00:12:40 +0200
Pelle wrote:
>
> It appears there is no way to sort an album (or several albums in a playlist)
> by track order. The available column headers for sorting are 'Title',
> 'Artist',
> 'Album' and 'Length'.
These are the default columns, indeed.
> W
Hi, Kevin,
On Mon, 15 Mar 2021 07:07:36 -0600
Kevin Locke wrote:
>
> I've attached an updated version
> which matches & and | in addition to ; as command separators. We may
> also want to consider modifying the compgen expression in the same way.
I added this patch (with a changelog entry) to t
On Mon, 15 Mar 2021, Kevin Locke wrote:
>
> Which appears to be a common idiom for only defining the function and
> completion if the command is in $PATH. I've attached an updated version
> which matches & and | in addition to ; as command separators. We may
> also want to consider modifying the
On Mon, 15 Mar 2021, Gabriel F. T. Gomes wrote:
>
> I'll check if it works correctly with the scripts currently installed
> under my /usr/share/bash-completion.
Perhaps we could also add && and || as command termination characters,
so that idioms like the following also get
Hi, Kevin,
On Sat, 13 Mar 2021, Kevin Locke wrote:
>
> I've attached a patch to fix the issue by requiring complete to follow a
> line break or semicolon. It obviously does not address the root of the
> problem of reliably differentiating a list of paths from a Bash script.
> (Which is not reall
On Thu, 04 Feb 2021, Daniel Kahn Gillmor wrote:
>
> (as i was writing this report, i realized that it's probably mainly an
> upstream bug, so i filed it at the URL above, but i figure it's worth
> tracking in the BTS as well since it affects other packages)
Thanks, and I agree. :)
Hi, William,
Thanks for your report.
On Fri, 04 Sep 2020, William Herrin wrote:
> set -u
> cd /
> cd ho[tab]
> bash: !ref: unbound variable
This is a known bug, which has been recently fixed upstream, and in
debian unstable/testing (see https://bugs.debian.org/741273#27).
> -- System Informati
Hi, Andreas,
I need help to reproduce this bug.
On 15 May 2020, Andreas Beckmann wrote:
>with dh_missing defaulting to --fail-missing in compat level 13,
>dh_bash-completion needs to log the files it has installed s.t.
>dh_missing does not wrongly report
> dh_missing: error: missing files, abor
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: gabr...@debian.org, sergi...@debian.org, vasek.ge...@gmail.com
Severity: normal
Hi,
libcdio needs a transition (upstream bumped the SONAME without ABI break).
I built all the packages repo
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: gabr...@debian.org, sergi...@debian.org, vasek.ge...@gmail.com
Severity: normal
Hi,
libcdio needs a transition (upstream bumped the SONAME without ABI break).
I built all the packages repo
On Fri, 31 Jul 2020, Sergio Durigan Junior wrote:
>
> Yeah, the list is large, indeed. I guess we'll find out whether this
> breaks something or not when it reaches unstable and starts to be used
> :-).
And if it breaks *before* people update debhelper's compat level, then
we know we broke it bac
Control: tags -1 + patch
Hi, Sergio,
<3 S2 <3 S2
On Thu, 30 Jul 2020, Sergio Durigan Junior wrote:
>
> So, here's the thing. We can't blindly rely on debhelper's
> filedoublearray anymore, because of the problem you guys pointed out
> above. Which means that bash-completion will probably have
Control: severity -1 important
Control: tags -1 + confirmed
Hi, Anthony,
thanks for the report!
On 17 Jul 2020, Anthony Fok wrote:
>I ran into the following error while packaging the latest version of
>hugo package:
>
>dh_bash-completion: error: Cannot resolve variable
> "${BASH_COMP_DEBUG
Hi, Vasyl,
On 26 Jul 2020, Vasyl Gello wrote:
>I need it to satisfy kodi build dependency in libcdio++. Actually, when Kodi
>19.0 goes live officially,
>I would like to have it in unstable, testing (if it gets released before the
>freeze takes place)
That sounds reasonable, and I'm already wor
Hi, Vasyl,
On 26 Jul 2020, Vasyl Gello wrote:
>I need it to satisfy kodi build dependency in libcdio++. Actually, when Kodi
>19.0 goes live officially,
>I would like to have it in unstable, testing (if it gets released before the
>freeze takes place)
That sounds reasonable, and I'm already wor
1 - 100 of 377 matches
Mail list logo
