Re: MBF: valgrind-if-available

On Sun, 2022-02-27 at 03:40 +0100, Adam Borowski wrote: > Among others, "command -v" [...] > * built-ins get reported as available.  And busybox has even "dpkg" > built-in, with a pretty bad implementation. Like this? +--- | % which which | which: shell built-in command +--- I suggest to imple

Re: git & Debian packaging sprint report

Russ Allbery writes: > Scott Kitterman writes: >> Except that we have different requirements than git. Git isn't looking >> for security properties from SHA-1, so it's highly likely it'll meet >> their accident avoidance requirements long after it's no longer >> appropriate for security related a

Re: git & Debian packaging sprint report

h the same way as tag2upload does, AFAICT. That is true and I don't like it. I should probably add a sha2 hash somewhere. (Note that we *can* just change it...) > On Mon 15 Jul 2019 at 10:43PM +02, Ansgar Burchardt wrote: > > It also has one downside: `git tag` alone won't be

Re: git & Debian packaging sprint report

Russ Allbery writes: > Ansgar Burchardt writes: >> The client tool could possibly also just create the .dsc and .changes, >> except for hashes of the compressed files, and the web service just >> recreate the tarball and compress them. > > I think experience with

Re: git & Debian packaging sprint report

Russ Allbery writes: > Ansgar Burchardt writes: >> Russ Allbery writes: >>> If so, I think that security model is roughly equivalent to the >>> automatic signing of binary packages by buildds, so probably doesn't >>> introduce a new vulnerability, >

Re: git & Debian packaging sprint report

Russ Allbery writes: > If so, I think that security model is roughly equivalent to the automatic > signing of binary packages by buildds, so probably doesn't introduce a new > vulnerability, It doesn't rely on strong cryptographic hashes to guarantee integrity. To quote Wikipedia: +--- | Revision

Re: Is it the job of Lintian to push an agenda?

Russ Allbery writes: > Matthias Klumpp writes: >> With two Debian stable releases defaulting to systemd now, I think a >> solid case could be made to at least relax the "must" requirement to a >> "should" in policy (but that should better go to the respective bug >> report). > > The Policy process

Re: git & Debian packaging sprint report

On Thu, 2019-07-11 at 17:58 -0300, Antonio Terceiro wrote: > > We designed and implemented a system to make it possible for DDs to > > upload new versions of packages by simply pushing a specially > > formatted git tag to salsa. [...] > If the uploads will be done by a service, this means that all

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

On Thu, 2019-06-20 at 10:52 +0200, Enrico Zini wrote: > This reminds me of something that popped up in a dinner discussion a few > days ago: mandate documenting workflow in debian/README.source no matter > what, and allow to symlink that file to a repository in > /usr/share/doc/somewhere/ as we do

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

Russ Allbery writes: > Colin Watson writes: >> Is it at all likely that the ftpmaster api service might migrate away >> from Let's Encrypt at this point? I would assume probably not. In that >> case, you could at least make the situation substantially better with no >> further DSA work required b

Re: .deb format: let's use 0.939, zstd, drop bzip2

Ian Jackson writes: > Ansgar writes ("Re: .deb format: let's use 0.939, zstd, drop bzip2"): >> `ar` needs to be replaced for the file size limitation mentioned in the >> initial mail: ar represents file size as a 10 digit decimal number[1] >> which limits the members (control.tar.*, data.tar.*) to

Re: Preferred git branch structure when upstream moves from tarballs to git

Sam Hartman writes: >> "Ansgar" == Ansgar writes: > > Ansgar> Sam Hartman writes: > >> I'm having a bit of trouble here and am hoping you can help us > >> out. Ian asked what git workflow it is that you're talking about > >> where people can deal with commit push and pull a

Re: Preferred git branch structure when upstream moves from tarballs to git

On Tue, 2019-04-30 at 16:00 -0700, Sean Whitton wrote: > > On Tue 30 Apr 2019 at 08:05AM +02, Ansgar wrote: > > > As an example: to update to a new upstream release, I ideally just have > > to drop the new upstream tarball, update d/changelog and am done. > > Compare with [1] which is much more c

Re: introduction of x-www-browser virtual package

