Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

On Sun, Sep 08, 2019 at 11:17:13PM +0200, Marco d'Itri wrote: > On Sep 08, Ondřej Surý wrote: > > > I would rather see an explicit statement. I would be very surprised > > with Debian’s usual stance regarding the users’ privacy that we would > > not consider this as a privacy violation, but

Re: getting rid of "testing"

On Tue, Jun 25, 2019 at 01:11:09PM +0500, Andrey Rahmatullin wrote: > On Tue, Jun 25, 2019 at 09:46:00AM +0200, Bastian Blank wrote: > > > Related to that I would like to be able to write something like > > > deb http://deb.debian.org/debian debian11 main > > > deb

Re: The Difference between debcheckout and dgit and what they try to accomplish

On Mon, Jun 17, 2019 at 11:47:38AM +0100, Sean Whitton wrote: > We could try to write a tool which tries to guess and convert (e.g.) the > dgit view with your changes into a maintainer workflow, but there are > large obstacles to this working reliably. For example, there exist edge > cases such

Re: scratch buildds

On Sat, Jun 15, 2019 at 11:34:19PM +0200, Bernd Zeimetz wrote: > > Hi Chris, > > On 6/15/19 12:28 AM, Chris Lamb wrote: > > Adam Borowski wrote: > > > >> Thus, what would you guys say about a new distribution, "scratch"? It > >> would > >> be a kind of extra-experimental that doesn't put its

Re: scratch buildds

On Sat, Jun 15, 2019 at 05:01:29PM +0200, Adam Borowski wrote: > Not every commit is worth testing, So only push when you want to test. GitLab CI tests every push, not every commit. > especially on bigger packages. I don't > want to cause unnecessary drain on already limited resources (crap >

Re: scratch buildds

On Fri, Jun 14, 2019 at 10:51:56PM +0200, Adam Borowski wrote: > Hi! > Fedora has an awesome feature for packagers: scratch builds. It would be > great if we could steal the idea. > > I find myself doing incremental uploads just to fix bugs that the previous > upload revealed on some weird arch.

Re: speeding up installs

On Mon, Jun 10, 2019 at 12:56:53PM -0400, Sam Hartman wrote: > Most debian systems are not installed with d-i. When you include things > like FAI for installing sites and clusters; chroots, containers, VMs, > etc, d-i is not used in most situations. Your 'most' does not match mine. I played

Accepted ola 0.10.7.nojsmin-2 (source amd64 all) into unstable

Maintainer: Wouter Verhelst Changed-By: Wouter Verhelst Description: libola-dev - Open Lighting Architecture - development libraries libola1- Open Lighting Architecture - shared libraries ola- Open Lighting Architecture ola-python - Open Lighting Architecture - Python Classes ola-rdm

Re: Cdbs Features

On Wed, May 15, 2019 at 02:37:59PM +0900, Marc Dequènes (duck) wrote: > On the more general topic, I believe there should be room for new tools to > emerge and not-being-dh should never be a RC or even important bug. My thoughts exactly. I think at this point we can recommend dh, and require

Accepted policy-rcd-declarative 0.2 (source all) into experimental

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 02 May 2019 11:31:23 +0200 Source: policy-rcd-declarative Binary: policy-rcd-declarative Architecture: source all Version: 0.2 Distribution: experimental Urgency: medium Maintainer: Wouter Verhelst Changed-By: Wouter Verhelst

Accepted policy-rcd-declarative 0.1 (source all) into experimental, experimental

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 11 Mar 2019 00:35:02 +0200 Source: policy-rcd-declarative Binary: policy-rcd-declarative Architecture: source all Version: 0.1 Distribution: experimental Urgency: medium Maintainer: Wouter Verhelst Changed-By: Wouter Verhelst

Accepted nbd 1:3.19-3 (source amd64) into unstable

Verhelst Changed-By: Wouter Verhelst Description: nbd-client - Network Block Device protocol - client nbd-client-udeb - Network Block Device protocol - client for Debian Installer (udeb) nbd-server - Network Block Device protocol - server Closes: 922383 Changes: nbd (1:3.19-3) unstable

Accepted sreview 0.4.0-2 (source all) into unstable

