Matthias Urlichs wrote...
> We don't do a GR among our users. We do that among Debian
> members/maintainers/developers/take-your-pick.
>
> Of those, most …
> * are perfectly happy with the TC's decision
> * can live with it
> * are unhappy, but think that to continue discussing this is way worse
Christoph Anton Mitterer wrote...
> 2) No more packages that bypass the package management system and secure
> apt:
> a) There are still several (typically non-free) packages which download
> stuff from the web, install or at least un-tar it somwhere without
> checking any integrity information th
Another thing: Hardening already has been a release goal but there
still are packages around without.
After having seen the proctetion catching a programming bug I think
more importance should be put on that, either by considering all
packages rc-buggy that should be built with hardening wrappers
Paul Gevers wrote...
> Is it just me or am I the only one getting bug reports from bugs that
> don't seem to exist on bugs.debian.org.
Now it's appearently back online, but a web tracking has been
added, as seen in #703298. That's disgusting.
Christoph
--
To UNSUBSCRIBE, email to debian-d
Moritz Muehlenhoff wrote...
> Security archive
> -
>
> * In order to avoid bottlenecks and to open up the security process
> further we're planning to allow maintainers which are not part of
> the security team to release security updates on their own. This
> applies to pac
Matthias Urlichs wrote...
> IMHO the decision to designate release N to be a LTS release has too be
> made at release time of N+1 _at_the_latest_, so maintainers know that they
> may not remove their "old" upgrade script snippets.
Agreed, but given the long intervals between releases: Waiting unt
Didier 'OdyX' Raboud wrote...
> I, for one, have been routinely dropping transitional binary packages
> that were in the latest stable; they were needed to migrate from (the
> releases which are now) oldstable to stable but are only archive noise
> now. Delaying that cleanup for an additional s
Didier 'OdyX' Raboud wrote...
> I was trying to say that there is no policy currently in place to ensure
> that skip-upgrades actually work,
Agreed. If LTS is going to be a permanent thing, this has to
change. For any squeeze-lts to jessie upgrades, the ride might become
a bit bumpy although I s
Moritz Muehlenhoff wrote...
> With the current level of commitment an LTS is unlikely.
Um, not good. Awaiting your announced separate message, then it's time
for those who promised commitment back in last August to prove they
are still interested.
Christoph
--
To UNSUBSCRIBE, email to deb
Moritz Muehlenhoff wrote...
> LTS
> - ---
>
> * Anyone interested in contributing, please get in touch with
> t...@security.debian.org. We'll setup an initial coordination list
> with all interested parties. All policies / exact work will be
> sorted out there.
Ups, I have to admit, it too
Pablo Lorenzzoni wrote...
> How should I proceed?
I suggest not to spend any time on this. Mostly since the old
conquest's upstream[0] isn't dead, unlike stated in #591487. This just
might have changed in the meantime. But now, if ever anyone brings the
old "conquest" back into Debian but you hav
Chow Loong Jin wrote...
> Some references would be helpful. I can't seem to find anything on this
> through
> some cursory googling.
Perl scripts, when installed by ExtUtils::MakeMaker or similar, do
have
| eval 'exec /usr/bin/perl -S $0 ${1+"$@"}'
| if 0; # not running under some shell
i
Dimitri John Ledkov wrote...
> Should we start transition to gnutls28 by default, for all packages
> that are compatible?
Given the fact libgnutls26 has issues like #708174 and cannot handle
SHA-512 signed certificates as issued by CACert¹: Yes, please let's
get rid of that old stuff whereever po
Steve Langasek wrote...
> I don't think systemd integration is in a state today that this is ready to
> become the default.
As long as packages like network-manager depends on systemd and that
dependency causes the init system to be changed accordingly, you can
expect the vast majority of desktop
gregor herrmann wrote...
> Which kind of problems did you see with new Perl versions (I could
> imagine incompatible old third-party software), and is there
> something the Debian perl maintainers and/or the Debian Perl Group
> can do to improve the situation?
At first I was about to say those wh
Paul Wise wrote...
> On Wed, May 14, 2014 at 6:33 AM, Christoph Biedl wrote:
>
> > In 5.18, upstream decided to discourage usage of smart matches and
> > given..when after these have existed since 5.10 (or: more than six
> > years) by marking them as experimental, and
Chris Boot wrote...
> The main problem that I see is that there isn't a built-in mechanism for
> tracking such a situation, as far as I can tell. There aren't any shared
> libraries involved, so I don't have the benefit of sonames, symbols
> files or symbol versioning.
(...)
disclaimer: I might
Santiago Vila wrote...
> Making a great percentage of packages in the archive to be "suddenly"
> buggy is unacceptable.
Nobody would consider making failing r12y "serious" at the current
state where 13 to 17 percent of the packages fail, depending on how
you read the numbers.
> We all want Debia
Package: wnpp
Severity: wishlist
Owner: Christoph Biedl
* Package name: libregexp-wildcards-perl
Version : 1.05
Upstream Author : Vincent Pit
* URL : https://metacpan.org/pod/Regexp::Wildcards
* License : Artistic or GPL-1+
Programming Lang: Perl
Jakub Wilk wrote...
> * Christoph Biedl , 2018-11-03, 12:41:
Thanks for proof-reading. Both issues you've reported are upstream, of
course I'll bring them there.
> > It handles the * and ? jokers,
>
> s/joker/wildcard/ ?
Not sure here. Seems in English "joker"
tl;dr: The file program in unstable is now built with seccomp support
enabled, expect breakage in some rather uncommon use cases.
Hello,
Upstream of the file package added seccomp support a while ago, and
probably everyone with even a small concern about security will agree
the file program, ofte
Paul Gevers wrote...
> Hi Christoph,
>
> On 19-07-2019 17:18, Christoph Biedl wrote:
> > tl;dr: The file program in unstable is now built with seccomp support
> > enabled, expect breakage in some rather uncommon use cases.
>
> This probably warrants an entry in
Russ Allbery wrote...
> Christoph Biedl writes:
>
> > tl;dr: The file program in unstable is now built with seccomp support
> > enabled, expect breakage in some rather uncommon use cases.
>
> Thank you very much for doing this! Here's hoping this sets a trend. It
&
Christoph Biedl wrote...
> tl;dr: The file program in unstable is now built with seccomp support
> enabled, expect breakage in some rather uncommon use cases.
Several issues popped up in the last days as a result of that change,
and in spite of some band-aiding to current implementat
Vincas Dargis wrote...
> On 2019-07-26 18:59, Christoph Biedl wrote:
> > > tl;dr: The file program in unstable is now built with seccomp support
> > > enabled, expect breakage in some rather uncommon use cases.
>
> Interesting, what are these uncommon use cases? Maybe
Philipp Kern wrote...
> That being said: It feels like if you face this situation, you could also
> fork off a binary with a clean environment (i.e. without LD_PRELOAD) and
> minimal dependencies and only protect that with seccomp. Of course you lose
> the integration point of LD_PRELOAD that othe
Philipp Kern wrote...
> On 2019-07-27 10:01, Vincent Bernat wrote:
> > I am upstream for a project using seccomp since a long time and I have
> > never been comfortable to enable it in Debian for this reason. However,
> > they enable it in Gentoo and I get the occasional patches to update the
> >
Steve Langasek wrote...
> I don't have any inkling how widespread this problem will be nor do I see
> any path towards automatically detecting such issues (a codesearch on time_t
> would return far too many false-positives to be useful).
While I doubt there is a perfect way to auto-detect this, I
Thorsten Alteholz wrote...
> Maybe this is a good opportunity to get rid of some old legacy stuff. Is
> there anybody or do you know anybody who is using the old BSD lpr/lpd
> stuff?
Well, not me. But the thing that puzzles me is the popcon numbers:
lpr has 755, lprng 233.
Assuming most of these
Stephan Verbücheln wrote...
> If you want to open that debate (again?), one should probably switch to
> lzip. It uses the same LZMA compression like xz, but has a way more
> sane file format.
Besides the fact dpkg already has zstd support while lzip is missing, so
that was a way bigger changes: I
Kurva Prashanth wrote...
> * Package name: control
> Version : 0.9.4
> Upstream Author : >
> * URL : http://python-control.org/
While I cannot judge whether this package is a sensible addition to
Debian - I strongly ask you to re-consider the package name as "control"
Russ Allbery wrote...
> Since I wrote my original message, I noticed that rlpr is orphaned.
If only rlpr were the only one :-|
When looking into the reverse dependencies of lpr/lprng at the beginning
of this thread, I found several orphaned packages, some for already for
more than ten years. To
Daniel Kahn Gillmor wrote...
(...)
Thanks for your exhaustive description. I'd just like to point out one
point:
> In practice, i think it makes the most sense to engage with
> well-documented, community-reviewed, interoperably-tested standards, and
> the implementations that try to follow them.
Package: wnpp
Severity: wishlist
Owner: Christoph Biedl
X-Debbugs-Cc: debian-devel@lists.debian.org, debian.a...@manchmal.in-ulm.de
* Package name: tftp-proxy
Version : 1.0.0
Upstream Contact: Arnoud Vermeer
* URL : https://github.com/openfibernet/tftp-proxy
Johannes Schauer Marin Rodrigues wrote...
> speaking of mirroring problematic debian.org services [1] by adding more
> copies
> of terabytes of data [2]: is there an update of the situation regarding
> snapshot.d.o? I do not see any activity in bugs like #1050815 and #1029744.
> And
> bug #10316
Hello,
over all the years I had assumed the -x and -b operations of dpkg-source
are inverse, and the other way around as well. In other words, I
expected to rely on the following:
Running "dpkg-source -x" on a .dsc, and then "dpkg-source -b" on
the unpacked tree re-creates the initial .ds
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: nagios-tang
Version : 7
Upstream Author : Nathaniel McCallum
* URL : https://github.com/latchset/nagios-tang/
* License : GPL-3+
Programming Lang: C
Description : A Nagios plugin to check the h
Andreas Metzler wrote...
> I am all for declaring a cutoff date (and release) which makes usrmerge
> mandatory and the only supported setup. (Or alternatively make usrmerge
> an unsupported setup.) The current state where we are trying to support
> both and end up dealing with fallout and cannot m
Hello,
the http-parser library was updated from 2.9.2 to 2.9.4 in unstable and
testing, the only change upstream worth mentioning was implementing a
protection against "request smuggling" in a rather restrictive
understanding of RFC 7320. The issue is also known as CVE-2019-15605.
As a result, ap
Julien Cristau wrote...
> On Tue, Jan 26, 2021 at 04:34:14PM +0100, Stephan Lachnit wrote:
> > * Package name: root
> [...]
> >
> > I want to maintain ROOT in the science team. ROOT was already in Debian as
> > `root-system` [1], but hasn't been updated since 2015.
> > I will probably go with
Hello,
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.
After that, things escalated a little, and eventually I wrote a script
that downloads d/u/s-k for ea
Christoph Biedl wrote...
> PS: Those who want to argue lintian should for check for such expired
> key, I couldn't agree more. Please read the discussion in #985793 first.
Sorry, that should have been #964971.
signature.asc
Description: PGP signature
Russ Allbery wrote...
> I think there's a bit of subtlety here in that if upstream uses a key with
> an expiration that they periodically extend (to provide a time-based
> cut-off if they lose control of the key for whatever reason, for
> instance), and that package is rarely updated because it's
Marc Haber wrote...
> I'd still consider the Raspberry Pi. It's unfortunate that the binary
> non-free blob is already needed to boot the box even if one doesn't
> need/use the GPU after booting, but it is reasonably common that
> people care about their software on the platform, and it's also
> a
Marc Haber wrote...
> On Sat, 5 Jun 2021 10:50:20 +0200, Christoph Biedl
> wrote:
> >For me, the biggest downside of the RPi4 is the need for an extra power
> >plug as they take up to three amps - while for example a BananaPi can be
> >powered using some unused USB (&l
Package: wnpp
Severity: normal
X-Debbugs-Cc: debian-devel@lists.debian.org
Control: affects -1 src:gkrellm-radio
[ Submitter of #440352 in Bcc: ]
Greetings,
in order to keep this package gkrellm-radio in a good shape, I've taken
over maintainership. However, I don't have such a device as an FM
r
Steve McIntyre wrote...
> IMHO there are 2 points to an ITP:
>
> * to save effort in case two people might be working on the same
>package
And having such a lock is a good thing.
> * to invite discussion on debian-devel / elsewhere
Which might include reactions like:
* There is already a
Hello debian-devel,
a new version of schroot (1.6.12-2) will hit unstable in a few hours.
As the only but major change, the rule about allowed characters in a
chroot (or session) name got a lot stricter to avoid some harm that can
be done. If you're using names with various punctation or 8bit
char
Christoph Biedl wrote...
> In the future, names must match the following regular expression:
>
> ^[a-zA-Z0-9][a-zA-Z0-9_.@%+-]*$
Some last-minute inspection revealed [@%+] can *not* be considered safe,
so they'll have to be disallowed as well, at least for the time being.
Hello,
some updates about the Debian Bug Squashing Party in a few weeks:
First, and most important, the event is still about to happen. Please
confirm your attendance in the Wiki page[1], or ping me in IRC. That
page has also all the information about precise times, getting
there, and the like (n
Hello,
these days, I found a package in Debian (four-digit popcon count) that
in an upgrade happily removed some some changes I had made to a
configuration file of that package, in /etc/.
My immediate reaction was to consider this a gross violation of the
Debian Policy (10.7.3 "Behaviour"). Upon
Marc Haber wrote...
> The "split it" approach is something that comes naturally to someone
> who has been heavily socialized in the Debian Universe because we
> handle conffiles on a file level. It feels unnatural and clumsy for
> someone who is not familiar with the deep historic reasons for us t
Heya,
perhaps it this happens more often that one might think: Huge changes
come in silence and small steps, and it takes a while to realize
something big is happening. And it seems we're just witnessing another
story of that kind.
It's about the naming of Debian packages, more precisely: about m
Niko Tyni wrote...
> somewhat recently new official buildds were added with IPv6-only
> connectivity. I'm not aware of an announcement, but I noticed this
> with #962019, where src:perl suddenly failed to build due to test suite
> failures.
Thanks for catching this - I had seen one of my packages
Martin Bammer wrote...
> I've got an issue with the generation of UIDs and GIDs when new
> users are added. By default UIDs and GIDs for users and user groups
> are values starting from 1000 (on Red Hat from 500). When a user is
> added the next free value is chosen.
Yes, also NFS has a problem h
Christoph Biedl wrote...
> So I patched adduser to determine the user (also: group) ID from a
> static "acount name"<->"ID" mapping. It's in the BTS somewhere eight
> years ago,
FTR: #243929
signature.asc
Description: Digital signature
Vincent Bernat wrote...
> One of the package that I maintain (python-asyncssh) makes a DNS request
> during build and expects it to fail. Since Policy 4.9 forbids network
> access (in a rather confusing wording "may not"), I got this serious
> bug:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?
John Paul Adrian Glaubitz wrote...
> On 09/20/2016 11:16 PM, Niels Thykier wrote:
> >- powerpc: No porter (RM blocker)
>
> I'd be happy to pick up powerpc to keep it for Stretch. I'm already
> maintaining powerpcspe which is very similar to powerpc.
For somewhat personal reasons I'm interest
Ian Jackson wrote...
> There's still big spikes in work for our core teams around deadlines,
> so it's still best if people sort their stuff out earlier, but the new
> arrangements are a big improvement IMO.
ACK, and also looking at the way removals were handled in the past
months (Like long grac
Ian Jackson wrote...
> I think what is really worrying people is the fear that they might
> miss something, for good reasons, and then find that their work that
> they care about is thrown out of stretch.
>
> It is difficult to address this fear with logical arguments intended
> to demonstrate tha
Hello,
it is the nature of an arch:all binary package it can be installed on
any architecture regardless on which architecture it has been build.
Given this I deduced I'm at liberty on which architecture I'd want to
rebuild such a package, but I saw disagreement. So I'm asking for
clarification:
Henrique de Moraes Holschuh wrote...
> There are some relevant issues, here.
>
> 1. It does protect against passive snooping *from non-skilled
> attackers*.
Well, yes, no. The tools become better so thinking a few years into
the future sophisticated programs for that purpose might be available t
Nikolaus Rath wrote...
> Just fix it in "bar", and don't bother worrying about the right
> severity?
If it was that simple ... The maintainers of "bar" haven't reacted to
the bug report for a few months although it contains a clear statement
the current state breaks the build of other packages. A
Paul Wise wrote...
> On Fri, Nov 11, 2016 at 7:32 AM, Christoph Biedl wrote:
>
> > Other suggestions?
>
> Include information about which packages/issues you are talking about.
How would this affect your assesment of the situation?
In my feeling, revealing the pakages
Colin Watson wrote...
> On Thu, Nov 10, 2016 at 08:52:15PM -0800, Nikolaus Rath wrote:
> > That's a good theoretical argument. But in practice, I think the subset
> > of architectures for which bar works correctly will always include
> > amd64, and John D. Rebuilder will have access to such a box
Marc Haber wrote...
> This is exactly the problem I have with the current policy: I fail to
> see why this measure will shorten the freeze.
I don't. But I'd say we'll just watch what's going to happen and resume
this discussion once stretch is released.
Chri- "somewhen December 2017" stoph
Hello,
two days ago, syslog-ng 3.8.1-5 migrated to testing. However, as this
package build-depends on libssl1.0-dev which is available in unstable
only at the moment, it cannot be rebuild in testing.
Please note my only interested in understanding this from a general
point, not about the particul
Adam D. Barratt wrote...
> britney has never considered build-dependencies (that's #145257). This
> is one of several reasons for periodic rebuilds of testing.
Oy. While this is rather unfortunate, I bet there's a reason why
this never got fixed in all the years.
Thanks for sharing the wisdom of
Emilio Pozuelo Monfort wrote...
> I would suggest to come up with some algorithm to determine if a package is
> effectively unmaintained, and implement it in an automatic way that gives
> maintainers prior notice and a chance to react, like we do with auto-removals.
> Then if nothing happens in a
Michael Meskes wrote...
> Sure, but then it would be nice if you'd tried finding out if nobody
> cares. As usual the real world is neither white not black, but some
> shade of gray. The problem with the package is that the new version
> does not build on my system but I lack the time to debug, cou
Adam Borowski wrote...
> I see two problems in that code:
> * it's Launchpad-specific
> * it supports only a single build-indep architecture rather than a list
Um, yes, perhaps, no. The important thing to me is there's already
something around that solves a problem I have. Of course this header
s
Roger Shimizu wrote...
> I'm ARM porter on armel/marvell (orion5x/kirkwood).
> Stretch will be frozen and released soon, which makes me bit depressed,
> because it means armel will be dropped out of unstable/testing as the
> conclusion of Cape Town BoF.
Same here. My Dockstars (orion5x/kirkwood
har...@a-little-linux-box.at wrote...
> While it would theoretically also be possible to file a RFA or O bug I
> currently do not consider this a good course of action: The number of QA
> packages is already very high and while adopting amavisd-milter would be
> not so much of a problem to maintai
Paul Wise wrote...
> On Fri, Dec 9, 2016 at 8:53 AM, Ben Hutchings wrote:
>
> > Also, dedicated tiny flash partitions for the kernel and initrd. I
> > wouldn't be surprised to be find that by the time we want to release
> > buster we can't build a useful kernel that fits into the 2 MB partition
W. Martin Borgert wrote...
> Quoting Ben Hutchings :
> >Also, dedicated tiny flash partitions for the kernel and initrd. I
> >wouldn't be surprised to be find that by the time we want to release
> >buster we can't build a useful kernel that fits into the 2 MB partition
> >that most of these devic
W. Martin Borgert wrote...
> The forementioned hardware needs < 0.5 W, the manufacturer even
> claims 0.18 W. AFAIK, most newer ARM boards that are capable to
> run Debian need more energy or am I wrong?
So let me play the devil's advocate another time: My Dockstar runs
24/7 and allegedly consume
Lennart Sorensen wrote...
> I actually highly doubt there are that many armv7 boxes running armel.
> armhf was a nice performance improvement and worth the hassle to reinstall
> if you had such a box in the first place. I think most armel systems
> are probably armv5, often the marvell chips. No
[ limiting to devel- ]
Wouter Verhelst wrote...
> I think a proper procedure should involve a script that:
[ sane criteria ]
> We currently don't have anything remotely like the above, and I think we
> should.
Yes, but I doubt it would be used a lot. There's a wide-spread culture
of re-install
Package: wnpp
Severity: wishlist
Owner: Christoph Biedl
* Package name: auto-resize-image
Version : 0.14.3-tb
Upstream Author : TrVTrV
<https://addons.mozilla.org/en-US/thunderbird/user/trvtrv/>
* URL :
https://addons.mozilla.org/en-US/thunderbird/addon/auto-
Emilio Pozuelo Monfort wrote...
> Unforunately, the BTS exported a broken/incomplete RC bug list, and britney
> used
> that and didn't see that some packages had an RC bug, so it allowed them to
> migrate.
Ouch, that's quite a nightmare. While I'm curious to learn how this
happened and what is
Eduard Bloch wrote...
> I volunteer as test subject for that experiment. I would appreciate even
> small steps, considering the current laptop in front of me with average
> magnetic HDD. Over a minute boot time, which is insane and IMHO mostly
> caused by the storm of IO operations required nowada
Package: wnpp
Severity: wishlist
Owner: Christoph Biedl
* Package name: ykush-control
Version : 1.0.0
Upstream Author : 2015-2016 Yepkit Lda
* URL : https://github.com/Yepkit/ykush
* License : MIT
Programming Lang: C++
Description : control application
Guillem Jover wrote...
> On Sun, 2017-01-01 at 10:47:59 -0800, Nikolaus Rath wrote:
> > TBH this feels like you're sniping at Raphael here, which I think is
> > pretty sad and inappropriate.
Well, bringing up more old stories, even if 'The secret plan behind
the "3.0 (quilt)" Debian source' was
Vincent Bernat wrote...
> For me, this is a great improvement over the previous format with
> several different patching systems (quilt, dpatch, nothing,
> custom). Now, most packages are using quilt, one less thing to
> understand.
That's for sure, and I doubt there are many people who consider
Christian Seiler wrote...
> tl;dr: I don't think compression modules will increase boot times
> on HDDs in any significant manner, but it may be a good idea to
> support that just to reduce the amount of space required on disk.
Well, sometimes I remember I was shocked to learn in the MBR partitio
Hi there,
as the stretch freeze approaches, I'm getting concerned about the
status of logrotate, most notably #734688. The maintainer (CC'ed)
hasn't shown any sign of activity for a while, also no response to a
private message (I admit, it's been just a few days).
Since the fix includes switching
Matthias Klose wrote...
> fyi, I NMUed logrotate yesterday to fix #849743, currently in delayed. Please
> add this fix to your upload.
Thanks for the heads-up, included in ~exp2 I had to do for other
reasons as well.
Christoph
signature.asc
Description: Digital signature
Aldrin P. S. Castro wrote...
> I would very much like the Universal Media Server to be in the Debian
> repositories.
> He is a very good dlna server. It is done in Java.
Unfortunately, by mailing debian-devel your suggestion will very likely
not reach the people who might be willing to do the job
# TL;DR
* The python-magic Python library for file type detection will switch
to a different implementation soon.
* Code that relies on the old implementation should not be harmed,
everything else is a bug.
* Such code however might need an adjustment some distant day, not
before the buste
Andrej Shadura wrote...
> It has happened to me in the recent years quite a few times that a
> package which I was using has a RoQA bug filed against it, and the
> package's got removed at a very short notice.
+1
You meant "RM"? Let me extend this to package removals in general since
I'm not to
Jeremy Bicha wrote...
> On Wed, Jan 31, 2018 at 3:03 PM, Christoph Biedl
> wrote:
> > Or for example the xmem removal (#733668):
>
> 4 years ago.
So?
> > And also give it some time, I'd suggest some two to four weeks.
>
> I don't think we need to add
Adam Borowski wrote...
> Thus, I'd like to propose a new kind of wnpp bug: "Intent To Remove".
Sounds like a very good idea. For me, I could automatically parse these
and check against the list of packages installed on my systems, or are
used to build packages (thanks for .buildinfo files) outsid
Thomas Goirand wrote...
> We already have RFA, where maintainers are asking for adoption. I fail
> to see how a different type of bug will trigger a quicker adoption. An
> ITR is going to (unfortunately) achieve the exact same thing as an RFA,
> which in most cases is ... no much.
I disagree. The
Paul Wise wrote...
> It might be a good idea to do these:
>
> Try to rebuild any packages that build-dep on python{,3}-magic and
> compare the resulting binary packages with diffoscope.
Thanks for this suggestion. Turns out one package will indeed fail to
build, fix was trivial. (alot, #889293)
Package: wnpp
Severity: wishlist
Owner: Christoph Biedl
* Package name: libdigest-ssdeep-perl
Version : 0.9.3
Upstream Author : Reinoso Guzman
* URL : https://metacpan.org/pod/Digest::ssdeep
* License : Artistic or GPL-1+
Programming Lang: Perl
Package: wnpp
Severity: wishlist
Owner: Christoph Biedl
* Package name: libtext-wagnerfischer-perl
Version : 0.04
Upstream Author : Dree Mistrut
* URL : https://metacpan.org/release/Text-WagnerFischer
* License : Artistic or GPL-1+
Programming Lang: Perl
e data at hand, I figured it would be
> easy to generate a dd-list of packages named after their module that
> lack the tag. You find that list attached.
> Christoph Biedl
>file
The src:file package doesn't ship python{,3}-magic any longer, the
change was two months ago.
Emilio Pozuelo Monfort wrote...
> We are about halfway through the buster development cycle, and a release
> update was overdue.
Thanks for all the updates, let's make this an exiting ride.
But briefly bleating by boldly bringing balking bits ...
> Future codenames
>
So we'll
Mathias Behrle wrote...
> Big thanks to all involved also from my side, it is great to have the mailing
> lists seamlessly running!
Seconded.
A few questions, though (asking for a friend, of course). It might have
been mentioned before but I have missed it then.
What is the long-term plan for
Holger Levsen wrote...
> please file bugs, so that autoremovals can kick in. Thanks.
Sheesh, it's not about removing package but keeping them. By making sure
they are in good shape which, among many other things, means there is a
working well-defined maintainer contact address.
1 - 100 of 134 matches
Mail list logo
