Re: Re: Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

Barak A. Pearlmutter wrote: > You know, that's a pretty good idea! > > Put a 00README-TMP.txt in /tmp/ and /var/tmp/ which briefly states the > default deletion policy, the policy in place if it's not the default, > and a pointer to info about altering it. "/tmp's contents are deleted > at boot

Re: Re: [RFC] locking down rsyslog.service

Michael Biebl wrote: > - CAP_SYS_ADMIN: exceed /proc/sys/fs/file-max, the system-wide limit > on the number of open files, in system calls that open files (e.g. > accept execve), use of setns(),... I realize that you can't lock down things upstream still requires, but CAP_SYS_ADMIN is

sysadmin configuration of sparse-/etc vs prepopulated-/etc?

le want the ability to make this choice, and packages should integrate with such a mechanism rather than choosing on a package-by-package basis? - Josh Triplett

Re: Re: systmd-analyze security as a release goal

Simon McVittie wrote: > For example, dbus-daemon can only usefully have hardening applied if it > was built with traditional (non-systemd) service activation disabled, > which we cannot usefully do in Debian for two reasons: because we support > non-systemd init systems, and because we don't

Re: Second take at DEP17 - consensus call on /usr-merge matters

Russ Allbery wrote: > This is more of a high-level design intuition that stems from some basic > architectural principles, such as "dpkg should be the authority for what > Debian installs on the file system so that it can ensure global > consistency." > > But to give you a concrete answer, here

Using i386 by mistake on 64-bit hardware [was Re: i386 in the future 32-bit archs: a proposal)]

anges to the installer, let alone changes that require translations. Also, if we already have some detection like that, my apologies for missing it.) - Josh Triplett

Re: dropping Priority field from binary packages for most packages

Ansgar wrote: > could we drop the Priority field from most packages? Most packages use > "Priority: optional" and this is just noise in d/control (source > package). Tools should just assume "optional" when no other value is > set. This seems like a great idea. People regularly note the overhead

Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

r gzip to parse it" The x86-64 ABI is set. Feel free to make the case to the next architecture designer that their new ABI should have the dynamic linker in `/usr/lib`. That would *not* have the same downsides, as long as everyone agrees on a path. - Josh Triplett

Re: Configuration files, local changes, and "managed section" markers

Marc Haber wrote: > On Tue, 14 Feb 2023 11:23:55 -0800, Russ Allbery wrote: > >I think the right answer (which as is often the case involves a lot more > >work) is to break the configuration file into separate parts, one of which > >is a true configuration file in the Policy definition and the

Re: Presenting DPKG_ROOT

paces as non-root. As a bonus, testsuites could use an overlayfs instead of a read-only bind mount, and then check afterwards if *any* changes occurred in the overlay, which would be a test failure. Does that seem like a reasonable addition to the DPKG_ROOT support? - Josh Triplett

Re: adduser default for sgid home directories

Matt Barry wrote: > On Mon, 2022-07-25 at 14:37 +0100, Colin Watson wrote: > > On Sun, Jul 24, 2022 at 12:34:31PM -0400, Matt Barry wrote: > > > Anyway, its been released at this point, so the issue is moot :) > > > > Regardless of the rest of the discussion, this isn't entirely true. > > Yes,

Re: Q: systemd-timer vs cron