Verhelst Changed-By: Wouter Verhelst Description: sreview-common - SReview -- common code sreview-detect - SReview input detection script sreview-encoder - SReview encoder code sreview-master - SReview components for master host sreview-web - SReview webinterface Changes: sreview (0.4.0-2

Accepted sreview 0.4.0-1 (source all) into unstable

Verhelst Changed-By: Wouter Verhelst Description: sreview-common - SReview -- common code sreview-detect - SReview input detection script sreview-encoder - SReview encoder code sreview-master - SReview components for master host sreview-web - SReview webinterface Changes: sreview (0.4.0-1

Accepted nbd 1:3.19-2 (source amd64) into unstable

Verhelst Changed-By: Wouter Verhelst Description: nbd-client - Network Block Device protocol - client nbd-client-udeb - Network Block Device protocol - client for Debian Installer (udeb) nbd-server - Network Block Device protocol - server Changes: nbd (1:3.19-2) unstable; urgency=medium

Accepted nbd 1:3.19-1 (source amd64) into unstable

Verhelst Changed-By: Wouter Verhelst Description: nbd-client - Network Block Device protocol - client nbd-client-udeb - Network Block Device protocol - client for Debian Installer (udeb) nbd-server - Network Block Device protocol - server Closes: 908977 Changes: nbd (1:3.19-1) unstable

Re: Bug#877900: How to get 24-hour time on en_US.UTF-8 locale now?

On Thu, Feb 07, 2019 at 02:05:33PM +0100, Adam Borowski wrote: > > LC_TIME="en_US.UTF-8" If you don't want US time, don't set US time. Instead, do something like: LC_TIME=en_BE.UTF-8 which means "I want time in English, but using Belgian customs, not the US ones". You may have to custom edit

Re: Proposal: Repository for fast-paced package backports

On Wed, Dec 26, 2018 at 07:19:02PM +0100, Dominik George wrote: > > If you don't see obstacles, why not start today? > > I think I already made those obstacles clear: Starting outside means > buying, (or getting donated) > installing and operating at least a server vor volatile.debian.net

Re: NEW and RC bugs (Re: julia_1.0.0-1_amd64.changes REJECTED)

On Tue, Nov 27, 2018 at 01:01:12PM +0500, Andrey Rahmatullin wrote: > On Tue, Nov 27, 2018 at 08:38:56AM +0100, Wouter Verhelst wrote: > > > > The experimental distribution is a good place for work in > > > > progress. Maybe the rules for automatic rejects can be relax

Re: Our build system may be broken: /bin vs /usr/bin

On Mon, Nov 19, 2018 at 04:59:57PM +0100, Matthias Klumpp wrote: > Am Mo., 19. Nov. 2018 um 16:52 Uhr schrieb Dirk Eddelbuettel > : > > > > > > Hi Ian, > > > > Thanks for the follow-up. > > > > On 19 November 2018 at 15:45, Ian Jackson wrote: > > | Dirk Eddelbuettel writes ("Our build system may

Re: NEW and RC bugs (Re: julia_1.0.0-1_amd64.changes REJECTED)

On Tue, Nov 27, 2018 at 01:05:14AM +0100, Alf Gaida wrote: > On Sat 24 Nov 2018 at 04:29PM +0100, Guido Günther wrote: > > > The experimental distribution is a good place for work in > > progress. Maybe the rules for automatic rejects can be relaxed for > > experimental so a package can go into

Re: NEW and RC bugs (Re: julia_1.0.0-1_amd64.changes REJECTED)

On Thu, Nov 22, 2018 at 09:16:59PM +, Holger Levsen wrote: > 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

Re: I resigned in 2004

On Sun, Nov 11, 2018 at 06:31:35PM +0100, Carsten Leonhardt wrote: > Russ Allbery writes: > > > The general principle that I would advocate for here, though, is that if > > someone says clearly and explicitly "never contact me again," we should do > > what we can to never contact them again. >

Re: I resigned in 2004

On Sat, Nov 10, 2018 at 03:49:32PM +0100, Dominik George wrote: > I am thus very happy that this DD is leaving immediately - whether you see > this as bureaucracy or not, he agreed with rules and processes when he > joined, There were *far* fewer of them when he did. In 2000, you didn't need an

Re: I resigned in 2004

On Sat, Nov 10, 2018 at 07:07:36PM -0800, Russ Allbery wrote: > Mattia Rizzolo writes: > > > Indeed, I was very bothered. > > > On the other hand, most of my reply to willy's mail was not addressed to > > him, but to debian-devel@ at large, to have everybody else understand > > how silly what

Re: Confusing our users - who is supporting LTS?

On Fri, Nov 02, 2018 at 08:58:47AM +, Jonathan Dowland wrote: > On Sat, Oct 27, 2018 at 09:41:43AM +0200, Wouter Verhelst wrote: > > On Fri, Oct 26, 2018 at 01:02:57PM -0300, Thadeu Lima de Souza Cascardo > > wrote: > > > I meant that we would say that stable is suppor

Re: Confusing our users - who is supporting LTS?

On Mon, Oct 29, 2018 at 12:56:26PM +, Holger Levsen wrote: > 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 > > >

Re: Confusing our users - who is supporting LTS?

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 circumstances at the time were also different. -- To the thief who stole

Re: Confusing our users - who is supporting LTS?

On Fri, Oct 26, 2018 at 01:02:57PM -0300, Thadeu Lima de Souza Cascardo wrote: > I meant that we would say that stable is supported by the security team. > And instead of saying that Jessie was supported by the LTS team, we > would say supported by Freexian. I would object to that, on the grounds

Re: Debian Buster release to partially drop non-systemd support

On Wed, Oct 24, 2018 at 11:30:17AM +0200, Marc Haber wrote: > On Tue, 23 Oct 2018 16:43:07 +0200, Wouter Verhelst > wrote: > >This has been discussed before and rejected. It makes no sense. > > technically, but a lot of sense if it helps silencing another > instance of

Re: no{thing} build profiles

On Tue, Oct 23, 2018 at 04:40:34PM +, Ivan Shmakov wrote: > >>>>> Wouter Verhelst writes: > >>>>> On Mon, Oct 22, 2018 at 11:12:57PM +0200, Adam Borowski wrote: > >>>>> On Mon, Oct 22, 2018 at 01:22:12PM -0700, Russ Allbery wrote:

Re: no{thing} build profiles

On Tue, Oct 23, 2018 at 05:04:11PM +0200, Vincent Lefevre wrote: > On 2018-10-22 10:47:05 +0100, Jonathan Dowland wrote: > > On Sun, Oct 21, 2018 at 10:00:43PM +, Ivan Shmakov wrote: > > > It can be argued that libgpgme11 does not “provide a significant > > > amount of functionality” (7.2)

Re: no{thing} build profiles

On Mon, Oct 22, 2018 at 11:12:57PM +0200, Adam Borowski wrote: > On Mon, Oct 22, 2018 at 01:22:12PM -0700, Russ Allbery wrote: > > Adam Borowski writes: > > > > > Thus, I'd re-propose a Policy change that was mentioned in multiple > > > threads in the past: > > > > > "A runtime library should

Re: Debian Buster release to partially drop non-systemd support

On Sat, Oct 20, 2018 at 08:22:35AM +0800, Paul Wise wrote: > On Fri, Oct 19, 2018 at 7:30 PM Martin Steigerwald wrote: > > > As long as people choose to strip of dependencies to libsystemd from > > packages like util-linux, avoiding a fork would not work with how Debian > > and Debian based

Re: no{thing} build profiles

On Sun, Oct 21, 2018 at 12:13:27PM -0400, Marvin Renich wrote: > * Sune Vuorela [181021 06:05]: > > On 2018-10-21, Jonas Smedegaard wrote: > > > I disagree that libgpgme11 should depend/recommend/suggest gnupg at all: > > > As a library it cannot possibly declare how tight a relationship to >

Re: Limiting the power of packages

On Thu, Oct 04, 2018 at 01:27:29PM +0200, Enrico Weigelt, metux IT consult wrote: > Yes, that would have to be customized per-package, but we're only > talking about a hand full of packages, anyways. Eh, no. -- Could you people please use IRC like normal people?!? -- Amaya Rodrigo Sastre,

Re: julia_1.0.0-1_amd64.changes REJECTED

Hi Lumin, On Tue, Sep 25, 2018 at 02:40:43PM +, Lumin wrote: > > What I'm emphasizing here is, the debug info in those shared objects > > are intensionally kept to preserve a good user experience and > > avoid increasing maintainance burden. > > > > This is the expected backtrace from the

Re: Package not compatible with old systemd

On Tue, Sep 18, 2018 at 10:45:45AM +0200, Ondrej Novy wrote: > Hi, > > út 18. 9. 2018 v 10:30 odesílatel Lars Wirzenius napsal: > > Would Conflicts work here? > > > Conflicts is just more strict Breaks, Eh, no. > for example when files are overwritten. This is not case and Breaks > "is

Re: [Delayed] Summary of the web team BoF at DC18

On Thu, Sep 13, 2018 at 04:02:15AM +0100, Steve McIntyre wrote: > * Build using GitLab CI? (this looks quite difficult! proposals welcome > :-)) No it's not :-) I'm willing to look into this. -- Could you people please use IRC like normal people?!? -- Amaya Rodrigo Sastre, trying to

Accepted ola 0.10.7.nojsmin-1 (source amd64 all) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 07 Sep 2018 20:33:31 +0200 Source: ola Binary: libola-dev ola-python ola-rdm-tests ola libola1 Architecture: source amd64 all Version: 0.10.7.nojsmin-1 Distribution: unstable Urgency: medium Maintainer: Wouter Verhelst

Re: Q: Where is keyring packaging guideline?

On Tue, Aug 21, 2018 at 01:15:03PM +0200, Adam Borowski wrote: > On Tue, Aug 21, 2018 at 01:39:29PM +0800, Paul Wise wrote: > > On Tue, Aug 21, 2018 at 1:21 PM, Kentaro Hayashi wrote: > > > > > I want to make 3rd party keyring package (ITP). In the advance, I > > > want to know a best practice

Accepted nbd 1:3.18-1 (source amd64) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 18 Aug 2018 17:19:50 +0200 Source: nbd Binary: nbd-server nbd-client nbd-client-udeb Architecture: source amd64 Version: 1:3.18-1 Distribution: unstable Urgency: medium Maintainer: Wouter Verhelst Changed-By: Wouter Verhelst

Re: salsa.debian.org maintenance (GitLab 11.1.4 upgrade, external storage migration)

On Fri, Aug 17, 2018 at 11:12:01PM +0200, Thomas Goirand wrote: > On 08/17/2018 04:11 PM, Wouter Verhelst wrote: > > But if we're going to > > be using an external cloud provider for such things, then it doesn't > > matter whether that external cloud provider runs

Re: salsa.debian.org maintenance (GitLab 11.1.4 upgrade, external storage migration)

On Tue, Aug 14, 2018 at 01:25:22PM +0200, Jonas Meurer wrote: > [...] free software cloud providers [...] No such thing. The whole concept of "cloud provider" is that you have a company which provides "hardware" or "infrastructure" as a service. This service is provided "as is"; you wouldn't be

Re: changing git tags on the remote repo

On Sun, Aug 12, 2018 at 01:12:40PM +0200, Holger Wansing wrote: > Hi, > > I am curious about how to change an already existing git tag afterwards > (means: change the commit it points to). > > Locally, I can change an existing tag, and then create it newly. > But I cannot push it to the remote

Re: intended MBF: wrong redirections in maintainer scripts

On Thu, Aug 09, 2018 at 09:48:22PM +0200, Ralf Treinen wrote: > Hello Wouter, > > On Tue, Aug 07, 2018 at 12:38:32PM +0200, Wouter Verhelst wrote: > > On Sat, Aug 04, 2018 at 01:15:57PM +0800, Ralf Treinen wrote: > > > Hi, > > > > > > as announced in

Accepted pmw 1:4.30-1 (source amd64 all) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 08 Aug 2018 17:22:53 +0200 Source: pmw Binary: pmw pmw-doc Architecture: source amd64 all Version: 1:4.30-1 Distribution: unstable Urgency: medium Maintainer: Wouter Verhelst Changed-By: Wouter Verhelst Description: pmw

Re: intended MBF: wrong redirections in maintainer scripts

On Sat, Aug 04, 2018 at 01:15:57PM +0800, Ralf Treinen wrote: > Hi, > > as announced in our talk at debconf'18 [1] we intend a MBF about wrong > redirections in maintainer scripts. In general these are of the form > > foo 2>&1 1> /dev/null > > Here it was probably intended to send both stderr

Re: Should the weboob package stay in Debian?

Hi Marc, On Sun, Jul 22, 2018 at 09:39:51AM +0900, Marc Dequènes (duck) wrote: > - is it degrading? > « These are acts that, even if done by consent, convey a message that > diminishes the importance or value of all human beings. » > This does no apply here as there is no depiction of act or

Re: Should the weboob package stay in Debian?

On Thu, Jul 19, 2018 at 10:02:23PM +1000, Dmitry Smirnov wrote: > On Thursday, 19 July 2018 7:43:39 PM AEST Wouter Verhelst wrote: > > weboob itself is fine, maybe. But there are various other binaries > > inside the weboob packages that aren't, at least not so much: > > >

Re: Should the weboob package stay in Debian?

On Fri, Jul 20, 2018 at 10:34:28AM +0200, Ansgar Burchardt wrote: > Matthew Vernon writes: > > We shouldn't need to have numbers of people having to justify why a > > particular thing is offensive before we (as a project) try and fix > > it. > > That works if Debian was a non-diverse groups where

Re: Should the weboob package stay in Debian?

On Fri, Jul 20, 2018 at 01:34:19PM +1000, Dmitry Smirnov wrote: > I refuse to judge the matter with my feelings. Rationality has a place, but so do feelings. The names in this package are offensive, plain and simple. Are other names offensive? Maybe. Does that mean we should do nothing until

Re: Should the weboob package stay in Debian?

Hi Dmitry, On Thu, Jul 19, 2018 at 05:40:46PM +1000, Dmitry Smirnov wrote: > On Thursday, 19 July 2018 10:50:20 AM AEST Ian Jackson wrote: > > I think this naming, and the iconography, is all very unfortunate. > > IMO it is not compatible with Debian's Diversity Statement (which as > > ou know

Re: Research survey: Impact of Microsoft Acquisition of GitHub

Hi Chris, [Cc list trimmed] On Wed, Jul 11, 2018 at 05:05:48PM +0100, Chris Lamb wrote: > Hi Wouter et al., > > > This questionnaire contains an error: > > Whilst I certainly appreciate your usual attention to detail and > preciseness note that these questionnaires — whilst they appear to be >

Re: Research survey: Impact of Microsoft Acquisition of GitHub

Hi, On Mon, Jul 09, 2018 at 02:13:13PM +0900, Asavaseri Natnaree wrote: > Dear Debian developers,  > > I am Natnaree Asavaseri and currently undertaking a research internship at > Nara Institute of Science and Technology, Japan. Note that we are not biased > to either GitHub or Microsoft, and

Re: get-orig-source and standardized source repacking (was: Debian Policy 4.1.4.0 released)

On Fri, Jul 06, 2018 at 08:27:13AM +0100, Simon McVittie wrote: > On Fri, 06 Jul 2018 at 08:16:12 +0200, Andreas Tille wrote: > > Just yesterday > > I had an example where the upstream download archive is lacking some > > files from upstream SVN which need to be merged in to enable building > >

Re: Versioned dependencies and maintainer scripts

On Mon, Jun 25, 2018 at 08:04:01AM +0100, Simon McVittie wrote: > On Sun, 24 Jun 2018 at 17:05:54 -0600, Daniele Nicolodi wrote: > > Packages that will use dh_installsystemduser will have maintainer > > scripts that will depend on the next relese of init-system-helpers. > > dh_installsystemduser

Re: Which checks should we mandate for source operations in shell scripts

On Wed, Jun 20, 2018 at 09:49:29PM +0200, Marc Haber wrote: > It has (finally, and to late) occurred to me that > > |# back up /etc/default/foo > |cp /etc/default/foo ~/foo > |(try something in /etc/default) > |sudo mv ~/foo /etc/default/foo > > will place a file owned by my "normal" user into

Accepted sreview 0.3.1-2 (source all) into unstable

Verhelst Changed-By: Wouter Verhelst Description: sreview-common - SReview -- common code sreview-detect - SReview input detection script sreview-encoder - SReview encoder code sreview-master - SReview components for master host sreview-web - SReview webinterface Closes: 901542 Changes

Accepted sreview 0.3.1-1 (source all) into unstable

Verhelst Changed-By: Wouter Verhelst Description: sreview-common - SReview -- common code sreview-detect - SReview input detection script sreview-encoder - SReview encoder code sreview-master - SReview components for master host sreview-web - SReview webinterface Closes: 901136 Changes

Re: Please remove your obsolete repos from alioth *NOW*

Hi, On Wed, May 30, 2018 at 10:24:33AM +0200, Alexander Wirt wrote: > Hi, > > we still have 175GiB git repos left on alioth. Please remove them asap. Life has been busy recently, and I didn't see this message until now. I guess that alioth has been shut down by now. Is it still possible for

Accepted libnet-ssh-authorizedkeysfile-perl 0.18-1 (source all) into unstable, unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 20 May 2018 07:58:50 +0200 Source: libnet-ssh-authorizedkeysfile-perl Binary: libnet-ssh-authorizedkeysfile-perl Architecture: source all Version: 0.18-1 Distribution: unstable Urgency: low Maintainer: Wouter Verhelst Changed

Accepted libnet-ssh-authorizedkeysfile-perl 0.18-2 (source all) into unstable, unstable

Changed-By: Wouter Verhelst Description: libnet-ssh-authorizedkeysfile-perl - Read and modify ssh's authorized_keys files Changes: libnet-ssh-authorizedkeysfile-perl (0.18-2) unstable; urgency=medium . * Move to pkg-perl: - Set maintainer to pkg-perl-team, add $SELF to uploaders * Fix

Accepted ola 0.10.6.nojsmin-1 (source amd64 all) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 17 May 2018 13:49:47 +0200 Source: ola Binary: libola-dev ola-python ola-rdm-tests ola libola1 Architecture: source amd64 all Version: 0.10.6.nojsmin-1 Distribution: unstable Urgency: medium Maintainer: Wouter Verhelst <

Re: Please do not drop Python 2 modules

On Wed, Apr 25, 2018 at 09:16:06AM +0200, Thomas Goirand wrote: > On 04/24/2018 07:39 AM, Vincent Bernat wrote: > > ❦ 23 avril 2018 23:54 +0200, Thomas Goirand  : > > > >> Isn't 10 years of Python 3 enough time for a migration? > > > > Python 3.3, the first release people could

Re: interpretation of wontfix

On Thu, Mar 29, 2018 at 02:16:31PM +0100, Ian Campbell wrote: > On Thu, 2018-03-29 at 14:02 +0100, Ian Jackson wrote: > > Don Armstrong writes ("Re: interpretation of wontfix"): > > > 2) wontfix+help: this bug requires too much effort to fix, so I won't be > > >working on it, but patches will

Re: Usage of real m68k hardware

On Wed, Mar 28, 2018 at 08:38:10AM +0200, Andreas Tille wrote: > Hi, > > recently some R packages received bugs that seem to stem from a problem > with the build setup (specifically, a qemu bug). When I asked back in > one of the bugs[1] whether there are real m68k users I've got the answer > >

Accepted nbd 1:3.17-2 (source amd64) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 17 Mar 2018 22:48:11 +0100 Source: nbd Binary: nbd-server nbd-client nbd-client-udeb Architecture: source amd64 Version: 1:3.17-2 Distribution: unstable Urgency: medium Maintainer: Wouter Verhelst <wou...@debian.org> C

Accepted nbd 1:3.17-1 (source amd64) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 16 Mar 2018 19:23:31 +0100 Source: nbd Binary: nbd-server nbd-client nbd-client-udeb Architecture: source amd64 Version: 1:3.17-1 Distribution: unstable Urgency: medium Maintainer: Wouter Verhelst <wou...@debian.org> C

Re: What can Debian do to provide complex applications to its users?

On Fri, Feb 16, 2018 at 04:11:29PM +0100, Raphael Hertzog wrote: > Hello everybody, > > the fact that I had to request the removal of dolibarr from Debian makes > me sad (see below for the reasons) and I believe that we should be able > to do better to provide complex applications to our end

Re: Debian part of a version number when epoch is bumped

On Thu, Feb 15, 2018 at 10:41:23AM +, Simon McVittie wrote: > On Thu, 15 Feb 2018 at 11:09:08 +0100, Wouter Verhelst wrote: > > I was thinking it might be better to go to a "wildcard" epoch: > > > > Depends: X (>= *:1.8) > > > > would mean &

Re: Debian part of a version number when epoch is bumped

On Wed, Feb 14, 2018 at 04:28:41PM -0500, Michael Stone wrote: > On Wed, Feb 14, 2018 at 12:54:05PM -0800, Russ Allbery wrote: > > Since there are two goals, a more correct implementation would be to split > > these into two versions. The simplest would be to have an integer > > "version epoch"

Re: Debian part of a version number when epoch is bumped

On Wed, Feb 14, 2018 at 04:29:20PM +0100, Michael Biebl wrote: > Am 14.02.2018 um 16:08 schrieb Andrey Rahmatullin: > > On Wed, Feb 14, 2018 at 01:57:16PM +0100, Vincent Bernat wrote: > >> It's not only an infrastructure problem. If you Depends on X (>= 1.8), > >> this will be true with X 1:1.6 as

Re: Debian part of a version number when epoch is bumped

On Wed, Feb 14, 2018 at 01:57:16PM +0100, Vincent Bernat wrote: > ❦ 14 février 2018 12:53 +0100, Wouter Verhelst <wou...@debian..org> : > > >> > Would it hurt to take those epoch bumps into Debian? > >> > >> Depends on what you mean by hurt. I see epoc

Re: Debian part of a version number when epoch is bumped

On Mon, Feb 12, 2018 at 03:23:14AM +0100, Guillem Jover wrote: > On Fri, 2018-02-09 at 14:35:15 -0500, Jeremy Bicha wrote: > > On Fri, Feb 9, 2018 at 2:22 PM, Andrey Rahmatullin wrote: > > > On Fri, Feb 09, 2018 at 06:58:49PM +0100, Philipp Kern wrote: > > >> If Ubuntu uses an

Accepted sreview 0.3.0-1 (source all) into unstable

Verhelst <wou...@debian.org> Changed-By: Wouter Verhelst <wou...@debian.org> Description: sreview-common - SReview -- common code sreview-detect - SReview input detection script sreview-encoder - SReview encoder code sreview-master - SReview components for master host sreview-w

Re: Debian part of a version number when epoch is bumped

On Wed, Feb 07, 2018 at 09:18:03AM +, Jonathan McDowell wrote: > You can't put a : in a filename on a FAT filesystem. Interestingly enough, you *can* put a : in a filename on an NTFS filesystem, if you do it with ntfs-3g. Windows won't like it, though. Yes, I found that out the hard way ;-)

