Re: Potentially insecure Perl scripts

On 2019-01-23 15:32:00 +, Ian Jackson wrote: > This is completely mad and IMO the bug is in perl, not in all of the > millions of perl scripts that used <> thinking it was a sensible thing > to write. I agree that it would be better to drop this "feature" of Perl. It is probably never used, an

Re: Potentially insecure Perl scripts

On 2019-01-23 17:23:10 +0100, Alex Mestiashvili wrote: > On 1/23/19 4:44 PM, Vincent Lefevre wrote: > > On 2019-01-23 15:32:00 +, Ian Jackson wrote: > >> This is completely mad and IMO the bug is in perl, not in all of the > >> millions of perl scripts that used &l

Re: Potentially insecure Perl scripts

On 2019-01-24 11:12:43 +0100, Alex Mestiashvili wrote: > On 1/24/19 2:40 AM, Vincent Lefevre wrote: > But I disagree that a language can be considered insecure, just because Note: just a feature, not the language itself. > it lets you shoot in the foot. > The first thing I learned wh

Re: Potentially insecure Perl scripts

On 2019-01-24 09:46:56 +0100, Ansgar wrote: > But "<>" isn't the only problem, there are way too many uses of the > two-argument form of Perl's "open" too... Perhaps, but at least "open" had correctly been documented since the beginning, and I quickly learnt to preprend "<" to the filename in the

Re: Potentially insecure Perl scripts

On 2019-01-24 11:18:06 +0100, Adam Borowski wrote: > On Thu, Jan 24, 2019 at 04:41:29AM +, Ben Hutchings wrote: > > On Wed, 2019-01-23 at 09:07 -0800, Russ Allbery wrote: > > > Ian Jackson writes: > > > > Apparently this has been klnown about for EIGHTEEN YEARS > > > > https://rt.perl.org/Pu

Re: Potentially insecure Perl scripts

On 2019-01-24 15:18:40 +, Ian Jackson wrote: > Ian Jackson writes ("Re: Potentially insecure Perl scripts"): > > The right answer is to fix the behaviour to be secure and sane by > > default. We can arrange for an environment variable for people who > > want to turn the crazy back on. > > To

Re: Potentially insecure Perl scripts

On 2019-01-25 13:55:47 +, Ian Jackson wrote: > The easiest way to sanitise a string to make it safe for 2-argument > open involves: > * prepending ./ if the string does not start with / > * appending \0 (a nul byte) > The result is also a valid operand for 3-argument open. However, the null

Re: Potentially insecure Perl scripts

On 2019-01-25 10:36:42 +, Dominic Hargreaves wrote: > Also, I think it's worth trying to identify what the worst extent > of the issue is. Whilst I don't agree with some who say that this isn't > a security issue at all, I don't know of any real-world cases where > it would be exploitable for r

Re: Potentially insecure Perl scripts

[resent with group-reply, sorry] On 2019-01-25 10:36:42 +, Dominic Hargreaves wrote: > Also, I think it's worth trying to identify what the worst extent > of the issue is. Whilst I don't agree with some who say that this isn't > a security issue at all, I don't know of any real-world cases whe

Re: Debian, so ugly and unwieldy!

On 2019-06-07 17:24:17 +0200, Adam Borowski wrote: > * CSD is still a thing. No, your special program shouldn't get to ignore > system theme, put controls in wrong order, miss some controls, not respond > to minimize/etc if it's currently busy, etc. Consistency not one-off > designs. > >

Bug#930908: general: incorrect rules for %s in /etc/mailcap yielding potentially unquoted metacharacters

Package: general Severity: grave Tags: security Justification: user security hole Affects: mutt The /etc/mailcap file contains many rules with '%s' instead of %s, for instance: text/*; less '%s'; needsterminal audio/ogg; ogginfo '%s'; copiousoutput This is incorrect. For instance, Mutt quotes th

Bug#930908: general: incorrect rules for %s in /etc/mailcap yielding potentially unquoted metacharacters

On 2019-06-22 10:51:35 +0200, Vincent Lefevre wrote: [...] > as seen in strace output: > > execve("/home/vinc17/bin/sh.screen", ["sh", "-c", "less > ''/var/tmp/_.txt''"], 0x564ffe666f40 /* 132 vars */) = 0 FYI, the sh.

