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
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
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.
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
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"
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
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
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
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
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
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
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
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 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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
> >
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
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
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
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
&
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
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
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"
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
Michael Biebl wrote...
> Am 24.09.18 um 16:24 schrieb Sean Whitton:
>
> > Aurélien can use his judgement, but I'd advise against this -- it has
> > the potential to make upstream less happy about their software being
> > included in Debian.
>
> I don't understand. Can you elaborate why you think m
peter green wrote...
> Nearly 3 months ago there was a mass bug filing on packages with dead
> alioth lists as maintainer. Many of these bugs are still open with no
> maintainer response
Yeah, but also a lot of people have already reacted. I got a lot of
e-mails sent to -close lately ...
> (note
Emilio Pozuelo Monfort wrote...
> On 05/05/18 17:34, Christoph Biedl wrote:
> > A lot of now defunct alioth addresses are used in the Maintainer:
> > field. This makes the packages rc-buggy for an invalid address.
>
> Before doing the MBF, can you send an email with all th
Dominic Hargreaves wrote...
> Thanks for doing this detailed work - which is very timely and important
> to ensure that communication paths within Debian remain open.
Yeah, unfortunately other things have been blocking my spare spare time
so this took *much* longer than wished. But here we go ...
Some now defunct alioth addresses are used in the Uploaders: field.
This is not explicitly forbidden by policy but certainly something that
should be addressed.
To create awareness about that issue, also to provide suggestions on
how to resolve this I intend to do a MBF using the following message
A lot of now defunct alioth addresses are used in the Maintainer:
field. This makes the packages rc-buggy for an invalid address.
To create awareness about that issue, also to provide suggestions on
how to resolve this I intend to do a MBF using the following message:
Hello everybody,
as discussed more than two weeks ago (time passes too fast), I intend
to do a mass bug filing (MBF) against packages that use any of those
alioth list addresses in debian/control that were *not* migrated to the
alioth-lists service, and hence are now invalid.
Statistic bit: Of 10
Raphael Hertzog wrote...
> Packages maintained by forensics-devel@ and pkg-security-team@ all
> have a fixed maintainer email in git. I was not planning on doing any mass
> upload right now and I would be really annoyed to have to hand-edit all
> changelog entries to add a bug closure.
Debian pol
Philipp Kern wrote...
> Turns out that this is a terrible idea.
Because?
> We should use numeric values for
> sorting. (And Ubuntu now does the same thing on the technical side.)
From a technical point of view there is no need for codenames at all.
But being human I prefer names over numbers, e
Christoph Biedl wrote...
> Also, @lists.alioth.debian.org addresses that were *not* migrated now
> result in bounces as expected. Are there already plans for a MBF
> severity RC against all packages with a now-failing maintainer address?
Following the rule a social ecosystem can wor
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.
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
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
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.
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
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
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)
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
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
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
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
# 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
W. Martin Borgert wrote...
> I'm not sure, whether missing SysV support is wishlist, minor,
> or normal. I would accept normal, but some maintainers would
> downgrade severity.
In my understanding of "universal" (Debian, operating system, y'know)
the goal should be to run on as many platforms as
Emilio Pozuelo Monfort wrote...
> One thing with compat 10 that doesn't make a lot of sense to me is how
> dh_missing is enabled by default but a no-op. It'd make more sense to me to
> change that in compat 11 to be enabled by default and run with --list-missing
> (--fail-missing is probably too m
Adam Borowski wrote...
> On Fri, Oct 20, 2017 at 11:42:04AM -0400, Jeremy Bicha wrote:
> > On Fri, Oct 20, 2017 at 10:59 AM, W. Martin Borgert
> > wrote:
> > > I would package the new dino under this name, because I don't think
> > > there is a conflict.
> >
> > It is a problem for Ubuntu unles
Package: wnpp
Severity: wishlist
Owner: Christoph Biedl
* Package name: python-magic
Version : 0.4.13
Upstream Author : Adam Hupp
* URL : https://github.com/ahupp/python-magic/
* License : MIT
Programming Lang: Python
Description : A python wrapper
Package: wnpp
Severity: wishlist
Owner: Christoph Biedl
* Package name: libluksmeta
Version : 7
Upstream Author : Nathaniel McCallum https://github.com/npmccallum
* URL : https://github.com/latchset/luksmeta
* License : LGPL-2.1+
Programming Lang: C
Package: wnpp
Severity: wishlist
Owner: Christoph Biedl
* Package name: libjose
Version : 9
Upstream Author : Nathaniel McCallum https://github.com/npmccallum
* URL : https://github.com/latchset/jose
* License : Apache-2.0
Programming Lang: C
Description
intrigeri wrote...
> tl;dr: I hereby propose we enable AppArmor by default in testing/sid,
> and decide one year later if we want to keep it this way in the
> Buster release.
I really appreciate your approach of trying this out while being
prepared this might turn out to be a bad idea. Or: Promot
Matthias Klumpp wrote...
> So, lzip isn't adopted widely, that's certainly not because of Debian
> or any other Linux distribution.
The war is over, the winner is VHS.
Trying to get lzip support in wider usage is somewhat a boot-up
problem: Few people see an advantage in doing this, so it doesn'
Paul Wise wrote...
> On Thu, Jun 15, 2017 at 9:05 PM, Christoph Biedl wrote:
>
> > I'm not keen on extending regular expressions like
> >
> > \.(gz|bz2|lzma|xz)$
> >
> > that I have in many places again and again.
>
> That sort of hard-coding
Ralf Treinen wrote...
> What is your opinion?
Certainly the right thing to do.
These scripts run as root, that's reaon enough to enforce extra
precautions. I'd consider even stricter modes like set -u, unless ...
Let's be honest: Shell scripts, while easy to write, carry too many
risks of unsaf
Maria Bisen wrote...
> I've got the feeling that the distribution the thread talks about is
> precisely yours, Debian's. As stated there, giving support to lzip in
> Debian seems feasable and easy. Could it be possible, then, to add
> lzip support? : )
If I understand correctly, it's about using
Ben Hutchings wrote...
> > * when using eatmydata
>
> I can certainly think of a test case that would be broken by eatmydata
> and I would not want to rule out such test cases. But still, I am
> suprised by this.
#667965 - don't know whether this still exists. I later decided to patch
dpkg so "
Sean Whitton wrote...
> I'm not sure why you're mentioned powerpc archs
Because that's a surprising feature of that arch and once you've
realized you were caught by this, you will not forget it. Bonus:
Rebuilding on a porter box passes since /home is not a tmpfs.
Christoph
PS:
https://sour
Santiago Vila wrote...
> I fully agree with the underlying idea, however: If we can measure the
> failure rate, then it means it already fails too often to be acceptable.
Cannot deny I somehow like that approach.
> For that to happen, the around 50 packages which FTBFS randomly should
> do so le
Niels Thykier wrote...
[ topic shift ]
> On a related note: Having some way to declare minimum requirements for
> e.g. disk space and memory (a la "base GB usage + GB usage/core") used
> would be great.
> Especially if it is available in metadata, so wanna-build can see
> whether it makes sense
Ian Jackson wrote...
> IMO all of these bugs should be RC. A randomly-reproducible build
> failure with more than negligible probabilty is likely to show up for
> some of Debian's users and downstreams and cause them mysterious
> trouble. It also causes trouble for stalwarts like Santiago, doing
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
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
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
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
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
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
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
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
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
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-
[ 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
1 - 100 of 132 matches
Mail list logo