Re: Removing packages perhaps too aggressively?

On Sat, Feb 03, 2018 at 11:07:37PM +0100, Adam Borowski wrote: > On Sat, Feb 03, 2018 at 06:04:42PM +0100, Bernd Zeimetz wrote: > > and/or open an rc bug > > This sounds like an abuse to me. Why would it be? You're always allowed to open a bug with "serious" severity under the "in the opinion of

Re: Removing packages perhaps too aggressively?

On Sat, Feb 03, 2018 at 01:25:14AM +0100, Adam Borowski wrote: > On Sat, Feb 03, 2018 at 12:39:57AM +0100, Wouter Verhelst wrote: > > On Fri, Feb 02, 2018 at 12:23:51AM +0100, Adam Borowski wrote: > > > If it's orphaned+RC-buggy but it Works For Me™, it's good to stay, right? >

Re: Removing packages perhaps too aggressively?

On Fri, Feb 02, 2018 at 12:23:51AM +0100, Adam Borowski wrote: > If it's orphaned+RC-buggy but it Works For Me™, it's good to stay, right? This doesn't compute. A package can be orphaned and still perfectly functional; a package can be orphaned and RC-buggy. A package cannot, however, be

Re: Removing packages perhaps too aggressively?

On Thu, Feb 01, 2018 at 09:45:55AM +0100, Andrej Shadura wrote: > On 01/02/18 09:40, Ansgar Burchardt wrote: > > Why would filing a third RC bug (the "proposed-RM") and waiting one > > month more change anything? Why would someone turn up to fix them now? > > Why not? I *was* already doing just

