Bug#755631: python-django-treebeard: Please ensure it works with Django 1.7
Source: python-django-treebeard Version: 2.0~beta1-4 Severity: important User: python-dja...@packages.debian.org Usertags: django17 Hello, your package python-django-treebeard depends on python-django. As you might know, Django 1.7 will be soon available and as each new upstream major version, it brings many changes, some of them which are backwards incompatible (after a deprecation period covering 2 major versions): https://docs.djangoproject.com/en/1.7/releases/1.7/ https://docs.djangoproject.com/en/1.7/releases/1.7/#backwards-incompatible-changes-in-1-7 We intend to upload Django 1.7 to unstable as soon as it is available because we really want the latest version in jessie and the freeze is approaching fast. In preparation of that, I have uploaded a release candidate in experimental. Please test your package against Django 1.7 in experimental. If a new upstream version of your package is required, please package it now. If you can't upload it to unstable because it only works with Django 1.7, feel free to upload it to experimental too. If the current package works fine, please close this bug (or retitle it as a suggestion to implement Python 3 support and drop its severity to wishlist[1]). If it's broken, please tag it as confirmed. If it's not broken, but would benefit from further work, please tag it as confirmed but reduce the severity. If you have experimental in your sources.list you can install the latest version easily: $ sudo apt-get install -t experimental python-django python3-django [1] We have recently added Python 3 support with the addition of python3-django. Consider doing the same if your package is a Django application/library. Thank you for your help! PS: I will raise the "confirmed" bugs that are still of severity "important" to "serious" once we upload Django 1.7 to unstable. -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140722080810.4ff0b5b7...@soleymieux.ouaza.com
Bug#755593: django-authority: Please ensure it works with Django 1.7
Source: django-authority Version: 0.5-2 Severity: important User: python-dja...@packages.debian.org Usertags: django17 Hello, your package django-authority depends on python-django. As you might know, Django 1.7 will be soon available and as each new upstream major version, it brings many changes, some of them which are backwards incompatible (after a deprecation period covering 2 major versions): https://docs.djangoproject.com/en/1.7/releases/1.7/ https://docs.djangoproject.com/en/1.7/releases/1.7/#backwards-incompatible-changes-in-1-7 We intend to upload Django 1.7 to unstable as soon as it is available because we really want the latest version in jessie and the freeze is approaching fast. In preparation of that, I have uploaded a release candidate in experimental. Please test your package against Django 1.7 in experimental. If a new upstream version of your package is required, please package it now. If you can't upload it to unstable because it only works with Django 1.7, feel free to upload it to experimental too. If the current package works fine, please close this bug (or retitle it as a suggestion to implement Python 3 support and drop its severity to wishlist[1]). If it's broken, please tag it as confirmed. If it's not broken, but would benefit from further work, please tag it as confirmed but reduce the severity. If you have experimental in your sources.list you can install the latest version easily: $ sudo apt-get install -t experimental python-django python3-django [1] We have recently added Python 3 support with the addition of python3-django. Consider doing the same if your package is a Django application/library. Thank you for your help! PS: I will raise the "confirmed" bugs that are still of severity "important" to "serious" once we upload Django 1.7 to unstable. -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140722080809.8bd815b7...@soleymieux.ouaza.com
Bug#538614: gtm: FTBFS with new source format 3.0 (quilt): improper handling of config.sub/config.guess
Package: gtm Version: 0.4.12+cvs20031024-4 Severity: wishlist Usertags: 3.0-quilt-by-default To prepare a possible switch to the new source package format "3.0 (quilt)" [1], I converted all source packages and rebuilt the packages afterwards to see what breaks, and gtm does break. To reproduce the problem you can do this: $ apt-get source gtm $ mkdir -p gtm-0.4.12+cvs20031024/debian/source $ echo "3.0 (quilt)" >gtm-0.4.12+cvs20031024/debian/source/format $ dpkg-source -b gtm-0.4.12+cvs20031024 $ dpkg-source -x gtm_0.4.12+cvs20031024-4.dsc $ cd gtm-0.4.12+cvs20031024 && debuild -us -uc In this process, if the .diff.gz contains changes to upstream files, dpkg-source will have created a corresponding patch in debian/patches/debian-changes-0.4.12+cvs20031024-4 and will have registered that patch in a quilt series (debian/patches/series, it is created if needed). All the patches listed in the "series" file are applied directly during the extraction (dpkg-source -x). quilt itself is used if available (and will thus lead to the creation of the .pc directory), otherwise dpkg-source applies the patches by itself. For more information about the new source package format see the manual page dpkg-source(1). In the case of gtm, it doesn't properly handle config.sub and config.guess. The .diff.gz contains changes to those files when it shouldn't (and this later leads to a quilt patch that can't be applied/unapplied). If you auto-update those files, you should do it just before configure and you should remove them in the clean rules (or put back in place a copy of the original files that you replaced). See /usr/share/doc/autotools-dev/README.Debian.gz for some details. Cheers, [1] http://wiki.debian.org/Projects/DebSrc3.0 -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#538679: dclock: FTBFS with new source format 3.0 (quilt): removes .pc before quilt pop
Package: dclock Version: 2.2.2-1 Severity: wishlist Usertags: 3.0-quilt-by-default To prepare a possible switch to the new source package format "3.0 (quilt)" [1], I converted all source packages and rebuilt the packages afterwards to see what breaks, and dclock does break. To reproduce the problem you can do this: $ apt-get source dclock $ mkdir -p dclock-2.2.2/debian/source $ echo "3.0 (quilt)" >dclock-2.2.2/debian/source/format $ dpkg-source -b dclock-2.2.2 $ dpkg-source -x dclock_2.2.2-1.dsc $ cd dclock-2.2.2 && debuild -us -uc In this process, if the .diff.gz contains changes to upstream files, dpkg-source will have created a corresponding patch in debian/patches/debian-changes-2.2.2-1 and will have registered that patch in a quilt series (debian/patches/series, it is created if needed). All the patches listed in the "series" file are applied directly during the extraction (dpkg-source -x). quilt itself is used if available (and will thus lead to the creation of the .pc directory), otherwise dpkg-source applies the patches by itself. For more information about the new source package format see the manual page dpkg-source(1). In the case of dclock, the clean target removes the .pc directory before calling quilt pop so quilt pop does nothing... Consider using /usr/share/quilt/quilt.make instead of using (broken) custom code. Cheers, [1] http://wiki.debian.org/Projects/DebSrc3.0 -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#576061: im-sdk: Please stop build-depending on dbs
Source: im-sdk Severity: wishlist Usertags: drop-dbs Hello, The dbs maintainer would like to deprecate/remove the dbs package considering that the new source format "3.0 (quilt)" provides the same functionality directly in dpkg-dev. Please update your package to stop using and build-depending on dbs. This bug is obviously filed with the consent of the dbs maintainer. Cheers, -- Raphaël Hertzog Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/ My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/ -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100331145903.a9486333...@soleymieux.ouaza.com
Bug#637057: Installing php5-idn makes apache2 segfault (if using the php5 module)
Package: php5-idn Version: 1.2b-6 Severity: critical I installed this php5 module as a dependency of libphp-simplepie and since then apache doesn's start anymore. I verified that decommenting the line in /etc/php5/conf.d/idn.conf makes it work again. Further inspection seems to indicate that it must not be loaded at the same time as php5-intl... since loading it without loading php5-intl works. This package has been removed from unstable, but maybe we should do in stable what we did in unstable: - update the libphp-simplepie dependency to php5-intl - make php5-intl conflict with php5-idn -- System Information: Debian Release: wheezy/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (150, 'experimental') Architecture: i386 (x86_64) Kernel: Linux 3.0.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110808070926.25877.5803.reportbug@rivendell.localdomain
Bug#527899: removal of package fails
On Tue, 02 Jun 2009, Chris Taylor wrote: > This patch fixes the removal bug in sqlrelay. It simply removes all > sqlrelay files and the directory from /etc. > > -Chris > > --- a/debian/sqlrelay.postrm > +++ b/debian/sqlrelay.postrm > @@ -19,7 +19,7 @@ set -e > case "$1" in > remove|purge) > rm -Rf /var/cache/sqlrelay > - rm -f /etc/sqlrelay* > + rm -rf /etc/sqlrelay* > ;; Removing configuration files on remove (instead of purge only) is a mistake too... Cheers, -- Raphaël Hertzog Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny : http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/ -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#485169: Source format "3.0 (quilt)" allowed in testing/unstable
[ Same message sent in bcc to all remaining "FTBFS with new source format" ] Hello, the new source format "3.0 (quilt)" is now allowed in testing/unstable and having all packages buildable with the new format is a release goal (http://wiki.debian.org/ReleaseGoals/NewDebFormats). Thus it would be nice to see this bug fixed. If you want, you can directly fix the bug by switching the package to use the new format. In order to help you in this process, I have put some advice on the project page and will continue to complete it with answers to your questions: http://wiki.debian.org/Projects/DebSrc3.0#FAQ If you need help, please tag the bug help and someone might provide you a patch. Ask explicitely if you want a patch to convert the package to the new source format. The few packages that contain multiple tarballs in the .orig tarball should (ideally) be converted to the new format by using the multiple upstream tarball feature that it offers. I also recommend switching to quilt if you use another patch system since it's now the patch system that is endorsed by the dpkg maintainers. If you have questions, please ask. Cheers, -- Raphaël Hertzog -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#553314: alltray: "Show/Hide" function and close button don't work
Hi Ignace, if you mail only 553...@bugs.debian.org the original bug submitter won't get a copy and you won't get an answer. Use 553314-submit...@bugs.debian.org or directly use group reply in the archive mbox that you can download on the web. Cheers, On Sat, 13 Feb 2010, Ignace Mouzannar wrote: > Hello, > > I am unable to reproduce this bug. > > Are you still experiencing this with the latest version (0.70-1) of > alltray? If yes, can you give me more details about your problem? > > Thank you in advance, > Ignace M > > > -- Raphaël Hertzog -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#571982: alltray: no tray icon; no way to get program in question back out of tray
severity 571982 important thanks On Sun, 28 Feb 2010, Lucas wrote: > Package: alltray > Version: 0.70-1 > Severity: grave > Justification: renders package unusable > > "alltray iceowl --st --na &" causes Iceowl to start, but no icon > actually appears in the system tray and there's no way to get the > program back up again without re-running it. Doesn't that kind of > defeat the purpose of alltray? Because you have the problem with one program doesn't mean it doesn't work at all. Thus it's not "unusable" and thus grave doesn't apply. I'll let the new maintainer deals with this bug. Cheers, -- Raphaël Hertzog Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/ My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/ -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100301074125.ga7...@rivendell
Bug#514305: smarty: Please sync the install path with Ubuntu
On Thu, 12 Aug 2010, Thijs Kinkhorst wrote: > I agree that given that Ubuntu has made this rather poor decision, we're only > left with this inelegant way forward to unify the packages again. Obviously > we > cannot have this changed for Squeeze anymore, so it'll have to be postponed > for a bit. Are you taking smarty over? > > But this won't work automatically if plugins are installed in libs/plugins/. > > You will have to add a preinst snippet that moves files around... > > /usr/share is the domain of the packaging system. So if there's anything in > libs/plugins, that is installed by another package and we should rather not > be > moving that around in preinst. Those packages should be updated instead, no? > You indicate this already for smarty-gettext and smarty-validate. Yes, they must be updated instead. Smarty will have to add conflicts:/breaks: statements to ensure they are upgraded. But there's the possibility that some plugins have been manually installed by the user. With breaks, you would have to setup the symlink in postinst because that's the only point where you can be sure that the other packages have been upgraded. With conflicts, you know in preinst already that other packages have been removed or upgraded already and you can deal with the symlink there in that case. Cheers, -- Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693] Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100815090034.ga29...@rivendell
Bug#484940: adonthell-data: FTBFS when converted to new source format 3.0 (quilt): due to patches that require -p0
Package: adonthell-data
Version: 0.3.4.cvs.20050903-4
Severity: minor
Usertags: 3.0-quilt-by-default
To prepare a possible switch to the new source package format "3.0
(quilt)" [1], I converted all source packages and tried to rebuild them.
Unfortunately, adonthell-data failed, you can try yourself with those
commands (and dpkg-dev >= 1.14.19 [2]) :
$ apt-get source adonthell-data
$ sed -i -e '/^Source:/ aFormat: 3.0 (quilt)'
adonthell-data-0.3.4.cvs.20050903/debian/control
$ dpkg-source -b adonthell-data-0.3.4.cvs.20050903
$ dpkg-source -x adonthell-data_0.3.4.cvs.20050903-4.dsc
$ cd adonthell-data-0.3.4.cvs.20050903 && debuild -us -uc
In this process, if the .diff.gz contains changes to upstream files,
dpkg-source will have created a corresponding patch in
debian/patches/debian-changes-0.3.4.cvs.20050903-4 and will have registered that
patch in a quilt series (debian/patches/series, it is created if needed).
All the patches listed in the "series" file are applied directly during
the extraction (dpkg-source -x). quilt itself is used if available (and
will thus lead to the creation of the .pc directory), otherwise
dpkg-source applies the patches by itself. For more information about the
new source package format see the manual page dpkg-source(1).
In the case of adonthell-data, it already uses quilt but some of the patches
require the '-p0' option of patch to be properly applied and this
option has been hardcoded in the series file. The new source package
format doesn't support this quilt feature and requires patches
to be applicable with the '-p1' option.
You can use the following command to easily update all the patches
that use the '-p0' option:
$ awk '{ if ($2 == "-p0") print $1 }' debian/patches/series | while read f; do
perl -pi -e 's|^--- (?:\./)?|--- a/|; s|^\+\+\+ (?:\./)?|+++ b/|;'
debian/patches/$f ; done
Not that you can replace "a" by "adonthell-data-0.3.4.cvs.20050903.orig" and
"b" by "adonthell-data-0.3.4.cvs.20050903" if you prefer.
Then don't forget to strip the "-p0" options from debian/patches/series.
As a side note, you must also pay attention to the following points in your
quilt usage to guarantee compatibility with the new source package
format:
- the patches must be in debian/patches/ together with the "series" file
(you can use QUILT_PATCHES=debian/patches if needed)
- you should not override QUILT_PC to change the location of quilt's
internal directory (".pc" by default)
- the patches should not reference absolute filenames (in +++/--- lines)
- your clean target must work even if the patches are already applied
- your build target must work with patches applied even if the clean
target is supposed to unapply them (because dpkg-source -b might
have applied them back)
Cheers,
[1] http://lists.debian.org/debian-devel-announce/2008/04/msg4.html
[2] the upcoming dpkg-dev 1.14.20 is more tolerant with patches, you can
grab it here if you want to try with that version:
http://people.debian.org/~hertzog/packages/dpkg-dev_1.14.20_all.deb
--
Raphael Hertzog
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#484977: adonthell: FTBFS when converted to new source format 3.0 (quilt): patches file created by .diff.gz
Package: adonthell
Version: 0.3.4.cvs.20050813-4
Severity: minor
Usertags: 3.0-quilt-by-default
To prepare a possible switch to the new source package format "3.0
(quilt)" [1], I converted all source packages and tried to rebuild them.
Unfortunately, adonthell failed, you can try yourself with those
commands (and dpkg-dev >= 1.14.19 [2]) :
$ apt-get source adonthell
$ sed -i -e '/^Source:/ aFormat: 3.0 (quilt)'
adonthell-0.3.4.cvs.20050813/debian/control
$ dpkg-source -b adonthell-0.3.4.cvs.20050813
$ dpkg-source -x adonthell_0.3.4.cvs.20050813-4.dsc
$ cd adonthell-0.3.4.cvs.20050813 && debuild -us -uc
In this process, if the .diff.gz contains changes to upstream files,
dpkg-source will have created a corresponding patch in
debian/patches/debian-changes-0.3.4.cvs.20050813-4 and will have registered that
patch in a quilt series (debian/patches/series, it is created if needed).
All the patches listed in the "series" file are applied directly during
the extraction (dpkg-source -x). quilt itself is used if available (and
will thus lead to the creation of the .pc directory), otherwise
dpkg-source applies the patches by itself. For more information about the
new source package format see the manual page dpkg-source(1).
In the case of adonthell, it already uses quilt but the patch
02_use_libsdl-ttf.diff modifies a file (src/py_adonthell_wrap.cc)
that doesn't exist in the original tarball. That file is created by the
Debian .diff.gz.
You should thus simply create the full file within the patch
02_use_libsdl-ttf.diff instead of having the change split in two
places. The conversion of the package fails when dpkg-source
tries to apply the quilt series on top of the plain upstream
directory (precisely when it tries to convert the local changes
to a new patch at the _end_ of the quilt series).
As a side note, you must also pay attention to the following points in
your quilt usage to guarantee compatibility with the new source package
format:
- all your patches must be applicable with the "-p1" option of patch
(and you shouldn't use options in the series file to override this)
- the patches must be in debian/patches/ together with the "series" file
(you can use QUILT_PATCHES=debian/patches if needed)
- you should not override QUILT_PC to change the location of quilt's
internal directory (".pc" by default)
- the patches should not reference absolute filenames (in +++/--- lines)
- your clean target must work even if the patches are already applied
- your build target must work with patches applied even if the clean
target is supposed to unapply them (because dpkg-source -b might
have applied them back)
Cheers,
[1] http://lists.debian.org/debian-devel-announce/2008/04/msg4.html
[2] the upcoming dpkg-dev 1.14.20 is more tolerant with patches, you can
grab it here if you want to try with that version:
http://people.debian.org/~hertzog/packages/dpkg-dev_1.14.20_all.deb
--
Raphael Hertzog
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#485158: apt-spy: FTBFS when converted to new source format 3.0 (quilt): patch depends on changes from the diff.gz
Package: apt-spy
Version: 3.1-18
Severity: minor
Usertags: 3.0-quilt-by-default
To prepare a possible switch to the new source package format "3.0
(quilt)" [1], I converted all source packages and tried to rebuild them.
Unfortunately, apt-spy failed, you can try yourself with those
commands (and dpkg-dev >= 1.14.19 [2]) :
$ apt-get source apt-spy
$ sed -i -e '/^Source:/ aFormat: 3.0 (quilt)' apt-spy-3.1/debian/control
$ dpkg-source -b apt-spy-3.1
$ dpkg-source -x apt-spy_3.1-18.dsc
$ cd apt-spy-3.1 && debuild -us -uc
In this process, if the .diff.gz contains changes to upstream files,
dpkg-source will have created a corresponding patch in
debian/patches/debian-changes-3.1-18 and will have registered that
patch in a quilt series (debian/patches/series, it is created if needed).
All the patches listed in the "series" file are applied directly during
the extraction (dpkg-source -x). quilt itself is used if available (and
will thus lead to the creation of the .pc directory), otherwise
dpkg-source applies the patches by itself. For more information about the
new source package format see the manual page dpkg-source(1).
In the case of apt-spy, some patches of the quilt series rely on changes
contained in the .diff.gz. Please move those changes in the quilt series
as well.
With the new source format this fails because the new debian-changes-*
patch gets applied _after_ the quilt series.
As a side note, you must also pay attention to the following points in
your quilt usage to guarantee compatibility with the new source package
format:
- all your patches must be applicable with the "-p1" option of patch
(and you shouldn't use options in the series file to override this)
- the patches must be in debian/patches/ together with the "series" file
(you can use QUILT_PATCHES=debian/patches if needed)
- you should not override QUILT_PC to change the location of quilt's
internal directory (".pc" by default)
- the patches should not reference absolute filenames (in +++/--- lines)
- your clean target must work even if the patches are already applied
- your build target must work with patches applied even if the clean
target is supposed to unapply them (because dpkg-source -b might
have applied them back)
Cheers,
[1] http://lists.debian.org/debian-devel-announce/2008/04/msg4.html
[2] the upcoming dpkg-dev 1.14.20 is more tolerant with patches, you can
grab it here if you want to try with that version:
http://people.debian.org/~hertzog/packages/dpkg-dev_1.14.20_all.deb
--
Raphael Hertzog
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#485169: jack-tools: FTBFS when converted to new source format 3.0 (quilt): patch files contained in tarballs
Package: jack-tools
Version: 0.0.2-5
Severity: wishlist
Usertags: 3.0-quilt-by-default
To prepare a possible switch to the new source package format "3.0
(quilt)" [1], I converted all source packages and tried to rebuild them.
Unfortunately, jack-tools failed, you can try yourself with those
commands (and dpkg-dev >= 1.14.19 [2]) :
$ apt-get source jack-tools
$ sed -i -e '/^Source:/ aFormat: 3.0 (quilt)' jack-tools-0.0.2/debian/control
$ dpkg-source -b jack-tools-0.0.2
$ dpkg-source -x jack-tools_0.0.2-5.dsc
$ cd jack-tools-0.0.2 && debuild -us -uc
In this process, if the .diff.gz contains changes to upstream files,
dpkg-source will have created a corresponding patch in
debian/patches/debian-changes-0.0.2-5 and will have registered that
patch in a quilt series (debian/patches/series, it is created if needed).
All the patches listed in the "series" file are applied directly during
the extraction (dpkg-source -x). quilt itself is used if available (and
will thus lead to the creation of the .pc directory), otherwise
dpkg-source applies the patches by itself. For more information about the
new source package format see the manual page dpkg-source(1).
In the case of jack-tools, the quilt series is only applicable
after extraction of a tarball/zipfile/jarfile. But dpkg-source
tries to apply the quilt series immediately after unpack
and will thus fail.
In several cases the usage of tarball(s) in tarball is justified by the
fact that several upstream tarballs have to be combined. The new format
does support unpacking of multiple upstream tarballs and as such, you
probably want to defer fixing this bug until the new format is accepted
and directly make usage of this new feature.
If your package only contains a single tarball, you might want to
reconsider the choice of using a tarball inside a tarball and
handle the build like do most other Debian packages.
In all cases, those are heavy changes for a simple wishlist bug and
I can understand that you don't fix this until after lenny's release.
I'm merely filing this bug to keep track of the packages that will cause
troubles when we switch to the new format.
As a side note, you must also pay attention to the following points in
your quilt usage to guarantee compatibility with the new source package
format:
- all your patches must be applicable with the "-p1" option of patch
(and you shouldn't use options in the series file to override this)
- the patches must be in debian/patches/ together with the "series" file
(you can use QUILT_PATCHES=debian/patches if needed)
- you should not override QUILT_PC to change the location of quilt's
internal directory (".pc" by default)
- the patches should not reference absolute filenames (in +++/--- lines)
- your clean target must work even if the patches are already applied
- your build target must work with patches applied even if the clean
target is supposed to unapply them (because dpkg-source -b might
have applied them back)
Cheers,
[1] http://lists.debian.org/debian-devel-announce/2008/04/msg4.html
[2] the upcoming dpkg-dev 1.14.20 is more tolerant with patches, you can
grab it here if you want to try with that version:
http://people.debian.org/~hertzog/packages/dpkg-dev_1.14.20_all.deb
--
Raphael Hertzog
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#485336: imlib: FTBFS when converted to new source format 3.0 (quilt): invalid patch
Package: imlib
Version: 1.9.15-7
Severity: minor
Usertags: 3.0-quilt-by-default
To prepare a possible switch to the new source package format "3.0
(quilt)" [1], I converted all source packages and tried to rebuild them.
Unfortunately, imlib failed, you can try yourself with those
commands (and dpkg-dev >= 1.14.19 [2]) :
$ apt-get source imlib
$ sed -i -e '/^Source:/ aFormat: 3.0 (quilt)' imlib-1.9.15/debian/control
$ dpkg-source -b imlib-1.9.15
$ dpkg-source -x imlib_1.9.15-7.dsc
$ cd imlib-1.9.15 && debuild -us -uc
In this process, if the .diff.gz contains changes to upstream files,
dpkg-source will have created a corresponding patch in
debian/patches/debian-changes-1.9.15-7 and will have registered that
patch in a quilt series (debian/patches/series, it is created if needed).
All the patches listed in the "series" file are applied directly during
the extraction (dpkg-source -x). quilt itself is used if available (and
will thus lead to the creation of the .pc directory), otherwise
dpkg-source applies the patches by itself. For more information about the
new source package format see the manual page dpkg-source(1).
In the case of imlib, the quilt series contains some invalid
patches. The stats in the headers (the line with @@) somehow do not
correspond to the reality of the patch below.
You can generally use quilt refresh to fix the broken patches (you might
want to refresh them all to be sure).
As a side note, you must also pay attention to the following points in
your quilt usage to guarantee compatibility with the new source package
format:
- all your patches must be applicable with the "-p1" option of patch
(and you shouldn't use options in the series file to override this)
- the patches must be in debian/patches/ together with the "series" file
(you can use QUILT_PATCHES=debian/patches if needed)
- you should not override QUILT_PC to change the location of quilt's
internal directory (".pc" by default)
- your clean target must work even if the patches are already applied
- your build target must work with patches applied even if the clean
target is supposed to unapply them (because dpkg-source -b might
have applied them back)
Cheers,
[1] http://lists.debian.org/debian-devel-announce/2008/04/msg4.html
[2] the upcoming dpkg-dev 1.14.20 is more tolerant with patches, you can
grab it here if you want to try with that version:
http://people.debian.org/~hertzog/packages/dpkg-dev_1.14.20_all.deb
--
Raphael Hertzog
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#486955: might be caused by a dpkg-dev regression?
On Thu, 19 Jun 2008, Lucas Nussbaum wrote: > Hi, > > I figured this out too late, but it seems that all those bugs are caused > by a dpkg-dev regression. > Bug#486987: sugar-toolkit: FTBFS: new copyright notices > Bug#486979: sugar-datastore: FTBFS: new copyright notices > Bug#486975: sugar-web-activity: FTBFS: new copyright notices > Bug#487002: sugar-pippy-activity: FTBFS: new copyright notices > Bug#486961: sugar-chat-activity: FTBFS: new copyright notices > Bug#486984: sugar: FTBFS: new copyright notices > Bug#487001: sugar-journal-activity: FTBFS: new copyright notices Those are related to a licensecheck improvement. Those checks should really go away and be run by the maintainer when he wants to check it and not automatically on build. > Bug#486982: gnomesword: FTBFS: patching failed > Bug#486955: jack-tools: FTBFS: patching failed > Bug#486988: bibledit: FTBFS: patching failed > Bug#486996: gpib: FTBFS: patching failed Those might be related to the change made on quilt: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=485835 It might be that CDBS packages using tarball in tarball and the quilt patching were implicitely using this feature... if that's the case I'd like to know how many packages are affected to be able to decide if we should revert that change. Can you retry all the packages that might be affected by this with quilt 0.46-4.1 instead of 0.46-5 ? > There are a few other candidates I haven't filed (new failure && package > using quilt ; false positives highly possible): A few random packages analyzed: > awstats > moin > yaird => also related to licensecheck > sword => related to quilt The bigger one like icedove and iceowl are probably related too. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#818907: live-build: Fails to integrate a binary package whose name contains an uppercase character
Package: live-build Version: 1:20151215 Severity: normal User: de...@kali.org Usertags: origin-kali If you download a Nessus deb from here: https://www.tenable.com/products/nessus/select-your-operating-system You get a Nessus-6.5.6-debian6_amd64.deb file for a "Nessus" package. Note the uppercase N in the package name... (both in the filename and in the .deb meta-data shown with dpkg -I) Put that file in config/packages.chroot/ and try a live-build, you will get an error like this: [2016-03-19 19:50:13] lb chroot_install-packages install P: Begin installing packages (install pass)... Reading package lists... Building dependency tree... Reading state information... E: Unable to locate package Nessus P: Begin unmounting filesystems... P: Saving caches... Reading package lists... Building dependency tree... Reading state information... -- Package-specific info: -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.4.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages live-build depends on: ii debootstrap 1.0.79 Versions of packages live-build recommends: ii apt-utils 1.2.7 ii cpio2.11+dfsg-5 ii live-boot-doc 1:20151213 ii live-config-doc 5.20151121 ii live-manual-html [live-manual] 2:20151217 ii wget1.17.1-1+b1 Versions of packages live-build suggests: ii debian-keyring 2016.01.20 ii gpgv1.4.20-4 -- no debconf information
Bug#818907: live-build: Fails to integrate a binary package whose name contains an uppercase character
On Mon, 21 Mar 2016, Rene Engelhard wrote: > Which is broken. It's not broken (the package works) but it doesn't conform to the Debian policy, certainly. > I don't think it is a bug if one can't handle a broken package. I think it's a bug, albeit a minor one. If there was a technical reason to not create such packages, dpkg would not allow to create such packages. > And isn't this apt/aptitude here, anyways? So it would be apt/aptitude "bug"? I have not investigated further so I don't know. It might be live-build which is not copying the files properly, it might be apt-ftparchive which is not generating the Packages file correctly or it might be apt-get not finding the package. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)
Hi, On Sun, 31 Jul 2016, adrian15 wrote: > Is there anyone else than can provide feedback on this patch / branch? > > Either by: > > * Installing live-build with this applied patch > * Building your iso and check if it boots in both BIOS and UEFI mode. > * Check non usual UEFI machines. > > I suspect it's fine to wait for one week for feedback. > After that time I'll try to request a proper pull / insertion into Debian's > live-build repo and probably into live-build package binaries. I can give a try to your patchset but I'm currently in vacation so it would not be before the third week of August. This is just FYI but you don't have to wait on my feedback to get your work merged if people are happy with it. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)
On Thu, 25 Aug 2016, adrian15 wrote: > That's how the grub-pc menu (BIOS) shows currently in live-build. Well, it sucks compared to the default visual appearance of isolinux/syslinux in live-build. > > - there are no menu entries to start debian-installer even though > >I built my image with "--debian-installer live" > > There were not such entries in the isolinux menu (BIOS). I already commented > such incongruence when I submitted my loopback patch but Daniel (or irl > maybe?. It was around the time dba quitted the project) agreed to merge my > code. > > Compared to binary_grub2 script I have removed the installation > entries because I did not see any of them in binary_syslinux. > > Can you explain to me why such Installation entries are not available in > binary_syslinux? > Maybe they should be put there also? Well, the menu entries are there by default: $ cat share/bootloaders/isolinux/menu.cfg menu hshift 0 menu width 82 menu title Boot menu include stdmenu.cfg include live.cfg include install.cfg menu begin advanced menu title Advanced options include stdmenu.cfg label mainmenu menu label ^Back.. menu exit include advanced.cfg menu end menu clear $ cat share/bootloaders/isolinux/install.cfg label install menu label ^Install linux /install/vmlinuz initrd /install/initrd.gz append vga=788 @APPEND_INSTALL@ --- quiet label installgui menu label ^Graphical install linux /install/gtk/vmlinuz initrd /install/gtk/initrd.gz append video=vesa:ywrap,mtrr vga=788 @APPEND_INSTALL@ --- quiet In fact I have not found any code to drop those entries when you don't want debian-installer in your live image... so I would rather see the opposite problem. So please add those entries in the grub menu. > > - the menu entries hardcode "Debian GNU/Linux" as name of the project, > >in the default syslinux configuration the entries are agnostic as in > >"Live (@FLAVOUR@)". > That @FLAVOUR@ is from Debian's live-build? Yes: $ cat share/bootloaders/isolinux/live.cfg.in label live-@FLAVOUR@ menu label ^Live (@FLAVOUR@) menu default linux @LINUX@ initrd @INITRD@ append @APPEND_LIVE@ label live-@FLAVOUR@-failsafe menu label ^Live (@FLAVOUR@ failsafe) linux @LINUX@ initrd @INITRD@ append @APPEND_LIVE_FAILSAFE@ > > I guess that some of those issues are not due to your changes, they > > are probably longstanding issues in the generic grub code but still > > it would be nice to have this fixed to have a more consistent experience > > between grub and syslinux. > > Well, there are some possible solutions to this problem: > > 1. Try to reuse some code from jnqnfe. He did quite some work on improving > bootloaders design which I don't think got into GIT: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775322 . His patch set is massive... but yes we should probably review them and merge what's appropriate. > 2. Try to reuse the debian-cd scripts which try to convert syslinux cfg > files into grub ones (including the design). > > Here: > > https://anonscm.debian.org/cgit/debian-cd/debian-cd.git/tree/tools/boot/jessie/parse_isolinux > > Not sure if this is the correct version to use but be warned that Sledge > himself warns us that it's not pretty. Yeah, I looked that code in the past and I would not want to rely on this even though the principle would be nice... > 3. Commit the patch as is and later on add more patches on the minimal set > needed for prettyfing this. I'm ok for this but I would still like you to re-add the installer entries first. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)
On Fri, 26 Aug 2016, adrian15 wrote: > > Well, it sucks compared to the default visual appearance of > > isolinux/syslinux in live-build. > I know, but the purpose of my patch is to add UEFI support. Not to improve > visual appearance of grub2 so that it matches the isolinux/syslinux one. Well, my initial patch added EFI support on top of syslinux-efi and it thus had a nice visual appearance by default. So for me it's a regression... But I assume it's not a regression in terms of computers supported because I believe that syslinux-efi works for less cases than grub-efi and hence why I did not commit my own patch in the first place. Also I expect that secure boot will be easier to add on top of grub than on top of syslinux. So I agree to apply your patch but I hope that you will stick around to help improve the visual appearance. > These: /install/vmlinuz and /install/initrd.gz strings seem to be hardcoded. > That explains why I did not see them in binary_syslinux . > What does happen if you request both x86 and amd64 in your Debian Live? The > first kernel gets into the /install/vmlinuz and the second kernel gets > discarded? I don't know, I never tried to build images for multiple architectures. It's not a need for me. > I will apply those patches as an addendum to my current changes. I don't > think it's worth the rebased needed for applying first the changes into the > grub-pc code. Fine for me. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)
Hi, On Fri, 26 Aug 2016, adrian15 wrote: > I don't know how to add Debian Installer to a Debian Live so I have not been > able to test it. > > So your feedback as user of the Debian Installer is welcome. Your patch seems to work. We get a lot of new top-level entries (install, expert, rescue, auto) all in text and gui variants. I pushed your branch to the git repository. Let the work continue! Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Bug#773775: About bootstrap_archive-keys
Hello, I reviewed the patches submitted in that bug and I have not found one worth committing. live-build is in low maintenance mode so I'm trying to not break compatibility with unnecessary new requirements. In fact, I believe that the bootstrap_archive-keys step is entirely useless. We already have the --keyring-packages option. It forces usage of a package, but that's acceptable IMO. I'm going to drop the script entirely. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Bug#718225: Review of live-build patchset to authenticate downloaded files
Control: tag -1 - patch Control: severity -1 + wishlist I quickly reviewed the patch set and it's way too intrusive for me to commit it. I think the goal is laudable but the approach taken is overkill. We don't need new options, we just want something safe by default. If anything we should be using apt even more... I don't plan to spend time on this large problem given that live-build. live-build is in a low maintenance mode and that kind of large change is not the kind of thing that we are interested in. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Bug#573173: support multiple kernel versions with same flavour
Control: tag -1 - patch Hello Michal, On Thu, 25 Aug 2016, Michal Suchanek wrote: > sending fixed/updated version of the patch. > This works for me quite well with live-build in Debian and Syslinux. > Grub is unsupported. As long as grub is unsupported, I can't really apply this patch. In particular since grub is required for EFI support nowadays. Also I'm not sure that I like the fact that we advertise the kernel version by default. As you might have noticed, the default grub config in Debian hides the current kernel version. You only see it in a sub-menu. We should probably aim for something similar in live-build when we have multiple kernels. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Bug#819136: Bugs included in #819136 patches
Hello, On Fri, 09 Jun 2017, Elliott Mitchell wrote: > Guess I should give at least a partial list of the extra bugfixes > included in the #819136 patch series: I was looking at bugs with patchs and saw this one. I believe most of the patches are obsolete, the only thing that should remain is the part where you try to generate a separate .deb. Are we actually allowed to build a .deb and distribute the firmware directly in a .deb? I haven't checked but I guess that it's "no", otherwise we would likely ship the firmware ourselves in non-free... I saw you contributed regularly to the package. What about getting a salsa account and taking over package maintenance? In any case, an update on this bug would be appreciated. Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS
Bug#786790: About the security issues affecting dcraw/ufraw/libraw/rawtherapee/rawstudio/exactimage/freeimage in Squeeze
Hello dear maintainer(s), the Debian LTS team recently reviewed the security issue(s) affecting your package in Squeeze: https://security-tracker.debian.org/tracker/CVE-2015-3885 We decided that we would not prepare a squeeze security update (usually because the security impact is low and that we concentrate our limited resources on higher severity issues and on the most widely used packages). That said the squeeze users would most certainly benefit from a fixed package. If you want to work on such an update, you're welcome to do so. Please try to follow the workflow we have defined here: http://wiki.debian.org/LTS/Development If that workflow is a burden to you, feel free to just prepare an updated source package and send it to debian-...@lists.debian.org (via a debdiff, or with an URL pointing to the the source package, or even with a pointer to your packaging repository), and the members of the LTS team will take care of the rest. However please make sure to submit a tested package. Thank you very much. Raphaël Hertzog, on behalf of the Debian LTS team. -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150526155045.ga6...@home.ouaza.com
Bug#797165: CVE-2015-0852: integer overflow in PluginPCX.cpp
Source: freeimage Version: 3.10.0-4 Severity: serious Tags: security upstream fixed-upstream Hi, the following vulnerability was published for freeimage. CVE-2015-0852[0]: Integer overflow in PluginPCX.cpp If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2015-0852 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-0852 https://marc.info/?l=oss-security&m=144073280200732&w=2 Please adjust the affected versions in the BTS as needed. BTW upstream patches are available but they are not minimal patches: http://freeimage.cvs.sourceforge.net/viewvc/freeimage/FreeImage/Source/FreeImage/PluginPCX.cpp?r1=1.17&r2=1.18&pathrev=MAIN http://freeimage.cvs.sourceforge.net/viewvc/freeimage/FreeImage/Source/FreeImage/PluginPCX.cpp?r1=1.18&r2=1.19&pathrev=MAIN Hopefully one the of the people who will discover this RC bug (because their package depends on freeimage or whatever) can be convinced to take over this package... it has been orphaned for way too long. Note that the package has another pending security issue (#786790). Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Bug#993678: Fails to produce PDF output when using scale.by.width - produces broken lstlisting/lstcode options
Control: forwarded -1 https://sourceforge.net/p/dblatex/bugs/129/ Hello, I have forwarded this bug to the upstream bug tracker and I pinged the upstream author by email to try to draw his attention to this issue. Cheers, -- Raphaël Hertzog
Bug#993678: Fails to produce PDF output when using scale.by.width - produces broken lstlisting/lstcode options
Control: tags -1 + patch
Le samedi 04 septembre 2021, Daniel Leidert a écrit :
> While building a PDF we stumbled upon an issue. Some of our XML files contain
> screen elements with non UTF-8 characters. When we enable scaling for listing
> elements:
>
> scale.by.width
>
> dblatex fails. The produced .tex files then contain line such as:
>
> \begin{lstcode}[escapeinside={<:}{:>}][scale=false,firstnumber=1,escapeinside={}{},moredelim={**[is][\bfseries]{}{}},moredelim={**[is][\itshape]{}{}},]
Upstream has provided a patch in
https://sourceforge.net/p/dblatex/bugs/_discuss/thread/6efb34bd22/7a8a/attachment/rawverb.patch
Can you test it and report back whether it helps? If you can send your
feedback directly to upstream that would be great:
https://sourceforge.net/p/dblatex/bugs/129/
Thank you in advance.
--
Raphaël Hertzog
Re: chroot-debianizer - Tool that automates routine work with Debian packages.
Hi, On Tue, 11 Feb 2025, Kirill Rekhov wrote: > I wrote a script called chroot-debianizer that automates routine tasks related > to Debian package management. This tool is designed to facilitate a clean and > isolated package building process in chroot environments specifically for the > amd64 architecture. > > chroot-debianizer serves as a wrapper around existing tools like pbuilder, > pdebuild, and debootstrap, streamlining them into a single workflow. After > building a package, the tool runs various utilities such as lintian, blhc, > lrc, > duck, etc, to ensure that the package meets Debian Policy standards and is > free > from common issues. Personally, I'm too lazy to constantly launch them > manually, > so I wrote them into one script and made it more automated. That sounds like what the "debian_pipeline" workflow can do in https://debusine.debian.net, except that it is able to do it on multiple architectures and also run reverse dependencies autopkgtest (however it doesn't support duck nor lrc, I don't even know what lrc is...). https://freexian-team.pages.debian.net/debusine/reference/workflows/specs/debian-pipeline.html We don't have any user-friendly documentation yet, i.e. tutorial-like, to show how to run those workflows but the feature is basically there already and workflows have been run: https://debusine.debian.net/debusine/System/work-request/70965/ https://debusine.debian.net/debusine/System/work-request/72260/ https://debusine.debian.net/debusine/System/workflow/?workflow_templates=build-pipeline Feel free to hang out in #debusine on IRC and ask questions if you want to try it out. Though at this point, debusine.debian.net is only usable by DD, we are considering to open it up a bit more broadly in the not too distant future. > Thank you for your time and consideration. I look forward to hearing your > thoughts. Maybe there is already a cooler solution? but I don't know about it. Hopefully you will find debusine cool :-) being a web service, it also means that the build happen remotely. Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS
Bug#1101536: openvpn-systemd-resolved: package is no longer installable
Hello, On Sat, 29 Mar 2025, Luca Boccassi wrote: > The openvpn-systemd-resolved package is no longer installable on > unstable, as systemd-resolved is no longer available in unstable. Please don't act on this request for now. The removal of systemd-resolved is hopefully not going to last... even though Luca is very annoyed at the technical committee decision, ultimately I'm pretty sure that things will settle down and that systemd-resolved will come back in Debian. Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS
