On Wed, Dec 26, 2018 at 02:35:19PM +0100, Dominik George wrote:
> >volatile is a very bad name for this because we've used it already for
> >something else.
> Well, I consider it more or less the same basic idea. The old and new ideas
> have more in common than not, with the only difference being
On Wed, Dec 26, 2018 at 12:07:42AM +0100, Dominik George wrote:
> I actually think volatile is a good name. After all, it's not so far from the
> previous volatile.
volatile is a very bad name for this because we've used it already for
something else.
--
cheers,
Holger
---
On Tue, Dec 18, 2018 at 08:38:39PM +0530, Pirate Praveen wrote:
> But if that is not possible, volatile as a separate archive is also fine.
instead of volatile we need PPAs.
--
cheers,
Holger
---
On Tue, Dec 04, 2018 at 01:07:42AM +0100, Guillem Jover wrote:
> These will detect problematic files under /usr/local which can taint
> the current build.
[...]
> +.B usr\-local\-has\-programs
I regularily have stuff in /usr/local/(s)bin/ which does not taint the
system nor my builds, so I think y
On Wed, Nov 28, 2018 at 07:52:08AM +0500, Alexander E. Patrakov wrote:
As long as there is one Debian Developer (or any other person who has the
> right to upload binary packages) who has a merged /usr on his system used
> for building packages, there is a risk of reintroducing the bug through his
On Mon, Nov 26, 2018 at 05:12:34PM +0100, Marco d'Itri wrote:
> So far the worst case of "usrmerge failure" can be fixed by
> deleting/moving some files (that were installed by you) and then running
> the program again. There has never been any case which required
> reinstalling/restoring a syst
package: dwarves
severity: minor
x-debbugs-cc: Domenico Andreoli ,
debian-devel@lists.debian.org
On Sat, Nov 24, 2018 at 03:28:37PM +0100, Domenico Andreoli wrote:
> after some ~7 years of inactivty I've been able to put a new upstream
> release of dwarves together. It's at https://salsa.d.o/de
package: usrmerge
severity: wishlist
x-debbugs-cc: debian-devel@lists.debian.org
On Fri, Nov 23, 2018 at 03:28:37PM +0100, Stephan Seitz wrote:
> > at the moment, the only issues that are known when installing the
> > usrmerge package is when there are different binaries with the same
> > name in
On Thu, Nov 22, 2018 at 10:11:24PM +0100, W. Martin Borgert wrote:
> Reminds me of the long /usr/doc -> /usr/share/doc transition in potato
> times. And we did not even have dh in those days. Sounds good to me!
ITYM s#potato#slink, potato, woody, sarge, etch and lenny#
(Started in 1999 and final
On Thu, Nov 22, 2018 at 01:42:42PM +, Ian Jackson wrote:
> > > Because:
> > > ...
> > thanks! nice summary.
> I replied in my other mail to the things I disagreed with (as is
> traditional) but it occurred to me I ought to send a positive note
> about this:
>
> Thanks for being easy to convinc
On Thu, Nov 22, 2018 at 12:52:48PM +, Ian Jackson wrote:
> Because:
>
> * Discussions about the RC bugs can be more effectively dealt with
>using our existing discussion mechanisms, including primarily the
>Debian BTS. Compared to REJECT mails:
> - Discussions in the BTS are mor
On Wed, Nov 21, 2018 at 08:37:28PM -0700, Sean Whitton wrote:
> What harm are the packages doing sitting in unstable? Distributing them
> does not have much point, but neither does removing them.
the rather few people working on (fully and partly) automated QA have to
spend brain and cpu cycles o
On Wed, Nov 21, 2018 at 12:38:53PM -0800, Russ Allbery wrote:
> But it's not just my opinion that matters. I think we need to decide this
> somehow as a project, whether via the TC or via GR or something, because
> there's a real disagreement here over whether we can or should
> force-upgrade all
On Wed, Nov 21, 2018 at 06:19:49PM +, Holger Levsen wrote:
> On Wed, Nov 21, 2018 at 05:57:40PM +, Dimitri John Ledkov wrote:
> > Before we get there, we should first start autoremoving packages from
> > unstable[...]
> I'm all for it.
also with a 3 month delay (in
On Wed, Nov 21, 2018 at 05:57:40PM +, Dimitri John Ledkov wrote:
> Before we get there, we should first start autoremoving packages from
> unstable, if we consider rc-buggy in unstable to be unacceptable. We
> do have quite a bit of things in unstable, that are neither getting
> fixed, nor gett
On Wed, Nov 21, 2018 at 03:19:33PM +, Ian Jackson wrote:
> Why is any of this a reason for an ftpmaster REJECT ? I still think
> all of this should be handled as bugs (possibly RC bugs) in the BTS
> in the conventional way, after ACCEPT.
because why accept rc-buggy software in the archive (wh
Hi Simon,
On Wed, Nov 21, 2018 at 02:05:42PM +, Simon McVittie wrote:
[...]
> > Another question is, why?
[...]
thank you very much for explaining in detail why usrmerge is sensible
and the right thing to do for Debian, the universal OS.
I'll link your mail on wiki.debian.org/UsrMerge now a
On Tue, Nov 20, 2018 at 04:12:01PM +, Simon McVittie wrote:
> Please use debootstrap --no-merged-usr explicitly if you want to be able
> to exercise the "not merged /usr" code path. I attach an untested patch.
thanks, merged and deployed/. (Plus recreation of 200 pbuilder base.tgz's
triggered
On Tue, Nov 20, 2018 at 02:35:56AM -0500, Chris Lamb wrote:
> > | > … Simon McVittie has actually patched our testing framework to vary
> > | > this and this is now live.
> > | > https://bugs.debian.org/901473#33
> > Are we sure this is fixed?
I think it's broken...
from irc:
< mapreri> I hav
On Fri, Nov 09, 2018 at 05:41:53PM +, Matthew Vernon wrote:
> The particular commit was fine (and had it come as a MR or bug report or
> whatever I'd have had no problem with it at all).
I'm not sure why you are so bothered by it.
Granted, when I first experienced a git push not working afte
On Tue, Nov 06, 2018 at 09:21:32AM -0800, Russ Allbery wrote:
> >> What is non-free? Signing stuff does not change the freeness of the
> >> software.
> > it does introduce https://en.wikipedia.org/wiki/Tivoisation however.
> I'm not sure how us signing our stuff does that.
you are right and I wa
On Tue, Nov 06, 2018 at 11:58:57AM +0100, John Paul Adrian Glaubitz wrote:
> I also bootstrapped the Rust compiler and helped fixing issues on armel,
> mips, mipsel, mips64el. Those are "strange" ports for you? Ok.
no (except armel..)
but as said, you just wrote a mail to d-d-a that rust has been
On Tue, Nov 06, 2018 at 02:43:44AM +0100, John Paul Adrian Glaubitz wrote:
> >> Why would I need to communicate that?
> > Because coordination needs involvement from all
> If the maintainer of a package doesn't understand which reverse
> dependencies his package has, he shouldn't be the maintain
On Tue, Nov 06, 2018 at 10:08:10AM +0100, Bastian Blank wrote:
> On Tue, Nov 06, 2018 at 01:09:50AM +0100, Adam Borowski wrote:
> > But only the stock kernel, which turns it non-free software.
> What is non-free? Signing stuff does not change the freeness of the
> software.
it does introduce http
On Wed, Oct 31, 2018 at 12:04:47PM +0100, Wouter Verhelst wrote:
> When I say "the circumstances were different", I mean that at the time,
> it was about paying people to do release management of testing, and that
> it was originally suggested by the DPL. In this case, it is about
> paying people t
On Sun, Oct 28, 2018 at 04:31:38PM +0100, Wouter Verhelst wrote:
> On Sun, Oct 28, 2018 at 01:14:13AM +, Ben Hutchings wrote:
> > Debian can't afford to pay developers in general, and previous
> > proposals to pay specific developers were not well received.
> That was over a decade ago. The cir
Package: grub-cloud-amd64
Version: 0.0.2
Severity: important
Dear Maintainer,
in your postinst you are trying to detect whether it's being run in a
piuparts test, to workaround #912038 ("grub-cloud-amd64: fails to
install"), which is detected by piuparts but can also be triggered by
anyone instal
On Fri, Oct 26, 2018 at 09:24:17AM -0400, Marvin Renich wrote:
> Using Depends instead of Recommends actually _prevents_ the admin from
> being able to choose.
you know about the equivs package, do you?
--
cheers,
Holger
On Thu, Oct 25, 2018 at 10:45:46AM +0200, Bas Couwenberg wrote:
> Or:
>
> - Leave the bugreport unresolved until libmd-dev (>= 1.0.1) is available in
> stable
>
> My initial suggestion to wait with the MBF until libmd-dev (>= 1.0.1) is
> available in stable is still the best solution in my opinio
On Mon, Oct 22, 2018 at 01:22:12PM -0700, Russ Allbery wrote:
> Personally, I think people in this thread are too worried about trying to
> remove as many packages from their system as possible and not worried
> enough about a straightforward user experience.
yep.
--
cheers,
Holger
---
On Fri, Oct 19, 2018 at 11:35:54AM +0200, Martin Steigerwald wrote:
> A minority? Yes. But a sizable one.
It doesn't matter how many people use it, if noone is willing to maintain
it. *If* people are maintaining it, it also doesnt matter how many people
are using it :)
*Someone* needs to do the
On Wed, Oct 17, 2018 at 11:04:00AM +0200, OndÅ?ej Surý wrote:
> > I know that there is
> > https://deb.sury.org - but prefer to trust stuff that was
> > built on Debian machines and is distributed/signed with a
> > key we trust.
> Shrug, all the packages that I upload to Debian and to the DPA are
On Sat, Oct 13, 2018 at 06:01:43AM +0100, Ben Hutchings wrote:
> > Has policy changed regarding support for multiple inits, or is it just that
> > no one is maintaining the shim and sysvinit-core?
>
> The latter. systemd-shim has been orphaned for over 2 years, and has
> RC bugs. sysvinit curre
On Mon, Oct 01, 2018 at 09:59:59AM +0200, Alex Muntada wrote:
> > As I understand it, alioth-lists.d.n is an interim location
> This is correct, when asked what to do we're encouraging people
> to keep the former lists.alioth.d.o addresses.
I find this quite confusing, because this way its not cl
On Thu, Sep 27, 2018 at 10:50:51PM +0200, gregor herrmann wrote:
> > Yes. Precisely because there is collaboration between both sides on those
> > packages.
> [..]
>
> I agree.
>
> While epochs are nasty and ,
> having this one more doesn't really hurt anyone and makes a
> maintainer's life easi
On Mon, Sep 24, 2018 at 07:19:57PM +0200, Christoph Biedl wrote:
> For me this concern is about asking upstream for a change that is caused
> by something more or less Debian-internal - although other distributions
> might have that issue as well. So it should rather be handled inside
> Debian.
Ar
On Mon, Sep 24, 2018 at 09:24:05PM +0500, Andrey Rahmatullin wrote:
> On Mon, Sep 24, 2018 at 09:21:14AM -0700, Russ Allbery wrote:
> > This causes a ton of headaches for the archive software. IIRC, I believe
> > dak is rather unhappy about version numbers going backwards
> This is unfortunate.
a
On Thu, Sep 13, 2018 at 08:56:22AM -0700, Russ Allbery wrote:
> > - A large part of the changelog is listing the changes in upstream
> > stable updates. [...]
> For the record, I've found these curated summaries of the upstream changes
> *incredibly* helpful more times than I can count. So I'd lov
On Thu, Sep 13, 2018 at 01:46:34PM +0300, Lars Wirzenius wrote:
> I was curious, so I ran the following on my laptop:
[finding 22M of changelogs]
I was curious too, so I ran "du -sch /usr/share/doc" and found that in
this VM thats 150M of a 3.5G system. But then I have ~15 such
installations on my
On Fri, Jul 27, 2018 at 03:23:08PM +0200, Philipp Kern wrote:
> Yup, but to note: Consensus-driven arguments can only go so far and scale
> poorly with more people. Ultimately contentious issues need to be voted on,
> otherwise you can be held hostage by a single person or small vocal group.
peopl
On Sun, Jul 15, 2018 at 12:41:36PM +0200, Carsten Schoenert wrote:
> Hmm, do you have tried to validate your shell code?
> https://www.shellcheck.net/
> I just pasted
> https://raw.githubusercontent.com/dashohoxha/pw/master/src/pw.sh into
> and got quite a lot of problematic remarks.
I've also don
On Mon, Jul 16, 2018 at 05:56:39AM +0200, Dashamir Hoxha wrote:
> I just uploaded it: https://mentors.debian.net/package/pw
> Please review and sponsor it.
please *dont* sponsor this until Dashamir has addressed the concerns
pointed out in
https://lists.debian.org/msgid-search/aa2d4d3d-41d2-5399-2
On Thu, Jul 12, 2018 at 02:16:01PM +0100, Ian Campbell wrote:
> > so what? Debian runs on non-free CPUs too, how is this any different?
> AIUI there is a pile of non-free libraries/tools on the host side too,
thanks for this clarification!
--
cheers,
Holger
signature.asc
Description:
On Thu, Jul 12, 2018 at 12:35:24PM +, Lumin wrote:
> (3) CUDA Deep Neural Network library (cuDNN)[4] is NVIDIA's **PROPRIETARY**,
> stacked on CUDA, and requires NVIDIA GPU exclusively.
so what? Debian runs on non-free CPUs too, how is this any different?
(and yes, I'd be happy to learn
On Mon, Jul 09, 2018 at 08:34:54PM +0200, Mattia Rizzolo wrote:
> I agree. I haven't been mad about it only because it affects i386 only,
> and we have 3 other architectures,
I agree too.
> but we'll need to figure a workaround
> soon.
and/or exclude these results from showing up on tracker.d.
On Mon, Jul 09, 2018 at 07:02:00PM +0200, Innocent De Marchi wrote:
> Recently, ALL the packages that I maintain based on Qt, have problems
> of reproducibility on build on i386.
>
> The message is always the same:
> /usr/lib/qt5/bin/uic: error while loading shared libraries:
> libQt5Core.so.5: c
On Thu, Jun 07, 2018 at 06:26:56PM +0300, Tommi Höynälänmaa wrote:
> Which Standards-Version and compat level should I use in the Debian packages
> I publish?
try running lintian from sid on your .changes file :)
spoiler: 4.1.4 and 11.
--
cheers,
Holger
signature.asc
Description: PGP
On Sat, Jun 02, 2018 at 10:36:58AM +0200, Emilio Pozuelo Monfort wrote:
> On 01-06-18 16:32, Chris Lamb wrote:
> > … wouldn't we just binNMU these?
> There are many packages in your list that are arch:all only, and those can't
> be
> binNMU'ed. Still I'm not sure we can do some several thousand bi
Hi Paul,
On Fri, Jun 01, 2018 at 08:17:48PM +0200, Paul Gevers wrote:
> It helps to spot things. I notice:
>siridb-connector (U)
> which wasn't even in Debian until February this year. Your original list
February 2018 even, ouch
> says:
> siridb-connector needs rebuild (no .buildinfo)
>
> S
Hi Chris,
On Fri, Jun 01, 2018 at 10:40:18AM +0100, Chris Lamb wrote:
> > I think this should be relatively easy to compute:
> Indeed — 9182/33705 packages need a rebuild in sid.
> (Full output of following script attached.)
hehe, very nice.
Just the numbers strike me as odd: we currently have
Hi,
On Thu, May 31, 2018 at 05:33:10PM +0200, Guillem Jover wrote:
> > We have the "upload_history" relation but that will only give us an
> > upper limit (roughly 50% of the archive).
>
> I think this should be relatively easy to compute:
yes, that's the easy part, once you have the data :)
>
hi,
at the MiniDebConf 2018 in Hamburg we listed a few issues in Debian with
regards to making Debian Buster reproducible in practice. (*)
One issue we forgot to mention there is that all binary packages built
with dpkg < 1.18.17 need to be rebuild. Is that something easy to find
out with UDD? (T
On Fri, May 25, 2018 at 03:13:43AM -0700, Sean Whitton wrote:
> Thank you for advocating on behalf of users who are not in a position to
> use the web form, Ian.
indeed, thanks, Ian.
--
cheers,
Holger
signature.asc
Description: PGP signature
On Tue, May 08, 2018 at 02:31:05PM +0100, Dominic Hargreaves wrote:
> > > Since the number of bugs is pretty large, I think it would be best to
> > > file these in batches.
> > why? I cannot see the benefit of this, but I can see the downsides. IME
> > it's never^wonly very rarely useful to delay r
Hi,
On Sun, May 06, 2018 at 04:08:06PM +0100, Dominic Hargreaves wrote:
> Thanks for doing this detailed work - which is very timely and important
> to ensure that communication paths within Debian remain open.
indeed! Christoph, many thanks for your work on this!
> > Affected packages below, as
On Fri, May 04, 2018 at 10:52:26PM +0200, W. Martin Borgert wrote:
> On 2018-05-04 21:12, Moritz Mühlenhoff wrote:
> > Same as all previous extension breakages incurred by ESR transitions;
> Why?
because this is what the modern web has become in 2018. go gopher go!
--
cheers,
Holger, SC
On Wed, May 02, 2018 at 11:09:46PM +0200, Paul Gevers wrote:
> tl;dr: migration from unstable to testing is influenced by the results
> of autopkgtest tests of your own package as well as those of your
> reverse dependencies.
AWESOME
Thank you to everone who worked and works on this!
--
chee
On Wed, May 02, 2018 at 08:12:21PM +0200, Antoine Beaupré wrote:
> try removing the first slash there :)
ah, ouch, thanks. sorry for trying to do a drive-by migration with
little attention spam. (some now contributor wanted to contribute but
asked for salsa move first but couldnt do that themselve
On Wed, May 02, 2018 at 07:02:29PM +0200, Paolo Greppi wrote:
> Hi Holger, try this:
> /alioth-migration/migrate-repo -v -d /git/collab-maint/anarchism.git
> /debian/anarchism
holger@moszumanska:~$ ls /alioth-migration/migrate-repo
ls: cannot access /alioth-migration/migrate-repo: No such file o
hi,
maybe i'm stupid but i'm also failing now with my 3rd "quick" attempt of
migration to salsa using the script...
holger@moszumanska:~/alioth-migration$ ./migrate-repo -v -d
/srv/git.debian.org/git/collab-maint/anarchism.git /debian/anarchism
(GITLAB_TOKEN was set as an environment variable.)
On Wed, May 02, 2018 at 11:23:56AM +0200, Thomas Goirand wrote:
> Frankly, I don't see the point in writing this kind of software. Sbuild
> works super well with the overlay backend, and already has throw-able
> chroots in tmpfs. Adding docker into this doesn't add any new feature,
> and in some wa
hi Aaron,
On Tue, May 01, 2018 at 11:10:15AM +0100, Aaron Gray wrote:
> Where do I find the .deb source packaging source code for packlages ? I
> does not seem to be in your sources. I need to update some packages to
> latest releease. Is this done by bhand on packages by bespoke or is there a
> b
On Mon, Apr 30, 2018 at 04:11:48PM +0300, Adrian Bunk wrote:
> > Wow, hopefully not ! LTS is an effort by the Debian project. What the
> > external company does is an effort to *FUND* individual to work on it.
> > Currently, only Freexian does this sponsor gathering and redistribution
> > work, bu
On Sat, Apr 28, 2018 at 04:25:35PM +0200, Alexander Wirt wrote:
> > does that mean git.debian.org starts becoming unusable (as a git server) on
> > 2018-05-16?
> No, as announced in my timeline [1] that will happen later.
>
> But I will do a first rsync run during Hamburg, it helps when as much
>
On Fri, Apr 27, 2018 at 08:55:43AM +0200, Alexander Wirt wrote:
> please remove your old, unused repos on alioth, so that we don't have to
> archive them.
>
> For darcs, bzr and mecurial do this until 2018-05-09 for all other VCS until
> 2018-05-16.
does that mean git.debian.org starts becoming
package: release-notes
severity: wishlist
x-debbugs-cc: debian-devel@lists.debian.org
On Tue, Apr 24, 2018 at 05:37:00AM +, Niels Thykier wrote:
> Reminder: The release-notes does have a section for "deprecations" (Note
> as I recall, it was empty for stretch, so it is probably not visible the
On Mon, Apr 23, 2018 at 07:05:41PM +0100, Chris Lamb wrote:
> It does, no? The current text is:
ah, thanks for clarifying. I indeed filed the bug only by judging what
was said and quoted on -devel@. Sorry for the noise!
--
cheers,
Holger
signature.asc
Description: PGP signature
package: lintian
severity: wishlist
x-debbugs-cc: debian-devel@lists.debian.org
On Mon, Apr 23, 2018 at 06:33:20PM +0100, Chris Lamb wrote:
> For example, I think Holger is interpreting this particular tag as
> "this source package is shipping a Python 2.x" module. This is not
> the case.
>
> Ra
On Mon, Apr 23, 2018 at 12:41:36PM +0100, Ian Jackson wrote:
> > N:If upstream have not moved or have no intention to move to Python 3,
> > N:please be certain that Debian would benefit from the inclusion,
> > N:continued maintenance burden and (eventual) removal of this package
> > N:
On Mon, Apr 23, 2018 at 03:46:36AM +, Luke W Faraone wrote:
> > you make it sound like the lintian maintainers are a bunch of lunatics,
> > but according to src:piuparts/debian/copyright, that's us, the piuparts
> > maintainers. the lintian maintainers (and uploaders) are a bunch of
> > (ex- an
On Mon, Apr 23, 2018 at 01:52:19AM +, Scott Kitterman wrote:
> Fundamentally not a lintian warnings are created equal. Some have solid
> foundation in Debian project consensus and policy. Others are nothing
> more than the opinions of the lintian maintainers. This is one of the latter.
you
On Thu, Apr 05, 2018 at 10:43:04AM +0200, Philipp Kern wrote:
> So what would be needed to make at least a simple export of the data
> happen? I think the requirements I'd have are these:
that's a good question! :)
maybe we can sit together with some ftp-team and reproducible builds
folks in Hamb
On Thu, Apr 19, 2018 at 09:06:36AM +0100, Simon McVittie wrote:
> youtube-dl seems to have this bug in jessie-backports only. It could be
> fixed by a re-upload with only one maintainer. Bugs in backports are not
> tracked in the Debian BTS[1] but I've contacted the backports mailing list
> and the
On Thu, Apr 19, 2018 at 09:35:25AM +1200, Ben Caradoc-Davies wrote:
> In the C locale, all uppercase letters are sorted before all lowercase
> letters:
>
> $ echo -e "buster\nStretch" | LC_COLLATE=C sort
> Stretch
> buster
>
> In en_GB, by comparison:
>
> $ echo -e "buster\nStretch" | LC_COLLATE
On Thu, Apr 19, 2018 at 09:06:09AM +0200, Andreas Tille wrote:
> > OTOH, there are some packages that have users.alioth.debian.org
> > e-mail addresses in Maintainer and Uploaders, that may be worth
> > dealing with.
Andreas, thanks for digging out the facts and informing those affected!
--
ch
On Wed, Apr 18, 2018 at 10:23:29AM -0400, Michael Stone wrote:
> On Wed, Apr 18, 2018 at 04:15:59PM +0200, Aurelien Jarno wrote:
> > Please define "sorted order", not everybody order letters the same way.
> really? there's more than one alphabetical order for english words?
yes, sorting depends on
Dear Lucas,
(it was really nice to meet you in Curitiba and I'm looking forward to
meet you again in the next weeks in Sao Paulo!)
Please relay my condolences to Athos, I wish this wouldnt have
demotivated him, though I'd totally understand if he spents his time on
more fun things to do in future
On Tue, Apr 17, 2018 at 08:38:52PM +0300, Adrian Bunk wrote:
> You could make the point that he should have posted to debian-private
> instead of debian-devel.
Rolf is a DM, so he cannot read debian-private and he might not even
know it exists.
> In any case naming the people who did this is requ
On Tue, Apr 17, 2018 at 10:39:22PM +0200, 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?
> This might become r
Alexander, thanks for the update on the alioth migration!
On Tue, Apr 17, 2018 at 01:00:56PM +0200, Alexander Wirt wrote:
> 17.-20.05.18: During the Mini-DebConf Hamburg any existing cron jobs will be
> turned off, websites still on alioth will be disabled.
we currently use https://reproducible.
On Tue, Apr 17, 2018 at 01:04:47PM +, Scott Kitterman wrote:
> >if your package recommends a package which is not available, this is a
> >normal bug, not one with RC severity (and neither an important one).
>
> Policy 2.2.1 pretty clearly says otherwise.
wow, I stand corrected, thanks.
(not
folks,
if your package recommends a package which is not available, this is a
normal bug, not one with RC severity (and neither an important one).
--
cheers,
Holger
signature.asc
Description: PGP signature
Rolf,
first of all, you immediatly lost your argument by putting peoples name
in the subject of a mail to debian-devel. This is really bad style
(called fingerpointing) and I wish you hadn't done this. Based on this
behaviour alone, I wouldnt recommend *you* becoming a DD or DM, at least
not now.
Dear Lumin,
you didnt mention which package of yours is stuck in NEW, could you
please elaborate? Else this seems like a rant out of the blue, without
much checking of facts, like Phil (Hands) thankfully provided.
I also share wookey's observation that NEW is being processed more
quickly than eve
On Mon, Apr 09, 2018 at 03:34:42PM +0200, W. Martin Borgert wrote:
> We have apparmor (maybe even by default!) to prevent network accesss
> of a music application, which is perfect for Adam, you and me, but it
> must also be easy to allow e.g. fetching of lyrics for those who want
> this. But only
On Sun, Apr 08, 2018 at 11:47:54PM +0200, Adam Borowski wrote:
> While I need online music services about as much as I need an additional
> hole in the head, this raises a good point: why do music players shipped in
> Debian default to grabbing lyrics, "LastFM stats", tags, and what not, even
> whe
On Wed, Mar 28, 2018 at 02:40:58PM +0200, Marco d'Itri wrote:
> This is how I see it: keeping the bug around as documentation to prevent
> other people opening it again.
IME there are two (more) aspects when dealing with wontfix bugs: keeping
those bugs open, so they are more visible or closing t
Hi Andreas,
I'd suggest you let go and stop caring about m68k. m68k has been dropped
from Debian many releases ago, thus IMO bugs affecting only m68k are
probably at most normal severity, though minor or wishlist IMO make
equally sense. Or just closing them as out of scope. Or you could tag
them "
On Thu, Mar 22, 2018 at 03:40:21PM +0100, Guillem Jover wrote:
> [...] I'd very strongly object to completely moving
> those fields out of the source packages, because it means when you get
> or have a source package lying around then it's missing important
> metadata and it stops being standalone,
On Fri, Mar 16, 2018 at 10:46:44PM +0100, Adam Borowski wrote:
> Bottom line: this mailing list is not a place to shame people about
> following or not a particular approach to genders.
bottom line: you don't listen to your own advice.
--
cheers,
Holger
signature.asc
Description: PGP
On Fri, Mar 09, 2018 at 02:07:19AM +0100, gregor herrmann wrote:
> We might need an archive area which is independent of our release
> suites.
.oO( PPAs )
--
cheers,
Holger
signature.asc
Description: PGP signature
On Tue, Mar 06, 2018 at 05:54:55PM +0100, Adam Borowski wrote:
> With my one of most active sponsors hat on: the current policy is that a
> version that has never hit the archive must not have a separate changelog
> entry, unless there are non-negligible users (such as a derivative, upstream
> repo
On Thu, Mar 01, 2018 at 10:26:27AM +0100, Didier 'OdyX' Raboud wrote:
> Good point: not all versions are desirable; "majors" can be installed in
> parallel, "minors" are updates to the formers.
I dont get this, your minor difference may make a major difference to
me. So if you/we were allowing se
On Wed, Feb 28, 2018 at 09:59:56AM -0800, Don Armstrong wrote:
> I suppose an alternative is to have the BTS ignore the special effect
> for -done messages which don't have a Version:, Package:, or other
> appropriate pseudoheader from a message which looks signed, a mailing
> address which is not
On Sun, Feb 25, 2018 at 07:05:52PM +0100, Moritz Mühlenhoff wrote:
> The security tracker is fairly flexible and it should take little
> effort to setup a separate instance which is based on the main
> data/our triage efforts while acting on a local Packages file.
>
> Ideally document this process
On Tue, Feb 20, 2018 at 07:21:21PM +0800, Paul Wise wrote:
> adequate has an incompatible-licenses tag that probably could be used
> for this. Just install all rdeps of cups and check all packages on the
> system with adequate.
piuparts.debian.org does this automatically (obviously only for stuff
On Mon, Feb 19, 2018 at 08:44:58PM +0100, Vincent Bernat wrote:
> a bit like backports that are not security supported
> either.
this is now the 2nd mail within 24h were you claim this *wrongly*.
backports are (supposed to be) getting security support. if you dont do
this for your backports, you
On Mon, Feb 19, 2018 at 09:52:57AM -0500, Michael Stone wrote:
> I'd argue that what people should stop being afraid of is just using a third
> party package if that's the optimal solution.
+1
--
cheers,
Holger
signature.asc
Description: PGP signature
On Sat, Feb 17, 2018 at 11:14:51PM +, Colin Watson wrote:
> * Constrained to the sort of server-side applications that might
>reasonably be run in a container on their own, just to keep the
>problem size down a bit.
why this contraint, there are more and more desktop application writt
On Fri, Feb 16, 2018 at 04:34:39PM +0100, Samuel Thibault wrote:
> Well, strictly speaking Debian does not actually need to be involved
> then, applications are already doing that. But it's indeed a sign that
> Debian is losing relevance, which is concerning and Debian could have to
> do something
301 - 400 of 1240 matches
Mail list logo