Accepted sreview 0.2.4-1 (source all) into unstable

Verhelst <wou...@debian.org> Changed-By: Wouter Verhelst <wou...@debian.org> Description: sreview-common - SReview -- common code sreview-detect - SReview input detection script sreview-encoder - SReview encoder code sreview-master - SReview components for master host sreview-w

Bug#886493: general: debian should support nosystemd build profile

Hi Britton, On Sat, Jan 06, 2018 at 09:34:32AM -0900, Britton Kerin wrote: > If debian is remotely serious about keeping non-systmed use an option, > is should support a nosystemd build profile. There's no other real > way to guarantee that packages don't use it. Sure they don't *have* > to

Accepted sreview 0.2.3-3 (source all) into unstable

Verhelst <wou...@debian.org> Changed-By: Wouter Verhelst <wou...@debian.org> Description: sreview-common - SReview -- common code sreview-detect - SReview input detection script sreview-encoder - SReview encoder code sreview-master - SReview components for master host sreview-w

Re: Bug#886238: Please introduce official nosystemd build profile

On Thu, Jan 04, 2018 at 04:36:16AM +0100, Adam Borowski wrote: > The only reason to avoid libsystemd0 is a cheap way to make sure systemd > paths are not used; some packages (I forgot which) have regressions when > compiled with systemd support as they detect its presence at compile time > rather