Paul Wise writes: > On Tue, 2019-01-08 at 13:20 +0100, Bastien ROUCARIES wrote: >> I could add a sensible-x-www-browser to be more nice to our user to >> sensible-utils > > We already have a x-www-browser alternative, so sensible-x-www-browser > would just duplicate that and is thus not needed. No

Re: [Pkg-julia-devel] julia_1.0.0-1_amd64.changes REJECTED

Hi, Mo Zhou writes: > Another fortnight has passed. Any update? Sorry for taking so long; I wanted to put this on our meeting agenda, but currently don't find much time... Anyway, the package is now marked to be accepted. There were some misunderstandings on our side why debug symbols weren't s

Re: Extension of Built-Using:

On Wed, 2018-12-12 at 15:12 +, Alastair McKinstry wrote: > I've been looking at using the "Built-Using" tag for dh-fortran-mod. Why not a Fortran-Mod: gfortran-7, gfortran-8, flang-42 field or so? As another example Python has `Python-Version: 3.6, 3.7` (for packages where this matters; d

Re: wicd-daemon-run_1.0_amd64.changes REJECTED

Lorenz writes: > Ansgar Burchardt: >>As a possible alternative: ship the runscript and some metadata (which >>systemd service(s) and/or sysvinit script(s) this corresponds with; >>which system users would be needed; ...) either in the service package >>(preferred

Re: wicd-daemon-run_1.0_amd64.changes REJECTED

Dmitry Bogatov writes: > I believed (and still believe, despite of REJECT), that best way is > > 0. One source package, providing single binary package per runscript. > >src:{foo}-run -> bin:{foo}-run -> /etc/sv/{foo} We generally try to avoid tiny packages in the archive; having 1000+ automat

Re: Re: usrmerge -- plan B?

On Wed, 2018-11-28 at 09:45 +, Holger Levsen wrote: > 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 build

Re: usrmerge -- plan B?

On Fri, 2018-11-23 at 12:45 +, Ian Jackson wrote: > Russ Allbery writes ("Re: usrmerge -- plan B?"): > > This is a much better summary of the thread, and I wish that you would > > have said this instead of claiming incorrectly that those same people are > > the ones advocating for a full merge

individual packages moving binaries from /bin to /usr/bin (was: Re: usrmerge -- plan B?)

Russ Allbery writes: > Ansgar Burchardt writes: >> Moving files around in such a matter that they are still available in >> the old location (via a symlink) is not a very invasive change, so there >> is only a small risk of problems. > > I think it's fair to

Re: usrmerge -- plan B?

On Thu, 2018-11-22 at 13:56 +, Ian Jackson wrote: > Marco d'Itri writes ("Re: usrmerge -- plan B?"): > > On Nov 22, Ian Jackson wrote: > > > Marco d'Itri writes ("Re: usrmerge -- plan B?"): > > > > So far nobody reported anything significant. > > > > > > I hear there was a major free software

Re: Q: secure boot

On Tue, 2018-11-06 at 09:14 +0800, Paul Wise wrote: > AFAICT the Debian Secure Boot packages are not designed for the > scenario where only Debian keys or per-user keys are trusted by the > firmware, if they were then shim-signed would be named > shim-signed-microsoft and there would be a shim-sign

Re: Q: secure boot

On Tue, 2018-11-06 at 10:42 +, Holger Levsen wrote: > 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 no

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

Paul Wise writes: > 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 distributions are built. > > It might be feasible to

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

On Fri, 2018-10-19 at 11:35 +0200, Martin Steigerwald wrote: > Martin Steigerwald - 19.10.18, 10:57: > > That written, I estimate or guess that the people preferring to use > > another initialization system than the initialization system in > > Systemd are in the minority. Yet, this minority might

Re: "debian.pool.ntp.org" for Debian derivatives?

On Thu, 2018-10-18 at 13:57 +0200, Philipp Hahn wrote: > So my question is more like "is it okay to not change Debians default > NTP server selection", so the initial setup and those lazy enough to > not change the default get a sane time? I don't think Debian can answer that question and suggest

Re: You are not seriously considering dropping the support of sysVinit?!

free...@tango.lu writes: > If Debian drops sysVinit support I will drop Debian [...] > This is your last chance to do the right thing and announce the > removal of this fucking piece of shit malware(D) from Debian and go > back to sysVinit or openrc! So dropping sysvinit support will make you go a

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

On Tue, 2018-10-16 at 14:48 +0200, Philipp Kern wrote: > The question is: Is > the package buggy if it does not contain an init script but a systemd > unit and it seems to be the case. Note that there are a *lot* of useful > options in a systemd unit that would need emulation to make properly >

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

On Tue, 2018-10-16 at 09:57 +0200, Martin Steigerwald wrote: > Ansgar Burchardt - 16.10.18, 08:53: > > If some people consistently call others a "cancer", accuse them of > > "vandalizing" open source, spread obvious FUD and so on, then I don't > > th

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

Martin Steigerwald writes: > Ansgar Burchardt - 15.10.18, 16:03: >> Please no. I don't think it would help Debian to have toxic people >> maintain packages. >> >> (As an example, Devuan's infobot has fun facts like this one: >> "<+infobot>

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

On Mon, 2018-10-15 at 14:20 +0100, Jonathan Dowland wrote: > On Mon, Oct 15, 2018 at 06:56:50AM +0200, Petter Reinholdtsen wrote: > > I believe Andreas Henriksson is right, the packages are going to be > > removed unless someone with time and interest show up to take care of > > them. A good start

Re: Package not compatible with old systemd

On Wed, 2018-09-19 at 10:07 +0200, Wouter Verhelst wrote: > On Tue, Sep 18, 2018 at 10:45:45AM +0200, Ondrej Novy wrote: > > for example when files are overwritten. This is not case and Breaks > > "is enough". > > "Breaks" means "will cause the other package to fail". That isn't the > case here. A

Re: Should the weboob package stay in Debian?

Hi Jonathan, On Fri, 2018-07-20 at 07:47 +0100, Jonathan Dowland wrote: > On Fri, Jul 20, 2018 at 01:34:19PM +1000, Dmitry Smirnov wrote: > > On Friday, 20 July 2018 12:50:12 AM AEST Jonathan Dowland wrote: > > > Have you read Matthew Vernon's reply to OP in this thread? Does > > > that not > > >

Re: Should the weboob package stay in Debian?

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 everyone had similar views on what is offensive. In that case the maintainer

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

Marc Haber writes: > back in the sysvinit days, we used to have the following construct as > a common idiom in init scripts: > > |if [ -f /etc/default/foo ]; then > | . /etc/default/foo > |fi > > This is an immediate privilege escalation vulnerability in the case > that /etc/default/foo or /etc/de

Re: rkt

Dmitry Smirnov writes: > On Tuesday, 5 June 2018 5:11:31 PM AEST Ansgar Burchardt wrote: >> rkt is neither in testing nor stable... > > Unfortunately... However it is a static Golang binary with minimum external > run-time dependencies which makes it possible to reasonably saf

Re: concerns about Salsa

Dmitry Smirnov writes: > Do you think there will be a potential to move services to containers, > probably on "rkt" runtime[*] ? rkt is neither in testing nor stable... > [*]: Because Docker sucks... Does rkt then suck more because it depends on docker stuff (at least in Debian)? *scnr* Ansgar

Re: Bug#900286: ITP: spm -- simple password manager

On Tue, 2018-05-29 at 13:11 -0400, Nicholas D Steeves wrote: > On Mon, May 28, 2018 at 07:46:59PM +0200, Jakub Wilk wrote: > > * Paride Legovini , 2018-05-28, 17:33: > > > spm is a single fully POSIX shell compliant script > > [...] > > > In Debian the script will be installed as 'spm.sh' > > > >

Re: Want to make salsa advertise contact and source code details [and 1 more messages]

On Fri, 2018-05-25 at 18:57 +0100, Ian Jackson wrote: > Another way to achieve the effect I want would be to do it post-hoc in > a reverse proxy. I see that salsa is using Apache as a reverse proxy. > So perhaps the right answer is to do this in Apache. It seems quite > hacky, but if it's thought

Re: Want to make salsa advertise contact and source code details

On Fri, 2018-05-25 at 17:16 +0200, Geert Stappers wrote: > Not knowing who is "we", but the thing I want to says is > > Do not ask for a lighter load, > but ask for more shoulders to carry the load. Asking for a lighter load has given us the wheel, washing machines, dishwashers, computers, an

Re: Salsa Questions

On Wed, 2018-05-02 at 14:11 +0200, Jörg Frings-Fürst wrote: > - Becomes salsa the permissions as an open system like Alioth or does > it stay so steady? Sorry, I can't parse this question. > The background to the question is that at the moment I can not even > draw attention to the one project th

Re: problems in gjots2 and Debian

On Wed, 2018-04-18 at 10:45 -0400, The Wanderer wrote: > On 2018-04-18 at 05:55, Andrey Rahmatullin wrote: > > > On Wed, Apr 18, 2018 at 11:23:23AM +0200, Martin Steigerwald wrote: > > > > > As just someone who mostly maintains one package (fio - flexible > > > I/O tester) I can certainly underst

Re: Lucas Kanashiro and Athos Ribeiro salvaged my package

Scott Kitterman writes: > Personally, I think people should be more annoyed at the people doing > the hijacking than the one they did it to. I thought this is called "salvage" now? There might have been some miscommunications, but given an acceptable alternative is just requesting the removal of

nmap license is incompatible with GPL

Hi, [ BCC'ed maintainers of packages mentioned below ] Chris Lamb pointed out that nmap uses a special version of the GPL-2 which is incompatible with the standard GPL license: +--- | Because this license imposes special exceptions to the GPL, Covered | work may not be combined (even as part of

Re: Removing packages perhaps too aggressively?

peter green writes: >> If you do reintroduce it, please note the extra steps (reopening bugs >> in particular) > On that note one thing that doesn't seem to be easy/well documented is > how to go about finding the bugs that affected a package at the time > of it's removal. If I go to the bugs page

Re: Removing packages perhaps too aggressively?

Andrej Shadura writes: > On 01/02/18 09:40, Ansgar Burchardt wrote: >> Andrej Shadura writes: >>> On 31/01/18 21:01, Jeremy Bicha wrote: >>>>> Here you go, there's #871004 for you. Missed jessie, stretch, >>>>> not in testing, no uploads since

Re: Removing packages perhaps too aggressively?

Andrej Shadura writes: > On 31/01/18 21:01, Jeremy Bicha wrote: >>> Here you go, there's #871004 for you. Missed jessie, stretch, >>> not in testing, no uploads since the beginning of 2017. >> >> I don't think you'll get much sympathy for a package being removed >> from unstable when it hasn't shi

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

Simon McVittie writes: > On Sun, 07 Jan 2018 at 00:27:15 +0100, Ansgar Burchardt wrote: >> sysvinit probably only stays in testing because systemd >> depends on sysv-rc for compatability with LSB init scripts... > > I think it did during the default init system transition,

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

Adam Borowski writes: > On Sat, Jan 06, 2018 at 07:17:14PM +0100, Marco d'Itri wrote: >> On Jan 06, Simon Richter wrote: >> >> > As it is now, we have a lot of people who are maintaining their own >> > packages outside of Debian. Can we get enough support to reintegrate >> > both the people and th

Bug#886238: Please introduce official nosystemd build profile

On Wed, 2018-01-03 at 14:26 +0100, Samuel Thibault wrote: > > Do we really need systemd-less builds? I'm not convinced this is > > something relevant to Debian. > > Well, if Debian wants to remain relevant to downstreams, it'd be > better to accomodate their needs. I think there is only one distr

Re: allowed uses of non-baseline CPU extensions

On Mon, 2017-10-23 at 16:47 +0200, Adam Borowski wrote: > On Mon, Oct 23, 2017 at 04:36:11PM +0200, Julian Andres Klode wrote: > > sse2-support and other packages that fail to install can massively > > screw up systems, potentially leaving dpkg in a state that people > > cannot easily recover from

Re: Mandates explicit -std=c++XY for c++ projects

Mathieu Malaterre writes: > With this mind I'd like to make mandatory the -std=c++XY flags when > compiling either a c++ library or a stand-alone c++ program: > > 1. Either upstream define the explicit -std=c++XY flags by mean of its > build system, > 2. Or the package maintainers needs to explicit

Re: allowed uses of non-baseline CPU extensions

On Thu, 2017-10-05 at 03:23 +0100, Ben Hutchings wrote: > This should be unnecessary since gcc 6, as you can easily tell the > compiler to generate and select between multiple versions of the > functions. See . Having to identify interesting functions and add com

Re: Removal of upstart integration

Ian Jackson writes: > Alexandre Detiste writes ("Re: Removal of upstart integration"): >> Please also sprinkle these maintainers scripts with some >> >> rmdir /etc/init --ignore-fail-on-non-empty > > That should be > > rmdir --ignore-fail-on-non-empty /etc/init > > in case an environment vari

Re: ftp master uploads disappearing?

Hi, Norbert Preining writes: >> I now use dupload which does not have that kind of issues. > > Indeed, dupload worked right ahead. Thanks. dput should also allow uploads via rsync-over-ssh (or scp or sftp) which also allows resuming uploads. The default dput.cf doesn't include it, but I have +-

Re: Whether remotely running software is considered "software" for Debian.

"Dr. Bas Wijnen" writes: > Actually, that isn't so clear at all. At least when it comes to current > practice, I have yet to find any client for which nobody wrote a free server. > People keep implying that we have many such clients currently in main, but I > don't think we do. So there is no cl

Maintainer information in source packages (was: Re: Returning to the requirement that Uploaders: contain humans)

Hi, as a more radical change one could also ask the question where to maintain the maintainer information. Currently we handle this in the source package via the Maintainer and Uploaders field, and via team memberships. This has several limitations: for teams, Uploaders will often be useless (yo

Re: Bad interaction between pbuilder/debhelper/dpkg-buildinfo/dpkg-genchanges and dak on security-master

On Sun, 2017-07-09 at 15:41 +0100, James Clarke wrote: > Now, the issue here is not its presence, but its > name; however, I'd argue this is the correct name for it; it *is* a buildinfo > file for an amd64 build. And that has little to do with what ends up in the archive, unlike other files dak pr

Re: DEP 15: Reserved namespace for DD-approved non-maintainer changes

Sean Whitton writes: > I am hereby reserving DEP number 15 for my draft DEP, "Reserved > namespaces for DD-approved non-maintainer changes". > > I'd like to suggest discussing this DEP on d-devel (which is the > Reply-to for this e-mail). The canonical DEP text is at >

Too many Recommends (in particular on mail-transport-agent)

Hi, my impression is that too many packages use Recommends that should really be Suggests. As a random example: installing dracut as a initramfs provider will pull in exim4... (dracut-core Recommends: mdadm which Recommends: default-mta | mail-transport-agent). This seems really not ideal. As a

Re: substvars in *.install + friends

Hi, On Thu, 2017-05-04 at 17:14 +0200, Enrico Weigelt wrote: > is it possible to use the substvars mechanism for the *.install and > similar files, just like w/ control file ? > > For multi-version installations, I'm keeping the whole package in a > prefix w/ the version number (see my other mail

Re: Bug#761348: ftp.debian.org: need machine-readable metadata about suites & repositories

Hi, On Fri, 2017-04-21 at 09:28 +0200, Michael Stapelberg wrote: > pabs, what’s the current status on this? AFAICT, you mentioned you > wanted to come up with a spec on the RepositoryFormat wiki page. I > don’t > see that on the RepositoryFormat wiki page yet. > > Is there any way to help? > > I

Re: Release impact of introducing a new archive section?

Josh Triplett writes: > Given that, can you please go ahead and add the two new sections for > rust (https://bugs.debian.org/845576) and javascript > (https://bugs.debian.org/753480), and update the override file for > existing packages? These packages should move to the "rust" section: > rustc, c

Re: no-strong-digests-in-dsc MBF

Adrian Bunk writes: > I want to do a MBF for all packages without a SHA256 checksum field > in the .dsc [1] - only SHA1 as hash would not be good in stretch. Why? The Sources index should have a stronger hash either way. If you care about stronger hashes in the .dsc itself, wouldn't the .dsc its

Re: "not authorised" doing various desktoppy things [and 1 more messages]

On Fri, 2017-01-06 at 07:48 +0100, Adam Borowski wrote: > On Thu, Jan 05, 2017 at 12:19:08PM +0100, Ansgar Burchardt wrote: > > With elogind do you mean https://github.com/wingo/elogind?  That > > project doesn't look very active. > > > > Is there any active p

Re: "not authorised" doing various desktoppy things [and 1 more messages]

On Thu, 2017-01-05 at 11:22 +0100, Adam Borowski wrote: > Neither systemd-shim nor consolekit are solutions that are viable in > the long term, the sooner we get rid of both, the better.  I don't > know what's a good alternative, though.  Loginkit is > vapourware.  Elogind maybe? With elogind do y

Re: "not authorised" doing various desktoppy things [and 1 more messages]

Ian Jackson writes: > Michael Biebl writes ("Re: "not authorised" doing various desktoppy things"): > I'm not sure I need "logind integration" in my X server but perhaps I > do ? Only if you want to start X as non-root. > Simon McVittie writes ("Re: "not authorised" doing various desktoppy things

Re: Can we kill net-tools, please?

Josh Triplett writes: > Geert Stappers wrote: >> On Mon, Dec 26, 2016 at 02:50:50PM +0100, Marco d'Itri wrote: >> > ifconfig, route, etc... >> >> From https://packages.debian.org/stretch/arm64/net-tools/filelist >> >> * /bin/netstat > > The rest of net-tools aside (which have sensible replacemen

Re: dpkg no longer installs conffiles??

Hi Svante, On Tue, 2016-11-29 at 17:58 +0100, Svante Signell wrote: > After upgrading to sid the conffiles don't seem to be installed any > longer? I think it would be nice to make restoring the original configuration easier. The various --force-conf* options by dpkg are not easily discovered an

Re: misleading timestamps in binnmus

On Thu, 2016-11-10 at 11:33 +, Ian Jackson wrote: > Cyril Brulebois writes ("Re: misleading timestamps in binnmus"): > > Ian Jackson (2016-11-09): > > > What version of sbuild do buildds run ?  Ie, supposing that this > > > is > > > fixed in sbuild in stretch, will this be fixed on the buildds

Re: misleading timestamps in binnmus

On Wed, 2016-11-09 at 10:04 +0100, Sven Joachim wrote: > On 2016-11-08 22:30 -0200, Johannes Schauer wrote: > > It seems that sbuild indeed re-uses the timestamp from the last > > debian/changelog entry in the binNMU changelog entry. > > This has been done in an early attempt to make binNMUs co-in

Re: awesome, it's done! (Re: When should we https our mirrors?)

On Mon, 2016-10-24 at 16:30 +, Holger Levsen wrote: > On Mon, Oct 24, 2016 at 11:51:00AM -0400, Paul Tagliamonte wrote: > > https://deb.debian.org/ is now set up (thanks, folks!) > > whoohooo, & it works on stable too! apt install apt-transport-https > was > all it took. (and changing the entr

Re: Package name conflict question

"SZ Lin (林上智)" writes: > Although these packages are not API-compatible, they are using the > same installation path and file name; therefore, I think "Conflict:" > section is needed. Note that Policy explicitly forbids using "Conflicts" in this case, see the first paragraph in [1]. [1]

Re: Support for merged-/usr now in debootstrap; default for stretch?

On Tue, 2016-09-27 at 15:42 +0500, Andrey Rahmatullin wrote: > On Tue, Sep 13, 2016 at 10:36:58PM +0200, Ansgar Burchardt wrote: > > > > debootstrap in unstable can now install with merged-/usr, that is > > with > > /bin, /sbin, /lib* being symlinks to their co

Re: Support for merged-/usr now in debootstrap; default for stretch?

Ansgar Burchardt wrote: > debootstrap in unstable can now install with merged-/usr, that is > with > /bin, /sbin, /lib* being symlinks to their counterpart in /usr.  Run > >   debootstrap --merged-usr testing .../testing http://deb.debian.org/ > debian > > to give it a t

Support for merged-/usr now in debootstrap; default for stretch?

Hi, debootstrap in unstable can now install with merged-/usr, that is with /bin, /sbin, /lib* being symlinks to their counterpart in /usr. Run debootstrap --merged-usr testing .../testing http://deb.debian.org/debian to give it a try. It has been previously suggested to make this the default

Re: Is missing SysV-init support a bug?

On Fri, 2016-08-26 at 00:11 +0200, Sven Hartge wrote: > I just saw the new conntrack-tools (1:1.4.4-2) package in Sid, which > has as a change > >   * [917beed] conntrackd: get rid of the sysvinit support > > and I wondered, if this is a bug (and at what severity) or not. FWIW, there is now a re

Re: Is missing SysV-init support a bug?

On Thu, 2016-08-25 at 18:43 -0400, Robert Edmonds wrote: > I looked up the answer to this recently (because I wanted to do > exactly > what the conntrackd maintainer had done). > > The relevant text from the policy manual, §9.11: > > Packages may integrate with these replacement init systems

Re: Proposed mass bug filing: use and misuse of dbus-launch (dbus-x11)

On Thu, 2016-07-28 at 15:25 +0100, Simon McVittie wrote: > On Thu, 28 Jul 2016 at 08:33:21 -0400, Marvin Renich wrote: > > Do you mean metapackage or virtual package?  Wouldn't a virtual > > package > > be exactly the right thing for this?  Then dbus-user-session and > > dbus-x11 would each "Provid

Re: Per-user package configuration

Dmitry Bogatov writes: > I am working on runit process supervision suite, and I want to provide > user-local supervision support out-of-binary-package. User-local supervision > for > requires one file pre user in /etc. (Well, true is a > bit more complex, but nevermind). One extra will be spawned

unstable-debug and experimental-debug gone for a day

Hi, we moved /debian-debug/dists/unstable-debug to sid-debug and added a symlink unstable-debug -> sid-debug to have the debug suite for unstable also available via its codename. The same for experimental-debug -> rc-buggy-debug. Sadly this directory-to-symlink conversion confuses our mirror scri

Re: Neomutt packages available

Ian Jackson writes: > I don't think there is anything wrong with having a competing package. There is. I'm fairly sure the security team will not be happy... Packaging the *same* project twice seems even more useless busy work for them than packaging lots of forks of the same project (which some p

Re: Package tool with systemd dependency

On Tue, 2016-06-21 at 10:55 +0100, Simon McVittie wrote: > On Tue, 21 Jun 2016 at 11:11:09 +0200, Jan Luca Naumann wrote: > > I want to package a tool* which highly uses systemd and particulary > > its > > per-user service feature. > > By "per-user service" are you referring to systemd user servic

Re: experimental syslog-ng

Hi, Matt Zagrabelny writes: > It appears that the version of syslog-ng for mirrors of > ftp.us.debian.org's experimental repository is still at version > 3.6.1+git20141206-g4d90138-4+b1, while tracker.d.o is reporting that > the experimental version is at 3.7.1-3, and has been since Thu, 08 Oct >

Re: Bug#824884: netbase: should not recommend ifupdown

Henrique de Moraes Holschuh writes: > On Tue, May 24, 2016, at 13:03, Ansgar Burchardt wrote: >> On Tue, 2016-05-24 at 11:43 -0300, Henrique de Moraes Holschuh wrote: >> > On Tue, May 24, 2016, at 10:01, Simon McVittie wrote: >> > > On Tue, 24 May 2016 at 09:0

Re: Bug#824884: netbase: should not recommend ifupdown

On Tue, 2016-05-24 at 11:43 -0300, Henrique de Moraes Holschuh wrote: > On Tue, May 24, 2016, at 10:01, Simon McVittie wrote: > > > > On Tue, 24 May 2016 at 09:08:11 -0300, Henrique de Moraes Holschuh > > wrote: > > > > > > Whatever we do, we absolutely must bring up a fully configured > > > loop

Re: Debian i386 architecture now requires a 686-class processor

Ian Jackson writes: > IMO the way to read "is a bug RC" is "if the bug is not fixed, would > Debian be better without the package, than with the buggy package". > This calls for weighing the harm caused by the bug to the people > affected, against the benefit of the package to other users. > > In t

Re: Overall bitrot, package reviews and fast(er) unmaintained package removals

On Thu, 2016-04-07 at 15:29 +0200, Enrico Zini wrote: > On Thu, Apr 07, 2016 at 02:23:42PM +0100, Steve McIntyre wrote: > Definitely. But we still seem to have a few overly-territorial > > people > > failing to maintain their packages. Not 100% sure what to do about > > that, as that same subset of

Re: arch all package's missing dependency on i386 prevents testing migration

Neil Williams writes: > On Tue, 29 Mar 2016 21:25:26 -0700 > Afif Elghraoui wrote: >> The package in question, circlator, depends on two >> architecture-dependent packages that can only build on amd64 and >> kfreebsd-amd64 currently. The package cannot migrate to testing >> because those dependen

Re: dh_gencontrol debug symbol wrapper: no debian/-dbgsym, skipping package

Hi, Nico Schlömer writes: > I'd like to play around with the (new) auto dbgsym packages, and for > starters build Mixxx [1] on launchpad's Xenial environment (featuring > debhelper 9.20160115ubuntu2). Instead of an auto dbg package, however, I'm > getting > ``` > dh_gencontrol debug symbol wrapper

Re: default softphone in Debian stretch

Daniel Pocock writes: > On 15/01/16 14:20, Bas Wijnen wrote: >> On Fri, Jan 15, 2016 at 11:08:35AM +0100, Daniel Pocock wrote: >>> If there are meta-packages (e.g. sip-client, xmpp-client), should >>> any softphone be able to assert that it provides sip-client? Or >>> should there be some quality

Re: Going ahead with non-free-firmware

Paul Wise writes: > On Mon, Jan 11, 2016 at 5:23 PM, Ansgar Burchardt wrote: >> So you don't want another component, but something that looks like a >> component in some places only? I.e. it behaves like a component in that >> it gets its own Packages (and Sources?) i

Re: Going ahead with non-free-firmware

Stefano Zacchiroli writes: > On Mon, Jan 11, 2016 at 09:52:08AM +0100, Ansgar Burchardt wrote: >> dak doesn't really like having a package in multiple components: the >> layout of pool/ requires that the files would have to be duplicated. >> Then dak only knows that a &

Re: Going ahead with non-free-firmware

Stefano Zacchiroli writes: > On Sat, Jan 09, 2016 at 08:48:25PM +, Steve McIntyre wrote: >> Are we sure on the name? Previous commenters have suggested that >> "non-free/firmware" might be better. I understand that may be more >> awkward to implement in terms of directories... :-) > > If my re

Re: Going ahead with non-free-firmware

Paul Wise writes: > On Sat, Jan 9, 2016 at 6:51 PM, Ansgar Burchardt wrote: >> I think there was consensus to introduce the non-free-firmware section >> and move the non-free firmware blobs there. I'm wondering what we need >> to do next? > > I have a question ab

Going ahead with non-free-firmware

Hi, I think there was consensus to introduce the non-free-firmware section and move the non-free firmware blobs there. I'm wondering what we need to do next? Besides the ftp team setting the new section up, I expect the installer would need changes to enable it instead of non-free when non-free

Bug#810378: lintian: suggest to use https:// over git:// (was: Re: Death to git://! Long live git://!)

Package: lintian Severity: wishlist Paul Tagliamonte writes: > We still have `git://` all over the place, for instance, on Vcs-Git on > control files. That makes me sad. Boo insecure transports. > > `git://` is plaintext, and plaintext transports are bad. > > I'd like to suggest we move all Vcs-G

Re: support for merged /usr in Debian

Craig Small writes: > On Tue, Jan 05, 2016 at 03:55:51PM +, Ian Jackson wrote: >> What is causing all the heat is the suggestion that support might be >> withdrawn for currently working configurations which _do_ have a /usr >> vs / distinction, or which do mount /usr using / rather than >> ini

Bug#809705: general: let people use non-free software but opt-out of non-open software

Philippe Cerfon writes: > On Mon, Jan 4, 2016 at 8:45 AM, Niels Thykier wrote: >> Philippe Cerfon: >> Your second item has been brought up before with different >> focus/rationale/purpose. At least I remember there being an interest in >> splitting "non-free" into "non-free/firmware" vs. various

  1   2   3   4   >