On 2025-04-20 Josh Triplett wrote:
> Andrey Rakhmatullin wrote:
> > Should we start declaring deps on all essential packages explicitly?
> I personally think that would be a good idea, though I'm not currently
> trying to make the case for that across the board here. Right now, I'm
[...]
> From w
On 2025-04-17 Osamu Aoki wrote:
> Following up on my previous post.
>> How about adding simpler versioned depends (no pre-depends) with pre-rm
>> script?
> I am talking about tricks using the "dpkg-maintscript-helper
> symlink_to_dir ..." command. Any thought?
[deleting drafted response]
This
On 2025-04-16 Simon Josefsson wrote:
[...]
> Was invoking the system library exception discussed or decided on
> project-wide in Debian? I tried to find some earlier discussion around
> this, and while many discussions is possible to find, I don't see any
> conclusions.
Good morning,
iirc it ca
On 2025-04-13 Chris Hofstaedtler wrote:
> brian m. carlson (one of the git upstream copyright holders) claims
> in Bug #1094969 that git cannot be distributed when linked with
> OpenSSL. IIRC the Debian position is to use the system library
> exception.
> Indeed our /usr/lib/git-core/git-remot
On 2025-03-09 Soren Stoutner wrote:
> On Saturday, March 8, 2025 4:23:56 PM MST Philip Hands wrote:
[...]
> > You seem to be under the impression that there's an emerging consensus
> > in favour of your idea.
> Yes, I feel like there are a majority of Debian Developers who are in favor
> of maki
On 2025-03-04 Blair Noctis wrote:
> On 04/03/2025 01:29, Andreas Metzler wrote:
[...]
> > There is another downside to the BTS sending mails to uploaders. - There
> > is no simple unsubscribe, it would need a sourceful upload.
> I wonder who would bother to add themself to Uplo
On 2025-03-02 Blair Noctis wrote:
[...]
> 2. Let PTS automatically subscribe maintainers to packages they are Uploaders
> of
> In the current version of the PTS, subscribing to a package means either a.
> after logging in, clicking the Subscribe button on
> tracker.debian.org/pkg/foo, and opti
On 2025-01-17 Frank Guthausen wrote:
> On Tue, 7 Jan 2025 19:01:51 +0100
> Andreas Metzler wrote:
> >
> > Afaik there is no /known/ blocker except for the
> > libgnupg-interface-perl test error #1088155.
> According to bug report[1] there are failed subtests i
On 2025-01-13 Simon Josefsson wrote:
> Jonathan McDowell writes:
[...]
> > I agree, but in this instance given the reliance we have upon GnuPG
> > throughout the Debian ecosystem I believe it's important we ensure that
> > the default configuration of what we ship is compatible with OpenPGP.
> >
On 2025-01-10 Frank Guthausen wrote:
[...]
> I reconstructed the following timeline:
> Debian bullseye hard freeze[1]: 2021-03-12
> According to Upstream[2], GnuPG 2.4 birth: 2021-04-07 (maybe as devel)
Definitely -devel
https://lists.gnupg.org/pipermail/gnupg-announce/2021q2/00045
On 2025-01-08 Jonathan McDowell wrote:
> On Tue, Jan 07, 2025 at 07:01:51PM +0100, Andreas Metzler wrote:
[...]
>> Should we move to 2.4? 2.4 is not a LTS release and will also EOL in
>> trixie' soon (2026-06-30).
> I haven't been fully following the GnuPG situat
On 2025-01-07 Simon Josefsson wrote:
[...]
> I believe this would be good, I frequently run into GnuPG bugs in the
> 2.2.x branch that was fixed years ago in 2.4 and today I mostly these on
> Debian because others moved on to 2.4.x. Andreas, can you give a
> current status of pending issues for
On 2024-12-29 Helmut Grohne wrote:
> On Sun, Dec 29, 2024 at 01:08:49PM +0100, Ansgar 🐱 wrote:
[...]
>> I would also like to do something similar to unstable; maybe start with
>> packages uploaded before some arbitrary date that are also not included
>> in any of oldstable/stable/testing. These ca
On 2024-12-23 Gioele Barabucci wrote:
> On 22/12/24 06:56, Andreas Metzler wrote:
>> On 2024-12-22 Sean Whitton wrote:
>>> On Sat 21 Dec 2024 at 10:23pm +01, Gioele Barabucci wrote:
>>>> We have a mechanism for when you feel responsible: "Maintainer: $me"
On 2024-12-22 Sean Whitton wrote:
> On Sat 21 Dec 2024 at 06:15pm +01, Chris Hofstaedtler wrote:
>> Uploads to the archive are not irreversible. You can just as well
>> upload a new version reverting whatever was done.
>> Please everybody stop treating the archive as the holy thing that
>> only
On 2024-12-22 Sean Whitton wrote:
> On Sat 21 Dec 2024 at 10:23pm +01, Gioele Barabucci wrote:
>> We have a mechanism for when you feel responsible: "Maintainer: $me".
>> What is being discussed here is a mechanism for shared, collective,
>> diffused responsibility: "If this package is in bad sh
On 2024-12-19 Andrey Rakhmatullin wrote:
> On Thu, Dec 19, 2024 at 04:58:06PM +0100, Samuel Thibault wrote:
>>> And it is actively harmful as if one edits the example configuration to
>>> have a useful configuration as dpkg will start annoying admins with
>>> "the example configuration has changed
On 2024-11-21 Julian Andres Klode wrote:
[...]
>An optimal mechanism would instea
[...]
Something seems to be missing here.
cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
On 2024-10-12 Alastair McKinstry wrote:
> On 12/10/2024 10:18, Andreas Metzler wrote:
> > On 2024-10-12 Alastair McKinstry wrote:
> > > Hi,
> > > cctools is at version 1:9.9 due to an error in 2021.
> > [...]
> >
> > Looks like a typo,
On 2024-10-12 Alastair McKinstry wrote:
> Hi,
> cctools is at version 1:9.9 due to an error in 2021.
[...]
Looks like a typo, afaict cctools currently has *no* epoch, i.e.
equivalent to 0:9.9.
cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to y
On 2024-10-06 Simon Josefsson wrote:
[...]
> I agree in principle, but I wonder if going through the effort of
> introducing a new source package 'signify-mail' and removing the current
> 'signify' will give us anything beyond doing the QA package upload to
> rename the binary package.
> The only
On 2024-10-05 Joachim Zobel wrote:
> Debian policy 9.2.1 says: "When maintainers choose a new hardcoded or
> dynamically generated username for packages to use, they should start
> this username with an underscore." By now this requires an
> adduser --allow-bad-names
> in the script creating th
On 2024-08-20 Helmut Grohne wrote:
> Hi fellow developers,
> (modified resend, as first attempt didn't arrive)
> please allow me to open a can of worms. Package removal from unstable.
> Deciding when it is time to remove a package from unstable is difficult.
> There may be users still and it is
On 2024-07-03 Alexandre Rossi wrote:
[...]
> #1073005 asks for the vendoring back of an unvendored library, arguing
> that this particular library is unmaintained upstream, implying that the
> vendored fork is better maintained.
> My view on this is that if the vendored fork is better maintained,
On 2024-06-14 Gürkan Myczko wrote:
[...]
> Have never done mass bug filings, any easy way, preferably something copy
> pastable,
> non-interactive.
Hej,
How about mass-bug(1) in devscripts?
cu Andreas
On 2024-05-29 Marco d'Itri wrote:
> On May 28, Andreas Metzler wrote:
>> I think it is bad choice to deliberately have different behavior for
>> freshly installed and upgraded systems. Offering upgrades has always
>> been one of the major selling points of Debian, an
On 2024-05-28 Luca Boccassi
wrote:
[...]
> - existing installations pre-trixie will get an orphaned tmpfiles.d in
> /etc/ that keeps the existing behaviour unchanged (no cleanup of
> /var/tmp)
[...]
Hello,
I think it is bad choice to deliberately have different behavior for
freshly installed an
On 2024-04-18 Sebastian Ramacher wrote:
[...]
> Let's start with the first category. Those are packages that could be
> binNMUed, but there are issues that make those rebuilds not have the
> desired effect. This list include packages that
> * are BD-Uninstallabe,
> * FTBFS but with out ftbfs-tag
On 2024-03-31 Andreas Metzler wrote:
[...]
> Afaict these are broken, though:
[...]
> tnat64 0.06-1
false positive, grep error.
On 2024-03-31 Andreas Metzler wrote:
> On 2024-03-31 Sven Joachim wrote:
[...]
>> Unfortunately the other four are not similar, but rather lacked a build
>> dependency on dpkg-dev (>= 1.22.5) which would have prevented their
>> migration to testing. Testing users on arme
On 2024-03-31 Sven Joachim wrote:
> On 2024-03-31 06:54 +0200, Andreas Metzler wrote:
> > On 2024-03-30 Julian Gilbey wrote:
[...]
> >> Looking through testing, I see the following t64 libraries present:
> >> libaio1t64
> >> libfyba0t64
> >
On 2024-03-30 Julian Gilbey wrote:
> My very limited understanding of this major transition was that the
> t64 libraries are being held in unstable until (almost) everything is
> ready, at which point there will be a coordinated migration into
> testing. But I've now been asked to upgrade somethi
On 2024-03-31 Wookey wrote:
[...]
> e.g. I remember it took me years to realise that I used _my_ public
> key for signing,
[...]
Good morning,
s/public/private/ - $recipient can then use your public key to verify
the sig.
cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other
On 2024-03-24 Samuel Henrique wrote:
> Hello everyone,
> Given our current time_t transition happening, which means packages
> are blocked from migrating to testing for weeks, and that unstable
> updates have become harder to apply, two critical CVE fixes for
> Firefox became impossible to get it
On 2024-03-02 Sven Joachim wrote:
> On 2024-03-02 08:47 +0100, Sven Joachim wrote:
>> On 2024-03-02 08:01 +0100, Andreas Metzler wrote:
>>> iirc it was recently proposed to add a suggestion to run dpkg --verify
>>> to the trixie upgrade notes to find missing
Hello,
iirc it was recently proposed to add a suggestion to run dpkg --verify
to the trixie upgrade notes to find missing files due to the usr-merge
transition. (Cannot find the reference right now).
However I just had file loss (due to libuuid changing its name to t64
and back again) and dpkg --
On 2024-02-26 John Goerzen wrote:
> Hi folks,
> As a person that frequently uploads to bookworm-backports, I am
> wondering how we are handling the time_t transition there?
> The picture of synchronization with testing is a little complicated over
> there. If you change the default build flags,
On 2024-02-09 John Goerzen wrote:
[...]
> So at the moment, I am unclear why there are bugs filed with severity
> serious that apparently cannot be fixed. Shouldn't they be normal with
> a tag wontfix until the relevant dpkg changes are in unstable?
> To put it another way, I'm not seeing why we
On 2024-02-06 Helmut Grohne wrote:
> Package: libselinux1t64
[...]> This looks fairly innocuous. We create a minimal sid chroot and install
> libselinux1t64 using apt. What could possibly go wrong? Well, apt thinks
> that it would be a good idea to avoid coinstalling breaking packages and
> first
On 2024-02-06 Alberto Garcia wrote:
> On Sun, Feb 04, 2024 at 11:05:46PM -0800, Steve Langasek wrote:
> > In fact, none of the t64 binaries currently being uploaded
> > to experimental have the final ABI either, we're just using
> > experimental to clear binary NEW.
> I was having a look at two o
On 2024-02-05 Tobias Heider wrote:
[...]
> As an active nvi user I would love to step up and help, but the biggest
> problem I see is that the choice of upstream project. Since the original
> is gone there isn't a clear successor.
> The BSDs all have their own forks which diverged over time (and
On 2024-02-03 Sebastian Andrzej Siewior wrote:
> On 2024-02-02 08:43:52 [-0800], Steve Langasek wrote:
>> debian-devel-announce wouldn't let me attach the file, but for those on
>> debian-devel at least, you can find the dd-list of to-be-NMUed source
>> packages attached.
> OpenSSL is on the lis
On 2024-01-21 Matthias Urlichs wrote:
> On 21.01.24 15:34, Andreas Metzler wrote:
> > However according to our release notes we only support upgrading from
> > release x to x+1, skipping releases is not allowed.
> I'm not talking about skipping releases but about partial
On 2024-01-21 Matthias Urlichs wrote:
> question: policy 3.5 states, rather unequivocally,
>Every package must specify the dependency information about other
>packages that are required for the first to work correctly.
> Now … does that apply to crossing release boundaries? Specifically,
On 2023-12-16 Jérémy Lal wrote:
[...]
> * Package name: acme.sh
> Version : 3.0.7
> Upstream Contact: w...@neilpang.com
> * URL : https://acme.sh
> * License : GPL-3
> Programming Lang: Shell
> Description : Pure unix shell script implementing ACME clien
On 2023-12-06 Dimitri John Ledkov wrote:
[...]
> May I also do a mass bug file against the above set of packages, at
> wishlist priority to nudge maintainers (or QA or Janitor) to make an
> upload?
> ideally bundled with any other reasonable modernisations. As such an
> algorithm indicates that th
On 2023-11-11 Michael Stone wrote:
> On Sat, Nov 11, 2023 at 11:50:31AM +0100, Andreas Metzler wrote:
> > you seem to have missed/deleted the paragraph where Ansgar suggested how
> > to do this *without* tradeoff. ("explicitly disable/enable build options
> > per arch&q
On 2023-11-10 Michael Stone wrote:
> On Fri, Nov 10, 2023 at 03:10:42PM +0100, Ansgar wrote:
>> Please avoid producing different results depending on the build
>> environment. That just results in non-reproducible issues in unclean
>> environments (suddenly different dependencies, different featur
On 2023-10-26 Vincent Lefevre wrote:
> On 2023-10-26 02:03:49 +0200, Vincent Lefevre wrote:
[...]
> Hmm... This seems to be due to a bug in the BTS when the bug was
> reopened for stable. At
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051563#25
> "Bug reopened Request was from Antonio
On 2023-10-15 Wookey wrote:
[...]
> OK. So I read all that, and learned a whole load of stuff I was quite
> happy not knowing about.
> However despite reading it all, and especially this bit:
> "Whenever I've maintained man pages in roff I tend to be precise in
> > the usage of - and \-, but TBH
On 2023-08-19 Diederik de Haas wrote:
> [please CC me as I'm not subscribed to debian-devel]
> On Mon, 17 Jul 2023 at 21:45:13 +1000, Hugh McMaster wrote:
> > On Mon, 17 Jul 2023 at 00:07, Simon McVittie wrote:
> > > On Sun, 16 Jul 2023 at 22:38:20 +1000, Hugh McMaster wrote:
> > > > Currently, t
On 2023-08-15 Boyuan Yang wrote:
[...]
> where .po file that contains translation is updated every time, causing dpkg-
> source to complain the diff and quit when building twoce in a row.
> Take https://tracker.debian.org/pkg/ibus-array as an example. The upstream
> project does not include .pot
Good morning,
guile-gnutls was uploaded almost a week ago to sid, but the unstable
autobuilders seem to ignore it.
https://buildd.debian.org/status/package.php?p=guile-gnutls
Is there anything I can do? The experimental uploads were picked up
seamlessly.
cu Andreas
--
`What a good friend you ar
On 2023-08-01 Helmut Grohne wrote:
[...]
> In moving crontab_setgid from lib to libexec, you effectively evade the
> moratorium and are entitled to also move from / to /usr. This is an
> action you can do right now. The move from /lib to /usr/libexec prevents
> the file loss scenario that spurred
On 2023-07-15 Markus Falb wrote:
> Hi, it’s Markus,
> …snip
> Index of /debian/dists/bookworm-updates/main
[...]
> The size of the gz files is 20, i.e. the unzipped files are empty.
> Is this by purpose?
Afaict (from looking at the Packages files) there are no Packagages yet
in bookworm-updates
On 2023-06-28 Helmut Grohne wrote:
> The category of generic changes includes
> imposing an ordering on initial unpacks (e.g. base-files first).
Hello,
I have not dug deeply into this but in the back of my mind a voice is
vaguely remebering that we already had multiple times wished we had this
i
On 2023-06-19 Sven Joachim wrote:
[...]
> If my above statements about debootstrap are correct, this will result
> in no dhcp-client being installed at all by debootstrap unless the
> override bug also requests bumping dhcpcd-base's priority from optional
> to important.
Not complety true. deboot
On 2023-06-07 Paul Wise wrote:
[...]
> There was another option mentioned earlier in the thread that could
> help resolve some aspects of these conflicts; make 32-bit arches
> (or just i386) support both time_t ABIs, like glibc and Linux do.
> The 64-bit time_t ABI would be the default but the 32
On 2023-05-20 Wookey wrote:
> On 2023-05-17 20:14 -0500, Richard Laager wrote:
>> They mention, "We likely have to complete Modern C porting first to remove
>> any instances of -Wimplicit-function-declaration otherwise the redirects in
>> glibc for e.g. time->time64 won't actually work."
>> Has t
On 2023-05-12 Ansgar wrote:
[...]
> The core issue as I see it is as follows:
[...]
> Do you think this summary of the issue is right?
I think Simon's reading of the situation as posted in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035904#30
makes a lot of sense.
cu Andreas
--
`What a g
On 2023-05-05 Simon Richter wrote:
[...]
> My proposal would be to put the onus on the client registering the
> diversion:
[...]
> - packages are encouraged to register both diversions
Hello,
That seems to be a rather ugly user interface, ("There is dpkg-divert on
Debian, but because the usrmer
On 2023-01-18 Jérémy Lal wrote:
> I just keep on removing apache2 on my system, and find it bad that some
> updates will reinstall it.
> It seems to be coming from dependencies on "apache2 | httpd-cgi" which
> favors the former (I have some httpd-cgi installed, just not apache2).
> Is it okay to o
On 2023-01-18 Otto Kekäläinen wrote:
> Lintian just started erroring on 'depends-on-obsolete-package
> lsb-base' on many of my packages yesterday. There are no new uploads
[...]
> Does somebody know what is going on?
> Example:
> E: mariadb-server: depends-on-obsolete-package Depends: lsb-base (>
On 2023-01-10 Sam Hartman wrote:
> > "Graham" == Graham Inggs writes:
> Graham> Hi All
> Graham> On Fri, 6 Jan 2023 at 00:33, Bastian Blank
> wrote:
> Graham> Would it be a bad thing to require all uploads that need to
> Graham> go through NEW (source and binary) to target e
On 2023-01-04 Markus Blatt wrote:
> Dear Anton,
> Am Wed, Jan 04, 2023 at 06:24:38AM +0100 schrieb Anton Gladky:
> > I am pleased to announce that the latest version of Boost, version
> > 1.81, is now available in Debian Testing [1].
> Thanks a lot.
>> We encourage all contributors whose packag
On 2022-12-16 Santiago Vila wrote:
> Greetings.
> I'm doing archive-wide rebuilds again.
> I've just filed 21 bugs with subject "Missing build-depends on tzdata"
> in bookworm (as tzdata is not build-essential).
> This is of course not fun for the maintainers, but it's also not fun
> for people
Gioele Barabucci wrote:
> On 05/12/22 18:19, Andreas Metzler wrote:
>> how do you avoid that people who still have got the transitional docker
>> (--> wmdocker) package installed end up being upgraded to real docker
>> (from docker.io)?
> How was the transition from
On 2022-12-09 Andreas Tille wrote:
[...]
> Thanks to Alexander Sulfrian who pointed out the Git repository
> featuring old tags that were obviously taken over from SVN I was proven
> wrong with the statement that there is no configure.ac any more.
> Unfortunately this is no simple drop-in with mo
On 2022-12-04 Hideki Yamane wrote:
> Hi,
> I'd like to propose wmdocker package would rename its source package
> from docker to wmdocker, and then docker.io package provides docker
> binary package and transitional docker.io package.
> Most of users who is not Debian expert still confusing
On 2022-11-14 Guerkan Myczko wrote:
> I would like to use Pre-Depends in the cadabra2 packge so it'll not break
> the jupyterhub notebook. It gets broken due to the package python3-notebook
> creating a symlink for the codemirror at
> /usr/lib/python3/dist-packages/notebook/static/components
> Now
you! Attached is a dd-list of those packages listed in the "Failures
> only" page in case somebody wants to have a quick glance whether their package
> is affected.
> Thanks!
> cheers, josch
[...]
> Andreas Metzler
>enblend-enfuse (U)
Works for me. - It is
On 2022-09-15 Scott Talbert wrote:
> On Thu, 15 Sep 2022, Andreas Metzler wrote:
[...]
> > A successful build is no guarantee for a working packaging though. e.g.
> > hugin errs out immediately when built with the newer wxWidgets.
> That is certainly true - and probably anot
On 2022-09-13 Scott Talbert wrote:
> Hi,
> wxWidgets 3.2 (a new API/ABI stable release) has been released a few months
> ago and is now packaged in unstable as wxwidgets3.2. Upstream has stopped
> supporting wxWidgets 3.0, so the Debian wx team would like to migrate all wx
> package users to wxw
On 2022-09-14 Paul Wise wrote:
> On Wed, 2022-09-14 at 07:41 +0200, Andreas Metzler wrote:
>> Is there a way to find all packages built against broken dh-fortran-
>> mod so all affected packages can be rebuilt?
> I am not sure of the correct regex, but the binary package contr
Package: libopenmpi-dev
Version: 4.1.4-2
Severity: serious
Hello,
it seems to be impossible to uninstall libopenmpi-dev:
(sid)root@argenau:/# dpkg --purge libopenmpi-dev
(Reading database ... 25167 files and directories currently installed.)
Removing libopenmpi-dev:amd64 (4.1.4-2) ...
rmdir: fail
On 2022-03-12 Hideki Yamane wrote:
> Is there any suggestion or guideline for pacakges that contain
> both systemd-timer unit setting and cronjob? Don't they conflict
> or not
Hello,
You want to skip running the cronjob on systems with systemd as init
systems. e.g. exim's daily cronjob works
On 2022-02-27 Adam Borowski wrote:
> On Sun, Feb 27, 2022 at 01:40:48AM +0100, Ben Hutchings wrote:
[...]
>> This should use "command -v", not which, I think?
> No, and the recent debacle revealed enough reasons that I'm pondering a MBF
> to change that _back_ in packages which followed the bad a
On 2022-02-24 Osamu Aoki wrote:
> I favor moving away from pre-dh7 packages and I support people pushing for
> it. But I
> am in intriguing situation with this effort. Can someone help me.
> At: https://udd.debian.org/cgi-bin/autoremovals.cgi
> I see:
> Osamu Aoki
>debian-history: buggy
On 2022-01-23 Thomas Dickey wrote:
> From: Richard Laager
>> On 1/23/22 10:04, Thomas Dickey wrote:
[...]
>> I see no other way to correct this but to add an epoch.
> agreed. Is there some way to further improve the transition?
>> As we see in this case, switching from version numbers to date-
On 2021-10-12 YaNing Lu wrote:
> Package: wnpp
> Severity: wishlist
> X-Debbugs-Cc: debian-devel@lists.debian.org
> * Package name: android-file-transfer-linux
> Version : 4.2.0
> Upstream Author : Vladimir
> * URL : https://github.com/whoozle/android-file-transfer-l
On 2021-09-14 John Paul Adrian Glaubitz wrote:
> I'm currently working on packaging KIWI [1] for Debian where I need to
> exclude on of the binaries from being installed into /usr/bin.
> I tried using "dh_install -Xkiwicompat" [2] but that doesn't work no
> matter what variation I'm trying, the b
On 2021-08-25 Niels Thykier wrote:
[...]
> As I understand it, the "have usrmerge package patch the dpkg database"
> approach will only work if we ensure that each and every package stop
> using / in bookworm+1.
Hello,
you missed the second part of the "plan". Editing dpkg database syncs
the db
On 2021-08-26 Timo Röhling wrote:
[...]
> However, Guillem also seems to think that dpkg can manage file
> symlinks in a real directory better than an directory symlinks in /,
> which is why he proposed symlink farms in the first place.
Hello,
Afaiui, the symlink farm would just work from dpkg's
On 2021-08-22 Guillem Jover wrote:
[...]
> The huge majority of files under /lib* (which is the actual bulk of them)
> should require no symlink farms. Many of the ones under /bin and /sbin
> (we are talking about around 240 packages here) might be switchable w/o
> compat symlinks after careful co
On 2021-07-27 Simon Josefsson wrote:
> Hi! I'm now resuming work on the libidn shared library transition, and
> I'm ready for the upload to experimental. I wanted to ping back here to
[...]
Hello Simon,
thank you, looks good to me.
cu Andreas
On 2021-07-27 Wouter Verhelst wrote:
> On Tue, Jul 27, 2021 at 02:13:33PM +0200, Andreas Metzler wrote:
[...]
>> Afaiu you are suggesting to do somethink like this instead and
>> immediately post bulleye release.
>>
>> pr
On 2021-07-27 Wouter Verhelst wrote:
> On Thu, Jul 22, 2021 at 03:20:05PM +0100, Simon McVittie wrote:
>> On Thu, 22 Jul 2021 at 15:53:32 +0200, Wouter Verhelst wrote:
>>> I've suggested previously that we can easily make it RC for bookworm to
>>> have a file outside a limited set of directories (
On 2021-07-20 Guillem Jover wrote:
> On Mon, 2021-07-19 at 16:41:42 +0200, Johannes Schauer Marin Rodrigues wrote:
>> So what what is actually the roadmap after the bullseye release?
>> What is the way forward? Should I rather file bugs with patches
>> against individual packages to move their fil
On 2021-06-12 Jonathan Carter wrote:
> On 2021/06/11 12:33, Raphael Hertzog wrote:
> > Jonathan explained that it wasn't easy for him due to reading over NNTP
> > and I also think that it's a bad default to have lists where custom
> > filtering is desirable for many.
> Ah, I haven't used NNTP in
On 2021-05-26 Guillem Jover wrote:
> On Tue, 2021-05-25 at 19:43:21 +0200, Andreas Metzler wrote:
[...]
> I'd probably instead make this a versioned Provides, so that the
> transitional package can be removed right away from systems, it does
> not interfere with the transitio
On 2021-05-24 Simon Josefsson wrote:
> Hi! This is for post-bullseye, but I appreciate guidance if anyone has
> time. Shared library version transitions trigger uncertainty in me.
> I want to upload a new upstream libidn release into Debian, but upstream
> has done a shared library transition.
On 2021-05-09 Harald Dunkel wrote:
> https://packages.debian.org/search?keywords=rsnapshot doesn't tell, so
> I wonder what is the recommended way to find out why rsnapshot (or any
> other package) has been dropped from Testing?
> rsnapshot is still in Sid. I found #986709, of course, but this
>
On 2021-04-03 Otto Kekäläinen wrote:
> Hello!
> In MariaDB we have over the years moved files around. A file that was first
> in e.g. mariadb-server-10.3 might have been moved to
> mariadb-server-core-10.3 and some years later to mariadb-client-core-10.5.
> The result is a massive debian/control
On 2021-03-26 Christoph Biedl wrote:
> a few days ago, I ran uscan on a package where I knew there was a new
> upstream version - just to encounter an validation error since the
> keys in debian/upstream/signing-key.asc had expired.
[...]
> Another about 40 distinct keys will expire within the nex
On 2021-03-07 Hideki Yamane wrote:
> X-debbugs-CC: debian-devel@lists.debian.org
> I've tried to remove files that was accidentally containts empty " ",
> comma "," and wildcard "*" via rm_conffile from dpkg-maintscript-helper.
> However, it returns an error like below.
> > dh_installdeb: err
On 2020-11-20 Ansgar wrote:
> I would like to propose to plan to move to support merged-usr-only over
> the following releases. The motivation is bugs like [1] where upstream
> developers just use `/usr/bin/rm` (or other binaries, or user scripts
> using /usr/bin/bash, or ...) unconditionally; th
On 2020-10-09 calumlikesapple...@gmail.com wrote:
> On Thu, 2020-10-08 at 18:45 +0200, Andreas Metzler wrote:
>> I do not get the reason for this change. Surely we do not expect
>> people to manually type
>> open penguin.jpeg
[...]
> I disagree. If you are developing
On 2020-10-07 Charles Plessy wrote:
> Hello everybody, hello Debian freedesktop.org maintainers,
> /bin/open has been kindly freed a couple years ago (#732796) and I would
> like to propose to repurpose it as a standard command for opening files,
> like on Mac OS and NextStep before it.
[...]
He
On 2020-08-29 Raphael Hertzog wrote:
> +URL: https://dep-team.pages.debian.net/deps/dep14/
[...]
| When a package targets any release that is not one of the usual
| development releases (i.e. stable releases or a frozen development
| release), it should be prepared in a branch named with the
In gmane.linux.debian.devel.general Niels Thykier wrote:
[...]
> 3) We followed up with an [update to the proposal] were debhelper would
> optionally expose some of the relevant directories (some by default,
> others on request) with symlinks while still supporting the new
> layout. I
1 - 100 of 673 matches
Mail list logo