Bug#886238: Please introduce official nosystemd build profile

Hi Steve, On Wed, Jan 03, 2018 at 10:48:06AM -0800, Steve Langasek wrote: > On Wed, Jan 03, 2018 at 09:13:24AM -0500, Paul R. Tagliamonte wrote: > > Conversely, if the patches are invasive and unmaintainable, its not on > > Debian to merge them. > > Moreover, defining an official nosystemd

Bug#886238: Please introduce official nosystemd build profile

t?) > On Jan 3, 2018 9:09 AM, "Wouter Verhelst" <wou...@debian.org> wrote: > > On Wed, Jan 03, 2018 at 01:59:05PM +0100, Andrew Shadura wrote: > > Hi, > > > > On 3 January 2018 at 13:12, Hleb Valoshka <375...@g

Bug#886238: Please introduce official nosystemd build profile

On Wed, Jan 03, 2018 at 01:59:05PM +0100, Andrew Shadura wrote: > Hi, > > On 3 January 2018 at 13:12, Hleb Valoshka <375...@gmail.com> wrote: > > Package: general > > Severity: wishlist > > > > Please introduce official nosystemd build profile so downstream > > distributions can send patches to

Accepted sreview 0.2.3-2 (source all) into experimental

: Wouter Verhelst <wou...@debian.org> Changed-By: Wouter Verhelst <wou...@debian.org> Description: sreview-common - SReview -- common code sreview-detect - SReview input detection script sreview-encoder - SReview encoder code sreview-master - SReview components for master host sreview-w