Michael Biebl wrote: > I'd agree here. user crontabs are such a niche case where systemd's > own facilities don't provide a direct replacement. > > That said, my main point was about packages shipping cron files. > > As a distro we'd benefit if those shipped native systemd timers > (instead or in

Re: Require packages to build without any configured DNS

Thomas Goirand wrote: > On 9/10/21 10:53 AM, Josh Triplett wrote: > > Thomas Goirand wrote: > >> On 9/8/21 6:01 PM, Josh Triplett wrote: > >>> Now, that said, if the build process actually wants a DNS server to > >>> run tests against, it sho

Re: Require packages to build without any configured DNS

Thomas Goirand wrote: > On 9/8/21 6:01 PM, Josh Triplett wrote: > > Now, that said, if the build process actually wants a DNS server to > > run tests against, it should provide or depend on such a DNS server, > > and configure it for such tests. > > Just to be 100%

Re: Require packages to build without any configured DNS

ide or depend on such a DNS server, and configure it for such tests. But a build process that's just *importing the dnspython library* should not need to have either /etc/resolv.conf *or* a functional DNS server. - Josh Triplett

Re: Arch triplet for uefi applications

sn't a "vendor", and the OS shouldn't be "none" since there is an OS of sorts. For that reason, Rust uses the target names "aarch64-unknown-uefi", "i686-unknown-uefi", and "x86_64-unknown-uefi". Those seem like the right names for these targets in other toolchains, as well. - Josh Triplett

Re: Need help with Multi-Arch in systemd

Helmut Grohne wrote: > So you made me thinking, can we somehow implement this with our > current spec? The most important requirements seem to be: > > * libsystemd-shared.so and /sbin/systemd need to reside in the same >binary package. > * It shall be possible to depend on

Re: Proposal: plocate as standard for bookworm

Steinar H. Gunderson wrote: > On Sat, Feb 06, 2021 at 10:16:29PM -0800, Josh Triplett wrote: > > locate is a purely user-facing tool, > > not really usable for portable scripting, since neither its presence nor > > its functioning can be assumed. > > Really? Basi

Re: Proposal: plocate as standard for bookworm

shouldn't make all users pay the cost of locate's database update to satisfy the subset of users who ever invoke locate. - Josh Triplett

Re: Package dependency versions and consistency

On Tue, Dec 29, 2020 at 03:19:30PM +0200, Adrian Bunk wrote: > [...] Rust [...] I did not bring up Rust, nor was I referring to Rust specifically, nor am I speaking for either Rust upstream or the work of the Rust team in Debian. There are *multiple* ecosystems in which the equivalent of

Bug#978600: Substantial increase in pseudo-Essential due to libnsl2 and libtirpc3 (and dependencies)

Package: libpam-modules Version: 1.4.0-1 Severity: normal X-Debbugs-Cc: j...@joshtriplett.org, debian-devel@lists.debian.org The new pam 1.4.0 has switched pam_unix from libnsl.so.1 (in libc6) to libnsl2 and libtirpc3, which brings those packages into the pseudo-Essential set. This is a rather

Re: Package dependency versions and consistency

Simon McVittie wrote: > On Sat, 26 Dec 2020 at 14:55:17 -0800, Josh Triplett wrote: > > I'm talking about packaging xyz 1.3.1 and 2.0.1, as separate xyz-1 and > > xyz-2 packages, and allowing the use of both in build dependencies. > > This is not all that rare even for C/C++

Re: /usr/bin/open now in use through the alternatives system.

Stig Sandbeck Mathisen wrote: >>> Le Sat, Oct 10, 2020 at 04:27:17AM +0900, Charles Plessy a écrit : Since `eog http://example.com/image.png` will open the image, shouldn't an "open" program ask to the server what the media type of the URL is, and pass it to the default program able

Re: Package dependency versions and consistency

On Mon, Dec 28, 2020 at 03:20:35PM +0200, Adrian Bunk wrote: > On Sat, Dec 26, 2020 at 02:55:17PM -0800, Josh Triplett wrote: > >... > > If you want to package abc version 1.2.3, and among many other things, > > abc depends on xyz version 2.1.4, and xyz has a new version 3.

Re: Package dependency versions and consistency

Adrian Bunk wrote: > On Fri, Dec 18, 2020 at 04:25:19PM -0800, Josh Triplett wrote: > >... > > I'm not suggesting there should be 50 versions of a given > > library in the archive, but allowing 2-4 versions would greatly simplify > > packaging, and would allow such

Package dependency versions and consistency

We can always file RC bugs on packages in the archive, and even remove packages later. Given all of the above improvements, it'd be much more feasible for tooling to help systematically unbundle and package dependencies, and to help manage and transition those dependencies in the archive. - Josh Triplett

Re: Allowed to build-depend a pkg in main on a pkg in non-free?

Roland Fehrenbacher wrote: > > "S" == Sven Joachim writes: > S> In addition, the packages in *main* > S> > S> * must not require or recommend a package outside of *main* for > S> compilation or execution (thus, the package must not declare a "Pre- > S> Depends",

Re: Allowed to build-depend a pkg in main on a pkg in non-free?

[Accidentally sent this early before it was finished.] Roland Fehrenbacher wrote: > > "S" == Sven Joachim writes: > S> In addition, the packages in *main* > S> > S> * must not require or recommend a package outside of *main* for > S> compilation or execution (thus, the

Re: Bug#969942: ITP: tty-share -- Terminal sharing over the Internet

Ansgar wrote: > Holger Levsen wrote: > > On Wed, Sep 09, 2020 at 06:27:28AM +, Francisco Vilmar Cardoso > > Ruviaro wrote: > > > * Package name: tty-share > > > Version : 0.6.2 > > > Upstream Author : Vasile Popescu > > > * URL :

Re: Bug#954313: dh_installchangelogs: provide option to strip off old changelog entries

ep only N entries maximum regardless of the above heuristic; that will help packages that have huge changelogs, or exclusively Debian revisions and no new upstream version. Does that sound like a reasonable default? - Josh Triplett

Re: RFC: Standardizing a new Protected field

an initramfs, etc.] This proposal looks great to me! I'm glad that it doesn't remove the requirement to declare dependencies; that makes it more feasible to carefully manage such packages without worrying about mysterious breakage. I'd love to see several of the packages currently marked Essential move over to using Protected instead. - Josh Triplett

Re: migration from cron.daily to systemd timers

Noah Meyerhans wrote: > Spamassassin has traditionally supplied a cron.daily script. I'd like > to provide the same functionality via a systemd timer, while still > providing cron as a fallback. For the most part, this is > straightforward, but there are a few details on which I'd like feedback.

Re: Be nice to your fellow Debian colleagues

gs-daemon 3.34.2-1 were just uploaded today, adding support for elogind. I have hopes that Debian's vaunted and venerable development processes will continue to produce good results, and I hope that the new decade sees developers healing and recovering from the last. - Josh Triplett

Re: Integration with systemd

Russ Allbery wrote: > Josh Triplett writes: > > Part of the problem is that the people interested in sysvinit don't tend > > to care about those features and often argue that others shouldn't care > > either, and the people interested in those features don't tend to care >

Re: Integration with systemd

Russ Allbery wrote: > One of the options that I find interesting is to enumerate a list of > features in unit files that Debian supports, and require that any > Debian init system be able to handle unit files with those features. > This standardzes an *API* for both package maintainers and

Re: Integration with systemd

On Wed, Oct 30, 2019 at 03:30:17PM -0400, Theodore Y. Ts'o wrote: > On Wed, Oct 30, 2019 at 05:14:02AM -0700, Josh Triplett wrote: > > Today, people can't use systemd persistent timers in place of cron (and > > in place of anacron's "wake up periodically" approach). You ha

Re: Integration with systemd

[Please CC me on replies.] Simon Richter wrote: > On Wed, Oct 30, 2019 at 05:14:02AM -0700, Josh Triplett wrote: > > If we're going to have a GR, part of the goal should be to either > > confirm the current state that we're never moving very far past the > > capabilities

Integration with systemd

part of the goal should be to either confirm the current state that we're never moving very far past the capabilities of sysvinit even when most people don't run it, or that we're allowed to use the full capabilities of our default init system even when there's no equivalent elsewhere. - Josh Triplett

Re: Seeking advice re: CVE-2019-13179 (insecure permissions for initramfs)

Jonathan Carter wrote: > Ah great, having a "/etc/initramfs-tools/conf.d/initramfs-permissions" > that contains "UMASK=0077" and running "update-initramfs -u" does fix > that for me locally, I think it should be reasonable to add that to the > calamares-settings package for Debian. > > Does anyone

Re: Unifying logging by default

On Thu, Feb 21, 2019 at 10:26:36PM +0100, Gabor Gombas wrote: > On Wed, Feb 20, 2019 at 02:44:37PM -0800, Josh Triplett wrote: > > > Both syslog and journald support multi-line log messages; I'd *love* to > > see /var/log/aptitude and /var/log/apt/history.log end up in sysl

Re: Unifying logging by default

On Wed, Feb 20, 2019 at 03:38:41PM -0800, Russ Allbery wrote: > Josh Triplett writes: > > Both syslog and journald support multi-line log messages > > syslog does not support multi-line log messages in any reasonable way. It > just escapes the newline (if you're lucky) and

Re: Unifying logging by default

On Wed, Feb 20, 2019 at 02:03:08PM -0800, Josh Triplett wrote: > While there are *absolutely* configurations in which system > administrators want to log to arbitrary locations and files, I would > like to propose that for consistency we should configure software to > unify logging

Re: Unifying logging by default

On Wed, Feb 20, 2019 at 11:53:24PM +0100, Guillem Jover wrote: > * The log data is "chroot" specific. This applies to all of the package > management logs. Logging into syslog would by default not do the right > thing and would be extremely confusing. I could see adding options > for dpkg

Re: Unifying logging by default

On Wed, Feb 20, 2019 at 02:19:02PM -0800, Russ Allbery wrote: > Josh Triplett writes: > > While there are *absolutely* configurations in which system > > administrators want to log to arbitrary locations and files, I would > > like to propose that for consistency we shou

Unifying logging by default

configure most applications for this default, we could introduce this into policy as a "should", but for now I'm seeking interest in slowly adapting applications to shift defaults to unified logging. - Josh Triplett

Re: Use of the Build-Conflicts field

Tollef Fog Heen wrote: > ]] Sean Whitton > > > There are two cases which we think that everyone would agree that there > > is a bug, but we are not sure that the bug would be considered to be RC. > > We are posting to -devel to see if, in fact, we do have a consensus that > > these bugs would be

Policy and procedures issue: init package hijacked via hostile NMU (declined by maintainers)

[Please don't CC me on responses, and please follow up solely to -devel rather than cross-posting.] Please note in the following mail that I'm raising this *exclusively* as a policy and procedures issue, *not* a technical issue. I would request that people *please* focus on the policy and

Re: Removing conflicts of init system

Dmitry Bogatov wrote: > [ I am not subscribed. Please keep me in CC. ] [I'm assuming that CCing the various init system @packages.debian.org addresses suffices?] > Currently, init system packages (sysvinit-core, runit-init, > systemd-sysv) are mutually exclusive -- each of them provides, > among

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

t doesn't, which seems questionable) is a bug. And it's absolutely a feature to have runit scripts and sysvinit scripts and configuration snippets of many sorts maintained in separate packages. - Josh Triplett

Re: usrmerge -- plan B?

and creates a /usr/usrtransition.d/packagename.conf file read by that boot-time mechanism. Then we know the transition will be handled correctly, and we won't have packages getting the details wrong and ending up with RC bugs. Sound reasonable? I'd be happy to work on that. - Josh Triplett

Re: Porting rust

On Tue, Nov 20, 2018 at 09:00:23PM +0100, Samuel Thibault wrote: > Hello, > > Josh Triplett, le lun. 05 nov. 2018 21:02:32 -0800, a ecrit: > > Speaking with an upstream Rust hat on in addition to a Debian hat: > > what could Rust do to make life easier for porters? > >

Re: Uncoordinated upload of the rustified librsvg

On Thu, Nov 08, 2018 at 06:28:29AM +0900, Mike Hommey wrote: > On Wed, Nov 07, 2018 at 01:21:44PM -0800, Josh Triplett wrote: > > > I have worked with the Rust upstream sources > > > well enough to know these issues. You have a regression in Rust 1.25 and > > >

Re: Uncoordinated upload of the rustified librsvg

On Wed, Nov 07, 2018 at 08:47:53PM +0100, John Paul Adrian Glaubitz wrote: > On 11/7/18 8:07 PM, Josh Triplett wrote: > >> Well, I wouldn't bet on that. I know that a lot of people have the > >> feeling that rewriting everything in Rust will solve all problems > >>

Re: Uncoordinated upload of the rustified librsvg

On Wed, Nov 07, 2018 at 11:53:06AM +0100, John Paul Adrian Glaubitz wrote: > Hello! > > > librsvg has rewritten substantial fractions of its code upstream in > > Rust. It won't be the last such library or package to do so. > > Well, I wouldn't bet on that. I know that a lot of people have the >

Re: Uncoordinated upload of the rustified librsvg

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 maintainer of > his package. This is not a

Re: Should libpam-elogind Provide libpam-systemd ?

Ian Jackson wrote: > tl/dr: would this be wrong >Package: libpam-elogind >Provides: libpam-systemd > and should there be a Conflicts too ? Please don't, no, for multiple reasons. First, various packages followed the widely offered advice of using libpam-systemd as the correct package to

Re: Questions about packaging systemd unit files

Theodore Y. Ts'o wrote: > Finally, if I have a systemd timer file, as well as a crontab entry, > what is the recommended way to decide whether to install/use the > crontab versus the timer unit file? Unfortunately, there isn't a clean mechanism for that. For systemd unit files, systemd's built-in

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

Wouter Verhelst 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. > > Yes. But adding a "nosystemd" build profile is in no way "invasive and > unmaintainable".

Re: Is missing SysV-init support a bug?

Russ Allbery wrote: > Josh Triplett <j...@joshtriplett.org> writes: > > Russ Allbery wrote: > >>> It does, however, mean that it's a good idea for us to continue to >>> support sysvinit. > >> Not quite. It means we should maintain support for sys

Re: Re: Is missing SysV-init support a bug?

Russ Allbery wrote: > m...@linux.it (Marco d'Itri) writes: > > On Dec 31, Simon Richter wrote: > > >> These are running stretch, and I would like to upgrade them without > >> breaking my existing scripts, which assume sysvinit with runlevels > >> (including one-shot runlevels).

Re: allowed uses of non-baseline CPU extensions

ux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=09642c1eb0869e8a9c075d0e8109f7ef1f62b320, with debug_info, not stripped - Josh Triplett

Re: Debian Policy 4.0.1.0 released

Anyone interested in helping with continued support for classic window managers should consider working on packaging for https://wiki.archlinux.org/index.php/Xdg-menu , and perhaps forming a maintenance team for it. And if it doesn't support your window manager or desktop of choice, consider

Re: MBF for deprecating Python2 usage

Scott Kitterman wrote: > Reintroducing /usr/bin/python as a python3 version risks their systems > for no benefit (since all python3 stuff points to /usr/bin/python3 and > works fine). Just let it go and don't bring it back. Agreed completely. /usr/bin/python -> python3 in Arch is an endless

Re: Naming of network devices - how to improve it in buster

Adam Borowski wrote: > Alas, having "bash-completion" installed, while adding some > context-sensitive completion, also breaks filename completion. You can always press Alt-/ if you want to use filename completion unconditionally. But if you run into a command that accepts filenames but for

Re: default config not in /etc [was: policy for shipping sysctl.d snippets in packages?]

Vincent Danjean wrote: > Perhaps, Debian can try to standardize this (for future releases), for > example asking to put the default config files in a central place (with > symlinks if required), for example /etc/default-config or even > /lib/default-config and/or /usr/lib/default-config. We

Re: policy for shipping sysctl.d snippets in packages?

Adam Borowski wrote: > On Mon, Apr 24, 2017 at 11:17:48AM +0200, Marco d'Itri wrote: > > While this scheme was probably instigated by limitations in RPM, at this > > point we have had multiple packages (kmod, systemd, udev for a start) > > using it for years. > > > > Moving the sysctl.d default

Re: policy for shipping sysctl.d snippets in packages?

On Sun, Apr 23, 2017 at 09:01:13PM +0200, Evgeni Golov wrote: > On Sun, Apr 23, 2017 at 11:40:34AM -0700, Josh Triplett wrote: > > On Sun, Apr 23, 2017 at 08:37:59PM +0200, Evgeni Golov wrote: > > > On Sun, Apr 23, 2017 at 10:48:33AM -0700, Josh Triplett wrote: > >

Re: policy for shipping sysctl.d snippets in packages?

On Sun, Apr 23, 2017 at 08:37:59PM +0200, Evgeni Golov wrote: > On Sun, Apr 23, 2017 at 10:48:33AM -0700, Josh Triplett wrote: > > Evgeni Golov wrote: > > > But this does not account for the fact that this specific tunable may be > > > already overriden in another sy

Re: policy for shipping sysctl.d snippets in packages?

Henrique de Moraes Holschuh wrote: > 1. read current levels (using sysctl, not directly). > > 2. if they are above the default, don't change the state of the system: >if your config file is there, let ucf handle its update normally. if >your config file is *NOT* there, assume deleted and

Re: policy for shipping sysctl.d snippets in packages?

o worry about that kind of configuration conflict unless it comes up. Ideally if multiple packages need to change this limit, they'll coordinate and agree on the new value, or perhaps even depend on a common configuration package. - Josh Triplett

Re: System libraries and the GPLv2

Carlos Alberto Lopez Perez wrote: > On 26/03/17 01:01, Walter Landry wrote: > > Florian Weimer wrote: > >>> #5 Declare GMP to be a system library. > >>> > >> (snip) > >> > >>> #5 was how Fedora looked at the OpenSSL library issue. Since Debian > >>> has another viewpoint on

Re: Depends/Recommends from libraries

Adam Borowski wrote: > I'd like to discuss (and then propose to -policy) the following rule: > > # Libraries which don't provide a convenient means of conditionally loading > # at runtime (this includes most libraries for languages such as C), SHOULD > # NOT declare a "Depends:" or "Recommends:"

Re: Non-free RFCs in stretch

"official" zlib. You can create your own version, and label it appropriately; the official version remains the official version. Changing a standards document doesn't change the standard. This really comes down to a question of endorsement: we determine whether a standards document represents the "official" version by looking at whether it has the endorsement of a particular standards body. - Josh Triplett

Re: De-Branding of Icedove, reintroducing Thunderbird packages into Debian

Mike Hommey wrote: > Why not just create a ~/.thunderbird symlink to ~/.icedove if > ~/.icedove exists? This seems like the right solution. (Or, equivalently, rename ~/.icedove to ~/.thunderbird and place a symlink in the other direction.) Any particular reason not to do this? - Josh Triplett

Re: [Pkg-rust-maintainers] Release impact of introducing a new archive section?

On Mon, Jan 23, 2017 at 08:56:31PM +0100, Ansgar Burchardt wrote: > 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 upd

Re: Release impact of introducing a new archive section?

On Fri, Dec 09, 2016 at 07:45:54AM +0100, Joerg Jaspert wrote: > On 14516 March 1977, Josh Triplett wrote: > > I've now written and submitted all of these patches. > > Thanks! > > Lets give it some time for them to get into packages and then we add > sections. Please ping

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

On Tue, 17 Jan 2017 13:35:14 + Ian Jackson wrote: > [1] AIUI this is when your laptop suspends to RAM, but after a timeout > or when the battery is low, wakes up so that it can suspend to disk. Linux implements hybrid sleep by going ahead and writing the

Re: Feedback on 3.0 source format problems

an improvement built around a non-VCS patches-and-tarballs world, not a VCS world. > Making everybody uses the same git workflow (like gbp pq) > would be better IMO, but I understand many will object. Not necessarily the same workflow, but the same repository layout. And yes, until a single repository layout exists that satisfies all requirements, people will object vehemently. Currently working on some improvements in that direction, to separate repository format from workflow. - Josh Triplett

Re: Feedback on 3.0 source format problems

Vincent Bernat wrote: > ❦ 2 janvier 2017 00:57 -0800, Josh Triplett <j...@joshtriplett.org> : > > > I don't want the source format to care about details like those. If > > people want to use quilt to manage a patch series within their > > packages, > > t

Re: Feedback on 3.0 source format problems

Guillem Jover wrote: > I'm interested in what things people still find so off-putting to the > point of not wanting to use the new 3.0 source formats, or what makes > people use them in anger and similar (if people would state which one > of these apply that would be helpful). All these including

Re: wording: "reverse dependence" vs "depender"

). Somewhat more verbose, but unambiguously clear. For instance, instead of "reverse-dependencies of libfoo-dev", I'd write "packages with Depends on libfoo-dev". - Josh Triplett

Re: Can we kill net-tools, please?

Russell Stuart wrote: > On Tue, 2016-12-27 at 01:02 -0800, Josh Triplett wrote: > > The rest of net-tools aside (which have sensible replacements), what > > replaces netstat in the absence of net-tools? > > /bin/ss, which is part of iproute2 Thanks, that looks perfect, and

Re: Can we kill net-tools, please?

what replaces netstat in the absence of net-tools? lsof can do a subset of its functions, but only a subset, and with much less useful output. - Josh Triplett

Re: compression support in kmod

ies to kmod. Does it speed up module loading at boot time (particularly for a distro kernel, which needs to load many modules)? I'd suggest testing both, and profiling system boot; if it speeds up boot time by any measurable amount, it seems worthwhile. - Josh Triplett

Re: Auto-detecting -dev package dependences from pkg-config

On Mon, Dec 12, 2016 at 10:10:57AM -0700, Sean Whitton wrote: > Hello Josh, > > On Sun, Dec 11, 2016 at 09:48:17PM -0800, Josh Triplett wrote: > > dpkg-shlibdeps automatically generates Depends on library packages > > corresponding to any libraries pulled in by the li

Accepted dh-cargo 1 (source all) into experimental, experimental

hanged-By: Josh Triplett <j...@joshtriplett.org> Description: dh-cargo - debhelper buildsystem for Rust crates using Cargo Changes: dh-cargo (1) experimental; urgency=medium . * Initial Release. Checksums-Sha1: 977b6942dc2896a7cc657af7e226ed063ca436fd 1583 dh

Auto-detecting -dev package dependences from pkg-config

n the other 1% of cases, -dev packages could provide some kind of mapping expression.) Does this seem like a reasonable approach? - Josh Triplett

Re: Release impact of introducing a new archive section?

On Sun, Dec 11, 2016 at 10:16:51PM +0100, Joerg Jaspert wrote: > On 14518 March 1977, Josh Triplett wrote: > >> (my first thought was a canonical online location, but these tools may > >> not want that at runtime and can't rely on it at build time, but maybe > >>

Re: Release impact of introducing a new archive section?

On Sun, Dec 11, 2016 at 09:45:36AM +, Ian Campbell wrote: > On Thu, 2016-12-08 at 21:39 -0800, Josh Triplett wrote: > > I've now written and submitted all of these patches. > > Might it be useful to have this list of names and descriptions in some > canonical

Re: Release impact of introducing a new archive section?

On Sat, Dec 10, 2016 at 04:46:01PM -0700, Sean Whitton wrote: > On Thu, Dec 08, 2016 at 09:39:26PM -0800, Josh Triplett wrote: > > Of the list of packages in > > https://lists.debian.org/debian-devel/2015/05/msg00287.html , aptdaemon > > no longer seems to exist in Debian,

Re: Release impact of introducing a new archive section?

On Fri, Dec 09, 2016 at 07:45:54AM +0100, Joerg Jaspert wrote: > On 14516 March 1977, Josh Triplett wrote: > > I've now written and submitted all of these patches. > > Thanks! > > Lets give it some time for them to get into packages and then we add > sections. Please ping

Re: Release impact of introducing a new archive section?

On Wed, Dec 07, 2016 at 03:05:21PM -0800, Josh Triplett wrote: > On Wed, Dec 07, 2016 at 09:36:00PM +, Niels Thykier wrote: > > Josh Triplett: > > > [Please CC me on replies.] > > > > > > [...] > > > > > > Does it seem reasonable t

Re: auto-removal and alternative dependencies

Daniel Pocock wrote: >On 08/12/16 16:59, Adam D. Barratt wrote: >> On 2016-12-08 13:08, Andreas Henriksson wrote: >>> On Thu, Dec 08, 2016 at 01:41:38PM +0100, Daniel Pocock wrote: On 08/12/16 13:35, Andrey Rahmatullin wrote: > On Thu, Dec 08, 2016 at 01:02:20PM +0100, Daniel

Re: Release impact of introducing a new archive section?

On Thu, Dec 08, 2016 at 05:55:37PM +0100, gregor herrmann wrote: > On Thu, 08 Dec 2016 08:44:15 -0800, Josh Triplett wrote: > > > While you are in there, there is #816693, also I'm unsure (and offline > > > atm) how many perl6 packages we currently have. > > As f

Re: Release impact of introducing a new archive section?

Holger Levsen wrote: > On Wed, Dec 07, 2016 at 03:05:21PM -0800, Josh Triplett wrote: > > If anyone has any objections to the creation of the two sections "rust" > > and "javascript", please speak up now, as I plan to start writing > > patches for

Re: Release impact of introducing a new archive section?

On Thu, Dec 08, 2016 at 07:46:23AM +0100, Joerg Jaspert wrote: > On 14515 March 1977, Josh Triplett wrote: > >> Longer version: I think we should patch the tools first and /if/ we are > >> in time before the release, we can add the sections. To my knowledge, > >&

Re: Release impact of introducing a new archive section?

On Wed, Dec 07, 2016 at 09:36:00PM +, Niels Thykier wrote: > Josh Triplett: > > [Please CC me on replies.] > > > > [...] > > > > Does it seem reasonable to attempt to introduce these new sections > > before the release, so that these pieces of softw

Release impact of introducing a new archive section?

rom the release team if they see negative effects on the release from such a change. - Josh Triplett

Re: Bug#846903: ITP: node-has-gulplog -- Check if gulplog is available before attempting to use it

easier than maintaining a permanent fork to avoid it. - Josh Triplett

Re: unattended-upgrades by default?

e with the admin to choose an appropriate time. However, I'd also suggest that more services and service management tools need mechanisms for zero-downtime upgrades. For instance, with some care, services running via socket activation can restart without losing any connections. - Josh Triplett

  1   2   3   4   >