Bug#930908: general: incorrect rules for %s in /etc/mailcap yielding potentially unquoted metacharacters

On 2019-06-22 10:51:35 +0200, Vincent Lefevre wrote: > execve("/home/vinc17/bin/sh.screen", ["sh", "-c", "less > ''/var/tmp/_.txt''"], 0x564ffe666f40 /* 132 vars */) = 0 > > i.e. the filename is eventually not quoted! &

Bug#930908: general: incorrect rules for %s in /etc/mailcap yielding potentially unquoted metacharacters

On 2019-06-22 10:51:35 +0200, Vincent Lefevre wrote: > The /etc/mailcap file contains many rules with '%s' instead of %s, > for instance: > > text/*; less '%s'; needsterminal > audio/ogg; ogginfo '%s'; copiousoutput > > This is incorrect.

nvidia-graphics-drivers-legacy-390xx uploaded 8 days ago but not yet installed

Hi, Bug 1042892 in nvidia-legacy-390xx-kernel-dkms was fixed on 2 August, and the packages for amd64 and i386 were built 8 days ago, but they are still in the "Uploaded" state (contrary to armhf): https://buildd.debian.org/status/package.php?p=nvidia-graphics-drivers-legacy-390xx What happens?

Re: Potential MBF: packages failing to build twice in a row

On 2023-08-13 16:32:03 -0500, John Goerzen wrote: > - Upstream wants to ship things that may get modified during build. Ie, > autoconf/automake replaces files they ship because they want it to > work "out of the box" in some fashion. Another example is > documentation; upstream may ship bui

Re: Potential MBF: packages failing to build twice in a row

On 2023-08-15 09:38:32 +0200, Lucas Nussbaum wrote: > On 15/08/23 at 01:29 -0400, Michael Stone wrote: > > we don't know, since the test was "regenerate source"--a thing very few > > people care about--rather than "build twice" which is the thing people do > > seem to care about. It seems likely th

Re: mutt removed from testing while the bug was closed (fixed)

On 2023-10-26 02:03:49 +0200, Vincent Lefevre wrote: > Hi, > > I've seen on https://tracker.debian.org/pkg/mutt that mutt was > removed from testing on 2023-10-25, with a link to > > https://tracker.debian.org/news/1473564/mutt-removed-from-t

mutt removed from testing while the bug was closed (fixed)

Hi, I've seen on https://tracker.debian.org/pkg/mutt that mutt was removed from testing on 2023-10-25, with a link to https://tracker.debian.org/news/1473564/mutt-removed-from-testing/ which says: -- FYI: The status of the mutt s

usrmerge breaks POSIX

POSIX says: SHELL This variable shall represent a pathname of the user's preferred command language interpreter. If this interpreter does not conform to the Shell Command Language in XCU Chapter 2 (on page 2345), utilities may behave differently from tho

Re: usrmerge breaks POSIX

On 2024-02-14 19:46:58 +0100, Ansgar 🙀 wrote: > Hi Vincent, > > On Wed, 2024-02-14 at 18:20 +0100, Vincent Lefevre wrote: > > POSIX says: > > > >   SHELL   This variable shall represent a pathname of the user's > >   preferred command lan

Re: usrmerge breaks POSIX

On 2024-02-14 10:41:44 -0800, Russ Allbery wrote: > Vincent Lefevre writes: > > > POSIX says: > > > SHELL This variable shall represent a pathname of the user's > > preferred command language interpreter. If this interpreter > >

Re: usrmerge breaks POSIX

On 2024-02-14 17:16:23 -0800, Russ Allbery wrote: > I have literally no idea what you're talking about. It would be really > helpful if you would describe what program rejected your setting and what > you expected to happen instead. Quoting https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817168

Re: usrmerge breaks POSIX

On 2024-02-15 09:39:51 +0100, Marc Haber wrote: > On Thu, 15 Feb 2024 00:05:36 +0100, Vincent Lefevre > wrote: > >This is invalid. See > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817168 > > That doesnt answer the question asked, it is a bug from 20

Re: usrmerge breaks POSIX

On 2024-02-15 16:59:28 +, Holger Levsen wrote: > On Thu, Feb 15, 2024 at 10:08:11AM +0100, Vincent Lefevre wrote: > > Not for mksh. > > so the subject should be "mksh is broken with usrmerge"? No, because my bug report about mksh was closed because it is not

Re: usrmerge breaks POSIX

On 2024-02-15 09:00:57 -0800, Russ Allbery wrote: > I think the obvious solution is to ensure that both the /bin and /usr/bin > paths for mksh are registered in /etc/shells. In other words, I think we > have a missing usrmerge-related transition here that we should just fix. > I'm copying Thorsten

Re: usrmerge breaks POSIX

On 2024-02-15 17:18:43 +, Thorsten Glaser wrote: > Russ Allbery dixit: > > >3. Something else that I don't yet understand happened that caused pkexec > > to detect the shell as /usr/bin/mksh instead of /bin/mksh. I'm not > > What sets $SHELL for the reporter’s case? Fix that instead. $SHE

Re: usrmerge breaks POSIX

On 2024-02-15 14:14:46 -0800, Russ Allbery wrote: > Thorsten Glaser writes: > > > Right… and why does pkexec check against /etc/shells? > > pkexec checks against /etc/shells because this is the traditional way to > determine whether the user is in a restricted shell, Could you explain? This see

Re: usrmerge breaks POSIX

On 2024-02-15 16:17:58 -0800, Russ Allbery wrote: > Vincent Lefevre writes: > > On 2024-02-15 14:14:46 -0800, Russ Allbery wrote: > > >> and pkexec is essentially a type of sudo and should be unavailable to > >> anyone who is using a restricted shell. > >

Re: usrmerge breaks POSIX

On 2024-02-15 16:30:25 -0800, Russ Allbery wrote: > I was only able to find this discussion of why pkexec checks $SHELL, and > it doesn't support my assumption that it was an intentional security > measure, so I may well be wrong in that part of my analysis. Apologies > for that; I clearly should

possible issues with downgrading and *.md5sums (was: Bug#1065022: libglib2.0-0t64: t64 transition breaks the systems)

[to debian-devel only] On 2024-03-01 10:13:18 +0100, Helmut Grohne wrote: > On Thu, Feb 29, 2024 at 06:53:56AM +0100, Paul Gevers wrote: > > Well, officially downgrading isn't supported (although it typically works) > > *and* losing files is one of the problems of our merged-/usr solution (see > >

Re: On merging bin and sbin

On 2024-02-28 12:25:13 +0100, Ansgar 🙀 wrote: > I totally agree: we should aim at moving all service binaries such as > daemons which are not directly invoked by users out of PATH to > /usr/lib{,exec} or similar to make shell completion more helpful. I disagree. The goal should not be to make shel

Re: Policy: should libraries depend on services (daemons) that they can speak to?

On 2024-01-15 11:15:32 -0500, Theodore Ts'o wrote: > For example, when I implemented libuuid, if you want to create a huge > number of UUID's very quickly, because you're a large enterprise > resource planning application, the the uuidd daemon will allow > multiple processes to request "chunks" of

Re: Policy: should libraries depend on services (daemons) that they can speak to?

On 2024-03-06 06:29:24 +0100, Jonas Smedegaard wrote: > Quoting Arnaud Rebillout (2024-03-06 02:26:00) > > However it's true that some packages are installed before that, at the > > debootstrap stage, and I guess debootstrap doesn't honor "Recommends:"? > > Correct. This is tracked as bug#742977

salsa web server broken?

Is the salsa web server broken? The display of https://salsa.debian.org/python-team/packages/fail2ban is completely wrong, and https://salsa.debian.org/ gives an error 500 "We're sorry. Something went wrong on our end.". -- Vincent Lefèvre - Web: 100% accessible valida

Re: salsa web server broken?

On 2024-05-24 11:51:15 +0200, Alexander Wirt wrote: > Am Fri, May 24, 2024 at 11:23:44AM +0200 schrieb Vincent Lefevre: > > Is the salsa web server broken? > > > > The display of https://salsa.debian.org/python-team/packages/fail2ban > > is completely wrong, and https:/

Re: Y2038-safe replacements for utmp/wtmp and lastlog

On 2024-05-08 16:53:53 +0800, Jun MO wrote: > For last(1) my concern is that it will be helped to keep the original > last(1) for back-compatibility to read old wtmp files. I agree, this may be useful. Unfortunately, the current status is that one cannot have both: installing wtmpdb forces the upg

Re: Bug#1068017: Y2038-safe replacements for utmp/wtmp and lastlog

On 2024-05-30 18:41:51 +0200, Chris Hofstaedtler wrote: > wtmpdb takes over the "last" name. Unfortunately without support for > reading the old files. Nobody wrote tooling to import them or so. In the new versions of the package, "last" could have been installed under another name (e.g. last-lega

Re: Y2038-safe replacements for utmp/wtmp and lastlog

On 2024-05-31 01:05:51 +0800, Jun MO wrote: > And if I understood correctly, wtmpdb require program use PAM to update > wtmpdb, thus program not use PAM will still write /var/log/wtmp. For > example, tmux write /var/log/wtmp via libutempter0 and I do not see tmux > depends on pam. GNU Screen and x

Re: Proposal: plocate as standard for bookworm

On 2021-02-09 22:12:31 +0100, Ansgar wrote: > "Steinar H. Gunderson" writes: > > On Sat, Feb 06, 2021 at 10:16:29PM -0800, Josh Triplett wrote: > >> Furthermore, any mechanism they use to configure one of them > >> (e.g. for privacy or performance reasons) will not control the other, > >> and again

inconsistent mailgraph settings

My bug report https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989734 has been closed again, with no explanations. While mailgraph was started on boot in the past, this stopped working with the upgrade to Debian 10, and I had to enable it again. So issues with the upgrade to Debian 11, but the ma

Re: Q: Use https for {deb,security}.debian.org by default

On 2021-08-20 12:11:30 -0700, Russ Allbery wrote: > The most naive attempt to mess with the update channel (intercepting the > http connection and replacing a package with a malicious one) will fail > immediately with both http or https. The primary difference in that case > with https is that the

Re: BTS not archiving Bcc: mails? [was: Re: inconsistent mailgraph settings]

On 2021-08-22 23:32:15 +0500, Andrey Rahmatullin wrote: > On Sun, Aug 22, 2021 at 08:25:41PM +0200, Tomas Pospisek wrote: > > Wouldn't the Bcc'ed email that arrived to the BTS be visible in the bug's > > log/archive (on the bug's page (https://bugs.debian.org/989734))? > It's visible: https://bugs.

Re: inconsistent mailgraph settings

On 2021-08-21 10:36:04 +0200, Tomas Pospisek wrote: > In particular it *seems* to work for him and he doesn't have access to your > system where things apparently went wrong so it could be really hard for him > to know. So what you can do is to try to debug *yourself* why the upgrade > went wrong a

Re: BTS not archiving Bcc: mails? [was: Re: inconsistent mailgraph settings]G

On 2021-08-23 07:43:07 +0100, Tim Woodall wrote: > On Mon, 23 Aug 2021, Holger Wansing wrote: > > Am 23. August 2021 07:19:26 MESZ schrieb Tomas Pospisek > > : > > > > > > The thing is, if you close a bug report via `Bcc: > > > -cl...@bugs.debian.org` then the mail that arrives at the

Re: build-depend on autoconf-archive and rm convenience copy in orig.tar.gz?

On 2022-01-19 11:03:15 -0800, Russ Allbery wrote: > Jonas Smedegaard writes: > > > Thanks for elaborating. > > > The concern is not licensing, but maintenance. It is covered in Debian > > Policy § 4.13: > > https://www.debian.org/doc/debian-policy/ch-source.html#embedded-code-copies > >

rebuild of rpcbind (and other packages?) due to old debhelper bug 993316

Hi, Due to the old bug 993316 in debhelper[*], rpcbind is still buggy as it hasn't been rebuilt yet: rpcbind_1.2.6-2_amd64.deb contains -rw-r--r-- root/root 626 2021-08-17 17:31:36 ./usr/lib/systemd/system/rpcbind.service -rw-r--r-- root/root 325 2021-08-17 17:31:36 ./usr/lib/system

Re: rebuild of rpcbind (and other packages?) due to old debhelper bug 993316

On 2022-04-08 18:55:14 +0500, Andrey Rahmatullin wrote: > On Fri, Apr 08, 2022 at 03:22:07PM +0200, Vincent Lefevre wrote: > > Bug 993316 was fixed on 23 September 2021. Any reason why rpcbind > > hasn't been rebuilt yet? > Was anything done for that to happen? Because

use of Recommends by vlc to force users to use pipewire

The vlc package now uses a Recommends (vlc-plugin-pipewire) to force users to use pipewire instead of pulseaudio (which broke the use of VLC, but also apparently ogg123 with the alsa device). IMHO, this is a bad use of Recommends. It is not up to applications to choose what sound server to use, eve

Re: use of Recommends by vlc to force users to use pipewire

On 2022-05-16 00:56:03 +0200, Sebastian Ramacher wrote: > On 2022-05-16 00:40:25 +0200, Vincent Lefevre wrote: > > The vlc package now uses a Recommends (vlc-plugin-pipewire) to force > > users to use pipewire instead of pulseaudio (which broke the use of > > VLC, but also a

Re: use of Recommends by vlc to force users to use pipewire

On 2022-05-16 16:14:02 +, Bill Allombert wrote: > On Mon, May 16, 2022 at 12:56:03AM +0200, Sebastian Ramacher wrote: > > And for the record: you get pipewire installed because libpipewire-0.3-0 > > recommends it. > > For a similar situation, I advocated to add a apt option so that apt > only

Re: use of Recommends by vlc to force users to use pipewire

On 2022-05-17 08:54:59 -0400, Marvin Renich wrote: > There is, unfortunately, a catch here. In order for any of the > applications that require a sound server to work, one of them must be > installed. For example, mpd links with libasound, libpipewire, and > libpulse. If each of these libs simpl

Re: use of Recommends by vlc to force users to use pipewire

On 2022-05-26 20:08:22 +0100, Simon McVittie wrote: > On Thu, 26 May 2022 at 17:21:27 +0200, Vincent Lefevre wrote: > > Here, this could be > > > > Recommends: pipewire | pulseaudio > > Those are not interchangeable. > > pipewire started as a multiplexer

Re: use of Recommends by vlc to force users to use pipewire

On 2022-05-26 23:55:02 +, Alberto Garcia wrote: > On Fri, May 27, 2022 at 01:03:57AM +0200, Jonas Smedegaard wrote: > > > It was actually due to a problem in Evolution that we made WebKitGTK > > > depend on xdg-desktop-portal (later downgraded to a recommendation): > > > > > > https://bugzilla

Re: use of Recommends by vlc to force users to use pipewire

On 2022-05-27 12:34:26 +0100, Simon McVittie wrote: > If vlc-plugin-pipewire is prioritized higher than other audio backends, > then I can see how that could happen. It's probably premature for > vlc-plugin-pipewire to be prioritized higher than PulseAudio or ALSA in > Debian. > > The dependency g

Re: use of Recommends by vlc to force users to use pipewire

On 2022-05-28 10:41:34 +0200, Sebastian Ramacher wrote: > On 2022-05-28 01:27:13 +0200, Vincent Lefevre wrote: > > On 2022-05-27 12:34:26 +0100, Simon McVittie wrote: [...] > > > That's needed for Bluetooth audio, *if* you are using Pipewire for audio, > > > whic

Re: use of Recommends by vlc to force users to use pipewire

On 2022-05-30 14:30:38 +0200, Dylan Aïssi wrote: > Le lun. 30 mai 2022 à 12:55, Jonas Smedegaard a écrit : > > a) pipewire package enables pipewire service by default > > Indeed, but pipewire service doesn't take control of audio over > pulseaudio. Only pipewire-pulse does that. This is incorre

Re: use of Recommends by vlc to force users to use pipewire

On 2022-05-31 14:04:18 +0500, Andrey Rahmatullin wrote: > On Tue, May 31, 2022 at 10:55:55AM +0200, Vincent Lefevre wrote: > > > > a) pipewire package enables pipewire service by default > > > > > > Indeed, but pipewire service doesn't take control of audi

Re: use of Recommends by vlc to force users to use pipewire

On 2022-05-31 11:43:06 +0200, Vincent Lefevre wrote: > Anyway, when I upgraded the vlc package two weeks ago, this had the > effect that PulseAudio was no longer used as the sound server (for > both vlc and ogg123), though pipewire was already installed (due to > a Recommends from lib

Re: use of Recommends by vlc to force users to use pipewire

On 2022-05-31 14:55:44 +0500, Andrey Rahmatullin wrote: > On Tue, May 31, 2022 at 11:43:06AM +0200, Vincent Lefevre wrote: > > Indeed, this is what happened with pipewire 0.3.39-1, as I can see > > in my dpkg logs and the changelog: > > > > * Change priority order bet

Re: transition announcement: gsfonts + gsfonts-x11 -> fonts-urw-base35

Hi, On 2022-08-28 16:55:04 +0200, Fabian Greffrath wrote: [...] > A preliminary package fonts-urw-base35_20200910-3 to enable the > transition can be found in experimental, So, in case anyone want to > check how the transition works out, any help will be appreciated [5]. [...] > PS: Please keep me

Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio

On 2022-09-08 17:58:25 +0200, Dylan Aïssi wrote: > We cannot talk about PipeWire without mentioning its session manager. > Thus, this change should go along the switch of the default session manager, > i.e. from the deprecated pipewire-media-session to WirePlumber. > We still use pipewire-media-ses

Bug#1021750: general: the nodelalloc mount option should be used by default for ext4 in /etc/fstab

Package: general Severity: normal The /etc/fstab file is created using by default ext4 with just the errors=remount-ro option. However, the Debian FAQ recommends the nodelalloc mount option to avoid performance degradation and preserve data safety: https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Why_is

Bug#1021750: general: the nodelalloc mount option should be used by default for ext4 in /etc/fstab

On 2022-10-14 11:59:09 +0200, Marco d'Itri wrote: > On Oct 14, Vincent Lefevre wrote: > > > The /etc/fstab file is created using by default ext4 with just > > the errors=remount-ro option. However, the Debian FAQ recommends > > the nodelalloc mount option to avoi

Bug#1021750: general: the nodelalloc mount option should be used by default for ext4 in /etc/fstab

On 2022-10-14 12:44:25 +0200, Marco d'Itri wrote: > On Oct 14, Vincent Lefevre wrote: > > > This is not "the Debian FAQ" but "the DPKG FAQ", which has been known to > > > recommend awful things in the past. > > But it is still considered

Re: Mass bug filing: dependencies on GTK 2

On 2020-04-29 18:37:50 +0100, Simon McVittie wrote: > Given GTK 2's lack of feature development (for things like HiDPI) it > seems higher-severity than "a problem which doesn't affect the package's > usefulness", and it's certainly not "presumably trivial to fix" in > many cases. Note that missing

Re: TMPDIR - Do we also need a drive backed TPMDIR ?

On 2016-07-21 18:19:43 +0530, Ritesh Raj Sarraf wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On Thu, 2016-07-21 at 13:15 +0100, Neil Williams wrote: > > > Now, back to the actual problem. For many applications, we rely on > > > the TMPDIR environments. Tools like Python's modules

Re: TMPDIR - Do we also need a drive backed TPMDIR ?

On 2016-07-21 15:24:10 +0200, Philip Hands wrote: > It's configurable. > > See TMPFS_SIZE in /etc/defaults/tmpfs If you mean /etc/default/tmpfs, it doesn't work with systemd (as documented), and there's the global problem with swap. > And it'll cheerfully use swap, so just make sure you have eno

Re: TMPDIR - Do we also need a drive backed TPMDIR ? [and 1 more messages]

> Vincent Lefevre writes ("Re: TMPDIR - Do we also need a drive backed TPMDIR > ?"): > > On 2016-07-21 18:19:43 +0530, Ritesh Raj Sarraf wrote: > > > Swap will come into effect when the kernel needs more memory. > > > > Anyway, even if it had wo

Re: TMPDIR - Do we also need a drive backed TPMDIR ? [and 1 more messages]

On 2016-07-21 21:53:11 +0100, Ben Hutchings wrote: > It's true that if the system has to swap a lot of data out then it is > likely to become unresponsive.  However, I think there are good reasons > to enable a small amount of swap space: > > - Some long-running applications have, effectively, mem

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

On 2016-07-28 01:03:04 +0100, Simon McVittie wrote: > libdbus-1-3 shouldn't depend on a session bus, because you might only > be using it to access the system bus; Or because the user might not use the system bus at all, but the application depends on libdbus-1-3 it because it's a library and uses

Re: ifupdown2: debconf followup

On 2016-08-01 16:43:27 +0100, Simon McVittie wrote: > This seems reasonable. I think NM is a better choice than ifupdown for > roaming client devices (e.g. laptops), and systemd-networkd is a good > choice for "infrastructure" devices like servers and NAS boxes. I don't have any problem with ifupd

Re: spammers closing bugs in BTS

On 2016-08-17 14:47:24 -0500, Don Armstrong wrote: > All of that said, we certainly do appreciate better anti-spam SA rules > for the BTS, and we do already give negative scores for messages which > have things which look like PGP signatures and/or come from an address > which is in the whitelist.

Re: spammers closing bugs in BTS

On 2016-08-18 16:13:29 +0200, Patrick Matthäi wrote: > > Am 18.08.2016 um 15:48 schrieb Vincent Lefevre: > > Reject mail with "X-PHP-Originating-Script:", at least for -done? > > I quite often see this in spam not caught by the filters, and I > > suppose that P

Re: Upcoming change to perl: current directory in @INC

On 2016-09-08 08:44:54 -0700, Russ Allbery wrote: > That's a little better but not a lot better. It means that it's still > unsafe to run any script out of a world-writeable directory such as /tmp, > even if the sticky bit is set. Running things in /tmp or its subdirectories is prone to security

Re: Bug#837606: general: system freeze

On 2016-09-15 10:10:23 +0200, Abou Al Montacir wrote: > That is very similar to the issue I'm experiencing. However I can > reproduce this 100% when opening a page on linkedIn using epiphany > browser. Then I think that you should give strace information + system logs. -- Vincent Lefèvre - Web:

Bug#837606: general: system freeze

On 2016-09-19 09:50:19 +0200, Abou Al Montacir wrote: > On Thu, 2016-09-15 at 11:30 +0200, Vincent Lefevre wrote: > > Then I think that you should give strace information + system logs. > Thanks Vincent for the only valuable answer I've got on this. > > I tried that but

Re: problem with libc6 / iconv

On 2016-10-09 10:21:03 +0300, Lars Wirzenius wrote: > On Sun, Oct 09, 2016 at 01:49:14AM +0200, Jérémy Lal wrote: > > node-iconv used to be able to translit utf-8 chars (ça va) to ascii (ca va) > > using setlocale("C.UTF-8") trick. > > > > However, several libc6 version ago, that behavior changed,

gnucash status

Though the following bug was closed several months ago, gnucash from sid still depends on libwebkitgtk-1.0-0. What is the current status? Shouldn't this bug have remained open until sid got a fixed version? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790204 -- Vincent Lefèvre - Web:

Re: gnucash status

On 2018-05-16 01:21:01 +, Anthony DeRobertis wrote: > It appears to be fixed in experimental, which has 3.0. Presumably > that'll hit unstable when the maintainer feels it's ready. > > It appears the the BTS's version tracking may not have fully > realized what was going on, explaining why it'

Re: Removing packages perhaps too aggressively?

On 2018-05-22 15:19:50 +0500, Andrey Rahmatullin wrote: > On Tue, May 22, 2018 at 11:43:31AM +0200, Heinz Repp wrote: > > Just stumbled over some removals: > > > > GnuCash removed from testing in August 2017 > > FreeCad removed from testing in October 2017 > > > > no sign of any effort to readd t

Re: Removing packages perhaps too aggressively?

On 2018-05-23 09:46:09 +0800, Paul Wise wrote: > On Tue, May 22, 2018 at 5:43 PM, Heinz Repp wrote: > > > GnuCash removed from testing in August 2017 > > Depends on obsolete WebKit version (fixed in experimental): > > https://tracker.debian.org/pkg/gnucash > https://tracker.debian.org/news/85989

Re: Removing packages perhaps too aggressively?

On 2018-05-29 15:35:24 +0200, Steve Cotton wrote: > On Tue, May 29, 2018 at 03:03:11PM +0200, Vincent Lefevre wrote: > > On 2018-05-23 09:46:09 +0800, Paul Wise wrote: > > > Depends on obsolete WebKit version (fixed in experimental): > > > > > > https://tracke

Re: no{thing} build profiles

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) without gnupg. > > It won't function at all without gnupg. That's pointless

Re: no{thing} build profiles

On 2018-10-23 16:55:00 +0200, Wouter Verhelst wrote: > 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: > > > >

Re: no{thing} build profiles

On 2018-10-23 17:01:04 +0200, Wouter Verhelst wrote: > On Mon, Oct 22, 2018 at 11:12:57PM +0200, Adam Borowski wrote: > > That would be a bad idea -- we don't want gratuitous dependencies > > all around. Just because I use xfce doesn't mean I want a daemon > > for some old kinds of iApple iJunk >

Re: systemd, ntp, kernel and hwclock

On 2017-02-28 20:01:52 +0100, Carsten Leonhardt wrote: > Daniel Pocock writes: > > > On 27/02/17 21:26, Ben Hutchings wrote: > >> But ntpd is also known to have a large amount of code written > >> without as much regard for security as one would hope. It seems > >> like an unnecessary risk for m

Re: systemd, ntp, kernel and hwclock

On 2017-03-05 03:52:33 +, Ben Hutchings wrote: > I would also expect that users running command-line tools to set the > time, such as ntpdate, have enough technical understanding to > distinguish the system clock and RTC. And what's worse is that by default, ntpdate is run automatically from /

Bug in https://release.debian.org/transitions/ page?

The https://release.debian.org/transitions/ lists in "Ongoing transitions": auto-golang-goleveldb (100%) auto-libratbag (100%) which are actually finished. And in "(almost) Finished transitions", one can see: auto-libevent (5%) which has 3 packages in "good", 2 packages in "partial", and

Re: DocBook 5 for Debian

Hi, On 2017-08-01 23:24:20 -0700, Paul Hardy wrote: > Therefore, I propose filing ITPs for packages "docbook5", "docbook5-xsl", > and "docbook5-xml". The packages initially would be based on DocBook 5.1, > unless DocBook 5.2 is finalized in the meantime. FYI, docbook5-xml has existed for years,

Re: Bug in https://release.debian.org/transitions/ page?

On 2017-08-08 14:13:31 +0200, Mattia Rizzolo wrote: > Trying to guess what your actual question is... > > On Tue, Aug 08, 2017 at 01:05:03PM +0200, Vincent Lefevre wrote: > > The https://release.debian.org/transitions/ lists in > > "Ongoing transitions": > >

Re: OpenSSL disables TLS 1.0 and 1.1

On 2017-08-08 13:26:52 +0200, Stephan Seitz wrote: > On Mo, Aug 07, 2017 at 11:18:38 -0500, Michael Lustfield wrote: > > Is there an actual need for the removal of TLS v1.{0,1}? Are either > > considered broken or unsupported by upstream? If not, I'd be much more > > That’s I like to know as well.

Re: Automatic way to install dbgsym packages for a process?

On 2017-08-08 15:53:34 +0200, Stefan Fritsch wrote: > Now, where to put it? Into devscripts? The disadvantage is that devscripts > already pulls in quite a few other packages via recommends. But I don't > have a better idea. Unless we want to include it in reportbug or something > like that? Th

Re: is the whole unstable still broken by gcc-5?

On 2015-09-13 23:57:13 +0200, Paul Wise wrote: > This config option improves the aptitude resolver for some situations: > > /etc/apt/apt.conf.d/99aptitude-resolver: > Aptitude::ProblemResolver { SolutionCost "removals"; } Unfortunately this has the consequence that aptitude sometimes wants to dow

Re: Bug#807019: tracking bin-num - broken unison due to binnmu upload

On 2016-01-03 16:54:40 +1100, Brian May wrote: > The package called "unison2.40.102" version 2.40.102-3+b1 in testing and > unstable is broken. This broken package is not in stable. If it can't > get fixed, it probably should get removed. Yes, I think that it should be removed ASAP. Thus, users of

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

On 2016-01-04 23:14:11 +0100, Stefano Zacchiroli wrote: > On Mon, Jan 04, 2016 at 07:45:37AM +, Niels Thykier wrote: > > 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-fre

Re: Packaging of static libraries

On 2016-04-10 14:28:02 +0100, Alastair McKinstry wrote: > (1) When performance matters. Here we need the static library to be > built without position independent code. This can still give several > percent gains depending on arch / programming language. Yes, but in that case, the best thing to do

Re: Packaging of static libraries

On 2016-04-12 14:52:33 +0100, Ian Jackson wrote: > I'm afraid that LTO is probably too dangerous to be used as a > substitute for static linking. See my comments in the recent LTO > thread here, where I referred to the problem of undefined behaviour, > and pointed at John Regehr's blog. This is n

Re: Packaging of static libraries

On 2016-04-13 12:40:39 +0100, Ian Jackson wrote: > Vincent Lefevre writes ("Re: Packaging of static libraries"): > > Note that by default, shared libraries would still be used, so that > > this would affect only users with specific applications, who would > > want

<    1   2   3   4