Accepted sreview 0.2.3-1 (source all) into experimental

: Wouter Verhelst <wou...@debian.org> Changed-By: Wouter Verhelst <wou...@debian.org> Description: sreview-common - SReview -- common code sreview-detect - SReview input detection script sreview-encoder - SReview encoder code sreview-master - SReview components for master host sreview-w

Re: salsa.debian.org (git.debian.org replacement) going into beta

On Sat, Dec 30, 2017 at 12:51:45PM +0100, Alexander Wirt wrote: > On Sat, 30 Dec 2017, Wouter Verhelst wrote: > > > On Fri, Dec 29, 2017 at 12:06:17PM +0100, Alexander Wirt wrote: > > > On Fri, 29 Dec 2017, Andreas Tille wrote: > > > > Or more precisely it was

Re: salsa.debian.org (git.debian.org replacement) going into beta

On Fri, Dec 29, 2017 at 12:06:17PM +0100, Alexander Wirt wrote: > On Fri, 29 Dec 2017, Andreas Tille wrote: > > Or more precisely it was a design flaw from the beginning which was > > intended to be cured with the workaround of annonscm and now it seems > > even this will be broken for no good

Re: build 2 similar binary packages from one source tree

On Sun, Dec 24, 2017 at 08:16:19PM +0100, Adam Borowski wrote: > While autotools in principle do support out-of-tree builds, a particular > program might still fail. In practice, this is rare, unless the developer doesn't try to run "make distcheck" before a build (like they really really

Accepted sreview 0.2.2-1 (source all) into experimental, experimental

: Wouter Verhelst <wou...@debian.org> Changed-By: Wouter Verhelst <wou...@debian.org> Description: sreview-common - SReview -- common code sreview-detect - SReview input detection script sreview-encoder - SReview encoder code sreview-master - SReview components for master host sreview-w

Re: recommends for apparmor in newest linux-image-4.13

On Sun, Dec 10, 2017 at 04:21:18PM -0500, Theodore Ts'o wrote: > On Wed, Dec 06, 2017 at 11:24:45AM +0100, Laurent Bigonville wrote: > > The SELinux policy could be altered to either run everything that we know is > > not ready to be confined in an unconfined domain or put that domain in > >

Re: Debian Stretch new user report (vs Linux Mint)

On Mon, Dec 04, 2017 at 04:29:43PM +0200, Lars Wirzenius wrote: > Myself, I would prefer us to keep both the free-software-only ISO and > the non-free ISO with firmware and other things needed to get typical > modern hardware running, and improve the discoverability of the > latter. I think we can

Re: recommends for apparmor in newest linux-image-4.13

On Thu, Nov 23, 2017 at 02:18:46PM +0100, Christoph Hellwig wrote: > Hi all, > > is there any good reason for the recommends of apparmor in the latest > linux packages? This is in response to a discussion that happened on this list. The thread started in august last year[1], but really picked up

Re: [apparmor] Let's enable AppArmor by default (why not?)

On Mon, Nov 20, 2017 at 07:01:29PM +0100, intrigeri wrote: > Wouter Verhelst: > > It would be awesome if you could also include some documentation in the > > style "I'm a Debian package maintainer and the apparmor profile for some > > of the binaries in one of my packag

Re: [apparmor] Let's enable AppArmor by default (why not?)

On Sat, Nov 18, 2017 at 07:23:42PM -0800, John Johansen wrote: > On 11/18/2017 01:59 PM, Marvin Renich wrote: > > * John Johansen [171118 16:02]: > >> You can disable individual profiles without editing them and messing up > >> the packaging by using aa-disable > >

Re: Auto-update for sid? Auto-backport?

On Thu, Nov 16, 2017 at 07:06:39PM +, Simon McVittie wrote: > On Thu, 16 Nov 2017 at 17:02:00 +, Holger Levsen wrote: > > On Thu, Nov 16, 2017 at 05:53:40PM +0100, Wouter Verhelst wrote: > > > Yes; and semver.org is a formalized system for version numbering stuff. >

<    1   2   3   4   5   6   7   8   9   10   >