Re: Command /usr/bin/mv wrong message in German

On 1/4/24 10:18, gregor herrmann wrote: % dpkg -S $(which mv > coreutils: /usr/bin/mv On bookworm: $ dpkg -S $(which mv) dpkg-query: no path found matching pattern /usr/bin/mv This is caused by the /bin -> /usr/bin shift. The reason I'm replying is after one, probably two decades thi

Re: A mail relay server for Debian Members is live

On 17/7/22 10:37, Ansgar wrote: On Sun, 2022-07-17 at 10:29 +0200, Dominik George wrote: tl;dr: DKIM-signed mail is verifiable, but only the headers; the body can be tampered with; This is just wrong. There is no reason to sign mails to ensure authenticity if one can just change the body...

Re: Firmware - what are we going to do about it?

On 19/4/22 10:27, Steve McIntyre wrote: 5. We could split out the non-free firmware packages into a new non-free-firmware component in the archive, and allow a specific exception only to allow inclusion of those packages on our official media. We would then generate only one set

Re: Making Debian available

On 17/1/21 3:27 am, Russ Allbery wrote: "Andrew M.A. Cater" writes: Wifi is the tough one: The companies that dominate laptop chipsets - Broadcom/Realtek/Qualcomm don't make it easy to find out which particular chipset it is. For USB Wifi connectors it's even harder - lots of Realtek chipsets

Re: isc-dhcp-client sends DHCPDISCOVER *before* wpa_supplicant authenticates/associates/connects.

On Sat, 2020-07-11 at 22:12 -0400, The Wanderer wrote: > I don't run either systemd or NetworkManager, and I'm not currently > interested in changing either of those things, but I am interested in > trying out an alternative to wpa_supplicant. Is there an appropriate > similar procedure for such an

Re: Heads up: persistent journal has been enabled in systemd

On Tue, 2020-02-04 at 18:10 -0800, Russ Allbery wrote: > It does take a bit of retraining to use journalctl instead (and I'm > personally not horribly fond of its UI, although that's probably > because I'm using it wrong), but it's a lot better at effectively > narrowing log messages to the things

Re: [RFC] Proposal for new source format

On Sun, 2019-10-27 at 20:29 -0700, Russ Allbery wrote: > If you modify the upstream source, then by definition you do not have > reproducibility of the upstream source, and you're now talking about > something else (review of the changes, which I called audit in my > previous message). I think I'm

Re: [RFC] Proposal for new source format

On Wed, 2019-10-23 at 09:49 -0400, Theodore Y. Ts'o wrote: > Generating a reproducible source package given a particuar git commit > is trivial. All you have to do is use "git archive". For example: It is indeed. Almost a tautology. But it's not what I'm interested in doing. The focus is on s

Re: [RFC] Proposal for new source format

On Tue, 2019-10-22 at 20:21 -0700, Russ Allbery wrote: > I define reproducibility as generating the same Debian source package > from a signed Git tag of my packaging repository plus, for non-native > packages, whatever release artifacts upstream considers canonical > (which may be a signed tarbal

Re: [RFC] Proposal for new source format

On Tue, 2019-10-22 at 20:21 -0700, Russ Allbery wrote: > This history has at least one commit per upload, although ideally > has the package maintainer's full revision history and upstream's > full revision history. I understand you like the history. A lot of people do. But not everyone values

Re: [RFC] Proposal for new source format

On Tue, 2019-10-22 at 16:52 -0700, Russ Allbery wrote: > That seems excessively pessimistic. What about Git makes you think > it's impossible to create a reproducible source package? Has it been done? Given this point has been raised several times before if it hasn't been done by now I think it'

Re: Init systems and docker

On Fri, 2019-10-11 at 19:25 -0400, Jose-Luis Rivas wrote: > There's not much sense in using systemd inside a docker container, to > be honest. To put it another way, in the container world the init system belongs outside of the container. That is because the closest thing equivalent to a containe

Re: duplicate popularity-contest ID

On Wed, 2019-08-07 at 09:34 +0200, Marc Haber wrote: > I am using Debian for two decades now, and I realized that necessity > two days ago. Ditto - except for me it was a few seconds ago. signature.asc Description: This is a digitally signed message part

Re: Programs contain ads - acceptable for packaging for Debian?

On Thu, 2019-06-20 at 13:15 +0700, Bagas Sanjaya wrote: > Suppose that an upstream has released a program which its license  > conforms to DFSG (named ZZZ), but when I test it, ads placed by the  > upstream appear (such as pop up ads). Since ads can affect user  > experience of ZZZ, but at the same

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

On Tue, 2019-04-30 at 09:25 +0800, Paul Wise wrote: > I like this option because it still works well if we ever decide to > fix a fundamental flaw in the Debian source package layout. I suspect whether that's a fundamentally is a matter or personal taste. On this point my taste aligns with yours.

Re: Concerns to software freedom when packaging deep-learning based appications.

On Thu, 2018-07-12 at 18:15 +0100, Ian Jackson wrote: > Compare neural networks: a user who uses a pre-trained neural network > is subordinated to the people who prepared its training data and set > up the training runs. In Alpha-Zero's case (it is Alpha-Zero the original post was about) there is

Re: concerns about Salsa

On Sat, 2018-06-09 at 13:52 +0100, Ian Jackson wrote: > As a service owner who has chosen to run the service out of git > for other reasons, I don't really care.  But someone who wants to run > the service from packages might have a different view. In my very limited experience with containers the

Re: concerns about Salsa

On Fri, 2018-06-08 at 10:11 +0800, Paul Wise wrote: > In my experience the Wordpress upstream auto-upgrade system is > typically faster than the Debian's handling of Wordpress. I didn't realise Wordpress had an auto-upgrade system. That put's in the same league as the Browsers like Chrome and Fir

Re: concerns about Salsa

On Thu, 2018-06-07 at 18:14 +0200, Tollef Fog Heen wrote: > Packages does not imply automation (lots of people maintain machines > by logging into each one and running apt by hand and $EDITOR on their > configuration files; I suspect this applies to the majority of > desktops and laptops by people

Re: concerns about Salsa

On Tue, 2018-06-05 at 15:44 +0100, Ian Jackson wrote: > Packages are great for software which you can just install and use > without much fuss.  That is often true for mature software.  But for > services which are less mature, and more complex, and which have more > tentacles, the admin is likely

Bug#894696: ITP: nagios4 -- A host/service/network monitoring and management system

Package: wnpp Severity: wishlist Owner: Russell Stuart -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: nagios4 Version : 4.3.4 Upstream Author : Ethan Galstad * URL : http://www.nagios.org/ * License : GPLv2 Programming Lang: C

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

On Tue, 2018-02-27 at 14:13 +0100, Didier 'OdyX' Raboud wrote: > > - we could ship those applications not as .deb but as container > >   and let them have their own lifecycle > > tl;dr: a new package format is needed, with a new non-suite-specific  > repository is needed to bring the Debian added-

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

On Mon, 2017-12-04 at 21:01 +, Ben Hutchings wrote: > I end up needing non-free firmware on most bare metal systems, but > nothing else from non-free.  I never remember how to include it at > installation time.  And I don't want us to gloss over the fact that > it is non-free and therefore not

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

On Thu, 2017-07-27 at 10:05 +, Sam Morris wrote: > You'd have to use BindsTo=sys-subsystem-net-devices-blah.device. But  > BindsTo= and device units are a bit fiddly, see systemd/systemd/issues/4413>. I had a systemd enthusiast sitting beside me who recommended that. I

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

On Sat, 2017-07-15 at 07:46 +0200, Tollef Fog Heen wrote: > Doesn't something like: > > [Unit] > Description=My hook for foo.link > After=foo.link > BindsTo=foo.link > > [Service] > Type=oneshot > ExecStart=/usr/local/sbin/whatever > RemainAfterExit=yes > > [Install] > WantedBy=multi-user.target

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

On Fri, 2017-07-14 at 18:31 -0700, Russ Allbery wrote: > I didn't think anyone was claiming they would, so I'm not sure why > you felt like it was necessary to say this. It's the same reason you feel like it was necessary to say this, I guess: On Fri, 2017-07-14 at 09:11 -0700, Russ Allbery wrote

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

On Fri, 2017-07-14 at 09:11 -0700, Russ Allbery wrote: > Right, I'm completely happy with the current behavior.  I have no > objections to the change.  I just also don't particularly care; I've > stopped using ifupdown and am using *.link units for network > configuration, which makes all of this t

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

On Fri, 2017-07-14 at 11:20 -0300, Henrique de Moraes Holschuh wrote: > MOST PCI/PCIe NICs indeed use "ethX", etc.  But the naming scheme > really is device driver-specific, and the "default" name used by a > driver is considered part of the kernel stable ABI, and cannot be > changed on the kernel

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

On Thu, 2017-07-13 at 09:07 -0700, Russ Allbery wrote: > Er, I saw this all the time without udev persistent naming.  Every > time we rebooted one of our servers, the four onboard NICs (of which > we were only using one -- long story, but basically that's just what > the systems came with out of th

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

On Thu, 2017-07-13 at 11:21 +, Clinton Roy wrote: > Unfortunately, others have (well, not the kernel, but PCI): > > https://lists.freedesktop.org/archives/systemd-devel/2017-May/038924. > html If you plug new hardware devices in then of course things are going to change. The claim really is

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

On Thu, 2017-07-13 at 05:20 -0400, Tom H wrote: > Stateless "/etc". > > Systems with multiple NICs where the order in which they're > recognized by the kernel can vary. I asked for a person. I guess I really asking for a use case. "Stateless /etc" isn't either. I've never seen the kernel vary

Re: IMPORTANT: Do live Debian images have a future?

On Wed, 2017-07-12 at 21:00 +0530, shirish शिरीष wrote: > On 12/07/2017, Fernando Toledo wrote: > > Our Use-case: > > > > We develop a derivated distro from Debian called Huayra GNU/Linux, > > this is for educational program of government in Argentina. This > > big program ship around 5 millons o

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

On Wed, 2017-07-12 at 17:35 +0200, Marc Haber wrote: > I'd rather have breakage in this case than having to look for the > interface every fscking time I need to run tcpdump, or having to > adapt to an entirely new name schema like lanc0 and lanw0 to not > stomp in the kernel's name space when usin

Re: UMASK 002 or 022?

On Fri, 2017-06-30 at 21:22 +1000, Scott Leggett wrote: > If windows is different, it looks to be the outlier because macOS > behaves the same way as Debian[0]: > >   > For example, the default umask of 022 results in permissions of 644 >   > on new files and 755 on new folders. Groups and other u

Re: "Ask HN: What do you want to see in Ubuntu 17.10?"

On Thu, 2017-04-06 at 09:22 +1000, Russell Stuart wrote: > Anyway, this discussion prompted me to get off my bum and look at why > unattended-upgrades wasn't working.  Turns out the default install > has "label=Debian-Security", and all these laptops are running > testi

Re: "Ask HN: What do you want to see in Ubuntu 17.10?"

On Wed, 2017-04-05 at 12:38 +0100, Ian Jackson wrote: > Me too.  I guess it depends very much on whether one can afford to > buy a good laptop which works well with Linux. Not in this case. My laptop concerned is an Dell XPS 9550. It wasn't cheap and in the 12 months of ownership I'd describe th

Re: "Ask HN: What do you want to see in Ubuntu 17.10?"

On Wed, 2017-04-05 at 11:18 +0800, Paul Wise wrote: > Not AFAIK. I would guess that needrestart would need to be promoted > to standard priority and needrestart-session would need to be added > to tasksel's task-desktop package, or to each of the task-*-desktop > packages; this adds wxWidgets to th

Re: "Ask HN: What do you want to see in Ubuntu 17.10?"

On Mon, 2017-04-03 at 15:35 +1000, Brian May wrote: > On 2017-04-03 10:10, Russell Stuart wrote: > > The first is better HDPI handling.  This will require Wayland ... > >   >   > Did I miss something? I thought Ubuntu was doing their own thing and > not using Wayland. >

Re: "Ask HN: What do you want to see in Ubuntu 17.10?"

On Fri, 2017-03-31 at 21:48 +0100, Chris Lamb wrote: > There's a very active conversation happening on Hacker News right > now entitled «What do you want to see in Ubuntu 17.10?»: > >   https://news.ycombinator.com/item?id=14002821 > > I haven't read every comment yet, but are there any feature r

Re: Feedback on 3.0 source format problems

On Mon, 2017-01-09 at 17:33 +, Ian Jackson wrote: > All of this applying and unapplying of patches around build > operations is complete madness if you ask me - but I don't see a > better approach given the constraints.  dgit sometimes ends up doing > this (and moans about it), which is even ma

Re: Converting to dgit

On Wed, 2017-01-04 at 14:47 +1000, Russell Stuart wrote: > The central issue here appears to be that none of the proposed ways > of using git within Debian help with that task. On Wed, 2017-01-04 at 04:42 +, Colin Watson wrote: > > git-dpm does too, and I agree it's nice. &

Re: Feedback on 3.0 source format problems

On Tue, 2017-01-03 at 18:37 -0800, Russ Allbery wrote: > Even if we never used tarballs, and instead our unit of operation was > the upstream Git repository plus Debian branches, I would maintain a > rebased branch of Debian changes to upstream This is not a novel requirement. Most projects I've

Re: Can we kill net-tools, please?

On Fri, 2016-12-30 at 16:09 +0100, Bjørn Mork wrote: > Fix it instead :) I have submitted patches for kernel the network stack to improve QoS for ADSL (ie where ATM cells are the link layer carrier). I'm not terribly forgiving of the long drawn out initiation rites the kernel dev's seem to demand

Re: Can we kill net-tools, please?

On Fri, 2016-12-30 at 10:42 +0100, Vincent Bernat wrote: > > I bet the bash authors use that argument when they add another > > feature. In reality all code has a cost. > > The only additional cost is the cost to check if the routing entry is > a blackhole (while the check for anything else alrea

Re: Can we kill net-tools, please?

On Fri, 2016-12-30 at 07:51 +0100, Vincent Bernat wrote: > The same work is not repeated over and over again. The kernel keeps > the needed information in a structure to avoid parsing the packet > several times. Yes, it does indeed keep the offset of the headers for the various protocol layers (li

Re: Can we kill net-tools, please?

On Thu, 2016-12-29 at 11:38 -0800, Russ Allbery wrote: > It certainly doesn't provide a man page that doesn't start with a BNF > syntax description.  The iproute2 documentation is awful. > > Also, this is not at all easy to parse: > > # ip -o address > 1: loinet 127.0.0.1/8 scope host lo\ vali

Re: Can we kill net-tools, please?

On Wed, 2016-12-28 at 03:08 +, Wookey wrote: > If we are supposed to change to something newer these days We've been discussing doing that for 8 years now: https://lists.debian.org/debian-devel/2009/03/msg00780.html > a pointer to a 'conversion' document would be nice. https://wiki.

Re: Can we kill net-tools, please?

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 It's probably wise to 'dpkg -L iproute2 | grep bin/'. They are the tools provided by t

Re: Crowd funding campaign to package browserify in debian

On Sun, 2016-12-25 at 19:17 +0100, Stéphane Blondon wrote: > Perhaps I missed something, so I'm curious to learn more about it (a > link or some keywords can be a good start). The buzz work mix is: - vue-loader - webpack - webpack plugin for .vue files (mix of HTML, CSS/sass/stylus, and JS). and

Re: Crowd funding campaign to package browserify in debian

On Fri, 2016-12-23 at 21:36 +, Jonas Smedegaard wrote: > This list is about development of Debian. > > Not about how to raise money to ease developing Debian. The first condition is fulfilled - the email is about getting development done within Debian. In fact given ITP's I've seen floating

Re: unattended-upgrades by default?

On Thu, 2016-11-03 at 18:47 +, Steve McIntyre wrote: > To solve the issue and provide security updates by default, I'm > proposing that we should switch to installing unattended-upgrades by > default (and enabling it too) *unless* something else in the > installation is already expected to deal

Re: When should we https our mirrors?

On Thu, 2016-10-27 at 08:35 +0200, Vincent Bernat wrote: > Moreover, the download speed can be very slow, either from work or > from home (100M fiber connection). Sometimes 100kbytes/s. That's a > pain. > > I am a bit worried for deb.debian.org to become a default as it > doesn't work well for me.

Re: GR: Declassifying debian-private: First call for votes

On Sun, 2016-08-07 at 01:48 +0200, Debian Project Secretary - Kurt Roeckx wrote: > Hi, > > This is the first call for vote on the General Resolution about > declassifying debian-private. > >  Voting period starts  2016-08-07 00:00:00 UTC >  Votes must be received by 2016-08-20 23:59:5

Re: synaptics vs libinput and GNOME 3.20 no longer supporting synaptics

On Thu, 2016-07-14 at 14:13 +1000, Russell Stuart wrote: > The second component is that apparently tapping doesn't work when > > enabled. That's most probably a bug, file one against libinput at > > bugs.freedesktop.org and it'll get fixed. > > Done. Fo

Re: synaptics vs libinput and GNOME 3.20 no longer supporting synaptics

On Thu, 2016-07-14 at 13:41 +1000, Peter Hutterer wrote: Thanks for the thorough analysis. > The second component is that apparently tapping doesn't work when > enabled. That's most probably a bug, file one against libinput at > bugs.freedesktop.org and it'll get fixed. Done.  Having to filing i

Re: synaptics vs libinput and GNOME 3.20 no longer supporting synaptics

On Tue, 2016-07-12 at 10:07 +0300, Lars Wirzenius wrote: > I've been using the following script, with variations on the > parameters to find a working setup. The values below are the best I > could manage, and they aren't any good. > > #!/bin/sh > > synclient \ > TapButton1=1 \ > TapB

Re: synaptics vs libinput and GNOME 3.20 no longer supporting synaptics

On Tue, 2016-07-12 at 07:48 +0300, Lars Wirzenius wrote: > After Raphael's mail yesterday, I switched from the synaptics driver > to the xinput one (by removing xserver-xort-input-synaptics) and > since then, I've not had a single case of moving the mouse or > clicking by tapping by accident. When

Re: synaptics vs libinput and GNOME 3.20 no longer supporting synaptics

On Mon, 2016-07-11 at 23:51 +0200, Raphael Hertzog wrote: > Well, if some KDE/XFCE/etc. packages work only with synaptics and not > with libinput, then we should get those packages updated to depend on > xserver-xorg-input-synaptics, no? I don't know about KDE/XFCE, but in the etc category is LXDE

Re: Thinking about a "jessie and a half" release

On Tue, 2016-07-05 at 08:25 +0100, Rebecca N. Palmer wrote: > Have you reported this bug (with the full warnings)?  If not, please > do so. I haven't.  If I got a response at all to "My monitor doesn't work" it looks to me it would be: compile latest source with instrumentation turned on and send

Re: Thinking about a "jessie and a half" release

On Tue, 2016-07-05 at 00:38 +0200, Ben Hutchings wrote: > As I understand it, xserver-xorg-video-modesetting should be used > instead of xserver-xorg-video-intel, for chips supported by the i915 > kernel driver.  So the latter should be changed to limit the device > IDs it claims, then both of them

Re: trying to use wireless not from gnome... what's the incantation?

On Thu, 2016-05-26 at 12:15 -0800, Britton Kerin wrote: > On Thu, May 26, 2016 at 4:35 AM, Andrew Shadura > wrote: > > There's no need in any of this, ifupdown already supports this mode > > without anything apart from wpa-conf. > > > > See /usr/share/doc/wpasupplicant/README.Debian.gz for more d

Re: trying to use wireless not from gnome... what's the incantation?

On Thu, 2016-05-26 at 10:24 +0200, Michael Biebl wrote: > It's hard to say though. For this we'd need proper debug logs to > further investigate this. You shamed me into doing something about it.  But now I test it, network-manager works.  It's been 3 months and a similar number of kernels, so who

Re: trying to use wireless not from gnome... what's the incantation?

On Mon, 2016-05-23 at 08:28 +0200, Adam Borowski wrote: > Using low-level tools can indeed be tricky, so while they're more > powerful than anything NM or wicd can do, they're an overkill and a > waste of learning time if what you want is regular use of a single > interface. I have a new laptop on

Re: An abrupt End to Debian Live

On Mon, 2015-11-09 at 17:47 +0100, Daniel Baumann wrote: > An abrupt End to Debian Live As a person who recently used Debian Live to set up a PXE boot image after trying several different alternatives including debian-cd, I am sorry to hear this and sad to see debian-live go. It will be missed, b

Re: Metapackage dependencies: "Depends" or "Recommends"?

On Thu, 2015-07-30 at 08:57 +0200, David Kalnischkies wrote: > This example makes it quite obvious that your requirements are "keep > a minimal set of packages installed" while the requirement of libapt's > autoremove is "suggest only packages for removal which are completely > safe to remove". If

Re: git and https

On Fri, 2015-05-29 at 22:21 +1000, Riley Baird wrote: > > LetsEncrypt will save us! > > I just looked that up. What a wonderful idea! I don't know how you missed it. My tongue has been hanging out for a year now. Finally, sanity prevails. A https cert is supposed to certify www.someone.com is

Re: Bug#786902: O: ifupdown -- high level tools to configure network interfaces

On Wed, 2015-05-27 at 19:27 +0800, Paul Wise wrote: > Your mail is missing some things: > > To: 786...@bugs.debian.org > Control: retitle -1 ITA: ifupdown -- high level tools to configure > network interfaces > Control: owner -1 ! If you mean it has been orphaned, it will work for while yet even

Re: Bug#786902: O: ifupdown -- high level tools to configure network interfaces

On Wed, 2015-05-27 at 12:33 +0200, Marco d'Itri wrote: > (I am shocked, shocked that there is no flood of people here rushing to > save ifupdown... :-) ) Until systemd-networkd can run scripts on events no defence is required. It would be like comparing a calculator to a computer. Sure, the calc

Re: Proposal: enable stateless persistant network interface names

On Wed, 2015-05-13 at 17:16 +0200, Vincent Lefevre wrote: > Well, having some of the network traffic (more precisely, connections > to machines that have an IPv6 address) re-routed to some unknown > machine on the local network is not a nice feature. > > IMHO, such a feature should be enabled only

Re: Proposal: enable stateless persistant network interface names

On Mon, 2015-05-11 at 09:29 +0200, Marc Haber wrote: > For example, it doesn't know dependencies between Interfaces, which is > rather common for a server jockey (consider a VLAN on a bridge which > is connected to the network via a bonding device) I haven't had to solve that example, but I have h

Re: Proposal: enable stateless persistant network interface names

On Sun, 2015-05-10 at 17:11 +0200, Vincent Bernat wrote: > The disease is that actual servers running actual free software can > break at each boot because we cannot have both a persistent naming > scheme and use the eth* prefix is worse that the cure because old > versions of Novell ZENworks may s

Re: debian github organization ?

First a Mel Cupa. I called the SourceForge system Apollo. It's actual name is Apache Allura. Brain fart. On Thu, 2015-04-16 at 23:13 -0700, Russ Allbery wrote: > Er, they did, didn't they? I could have sworn that they only supported > CVS initially, and then only added Subversion, and getting

Re: debian github organization ?

On Thu, 2015-04-16 at 19:37 +0200, Sven Bartscher wrote: > On Thu, 16 Apr 2015 09:04:07 -0600 > Dimitri John Ledkov wrote: > > > I'd rather see gitlab.debian.net :) > > I don't a reason to have gitlab/github/someother git stuff for debian, > since we already have alioth. > Maybe someone can enl

Re: Who gets an email when with bugreports [was: Re: Unauthorised activity surrounding tbb package]

On Wed, 2015-01-21 at 21:10 -0500, Michael Gilbert wrote: > So anyway, nn-subscribe can be used to spam confirmation messages > currently, and general mail to the bts from an unknown address will > end up doing the same, but it's basically a non-issue because it's a > rather uninteresting thing

Re: Who gets an email when with bugreports [was: Re: Unauthorised activity surrounding tbb package]

On Mon, 2015-01-19 at 16:57 -0500, Michael Gilbert wrote: > Isn't the spam vector already wide open for > nn-subscr...@bugs.debian.org, which isn't much (ab)used today? > > I fail to see how any of the discussed changes open an abuse vector > that doesn't already exist. OK, so let me help you

Re: Who gets an email when with bugreports [was: Re: Unauthorised activity surrounding tbb package]

On Mon, 2015-01-19 at 10:03 +0100, Tomas Pospisek wrote: > Am 19.01.2015 um 02:03 schrieb Ben Hutchings: > > No, this would turn the BTS into a (worse) spam vector. > > > > But the acknowledgement mail should tell you how to subscribe, if you > > aren't already subscribed. > > But isn't subscribi

Re: policy regarding redistributable binary files in upstream tarballs

On Fri, 2014-11-21 at 17:39 +0800, Paul Wise wrote: > On Fri, Nov 21, 2014 at 5:25 PM, Matthias Urlichs wrote: > > > These days, they might just push their repo to github and let its machinery > > generate the tarballs, which TTBOMK aren't guaranteed to be 1:1 identical to > > another tarball of t

Re: policy regarding redistributable binary files in upstream tarballs

On Thu, 2014-11-20 at 13:46 +0800, Paul Wise wrote: > On Thu, Nov 20, 2014 at 1:14 PM, Ben Finney wrote: > > > But a growing number of upstreams disagree, so those upstreams are > > likely to be actively opposed to your recommendation to patches > > which remove non-source files from the VCS repo

Re: Bug#752450: ftp.debian.org: please consider to strongly tighten the validity period of Release files

On Thu, 2014-10-30 at 16:06 +0100, Wouter Verhelst wrote: > On Thu, Oct 30, 2014 at 03:59:33PM +1000, Russell Stuart wrote: > > Yes, fine. But a truly security conscious distribution doesn't depend > > on its users being truly security conscious. > > I would hope Deb

Re: Bug#752450: ftp.debian.org: please consider to strongly tighten the validity period of Release files

On Thu, 2014-10-30 at 01:40 -0400, Michael Gilbert wrote: > There are also end-of-life announcements, which maybe the > debian-security-support package now addresses in a somewhat automated > fashion. I wasn't aware of that. Thanks. > Anyway, it is entirely understandable that reading can be har

Re: Bug#752450: ftp.debian.org: please consider to strongly tighten the validity period of Release files

On Wed, 2014-10-29 at 21:58 -0700, Russ Allbery wrote: > Also, this means that you completely miss security advisories that *don't* > involve changing a package in the archive, like "this thing is a disaster, > so we're pulling it from the archive entirely and suggest you stop using > it." If it i

Re: Bug#752450: ftp.debian.org: please consider to strongly tighten the validity period of Release files

On Wed, 2014-10-29 at 19:39 -0700, Russ Allbery wrote: > But we shouldn't confuse that with the right way to check > for security updates for Debian systems. People who > care about security updates need to be subscribed to > debian-security-announce and reading the DSAs. If there are two "ways"

Re: GPL-3 & openssl: provide a -nossl variant for a library

On Thu, 2014-10-23 at 12:46 +1100, Brian May wrote: > On 23 October 2014 04:03, Russ Allbery wrote: > It's usually more immediately useful to just > upload the package with an explanation of the issues in > debian/copyright > and see what the ftp-master team says. >

Re: bash exorcism experiment ('bug' 762923 & 763012)

On Wed, 2014-10-15 at 23:36 +0100, Ian Jackson wrote: > Actually, the problem is indeed in policy. In its resolution of > #539158 the TC decided unanimously (but unfortunately slightly > implicitly) that printf ought to be provided by our /bin/sh. > > Unfortunately the policy has not been properly

Re: bash exorcism experiment ('bug' 762923 & 763012)

On Mon, 2014-10-13 at 06:23 +0200, Dominik George wrote: > foo='x[$(rm -rf /)]' > echo $(( foo )) > > Guess when the array index is evaluated? Now mind that it could be > user-provided. In dash it isn't executed which means on Debian at least it's most harmless. That's another bouquet for dash.

Re: bash exorcism experiment ('bug' 762923 & 763012)

On Sun, 2014-10-12 at 22:05 +0200, Florian Weimer wrote: > Array variables practically imply arithmetic evaluation, amd this is a > shell feature which is rather difficult to use correctly because > compatibility with other shell encourages both recursive evaluation > and access to the full shell l

Re: bash exorcism experiment ('bug' 762923 & 763012)

On Fri, 2014-10-03 at 09:20 -0700, Russ Allbery wrote: > Russell Stuart writes: > > I looks to me like you are re-writing history. > > I'm not sure how you meant this, but to note, this sentence made me very > sad, since it felt like you believe I'm being intentionall

Re: bash exorcism experiment ('bug' 762923 & 763012)

On Thu, 2014-10-02 at 20:43 -0700, Russ Allbery wrote: > A lot of people miss this about Policy 10.4. People seem to think that > Policy 10.4 is about requirements for shell scripts. But it's just as > much a standard for /bin/sh. You wrote it, so I guess you get to say what it means. But if yo

Re: bash exorcism experiment ('bug' 762923 & 763012)

On Thu, 2014-10-02 at 18:05 -0700, Russ Allbery wrote: > Up until dash changes, and then you have absolutely no idea what to do > with that sort of policy. There's a reason why no standards document I've > ever seen says something like this. The ISO C standard isn't going to say > that anything t

Re: bash exorcism experiment ('bug' 762923 & 763012)

On Thu, 2014-10-02 at 22:50 -0300, Henrique de Moraes Holschuh wrote: > Debian policy mandates that /bin/sh implement a _superset_ of POSIX, which > is out of scope for "posh". Regardless, posh implements all the additional features mandated by 10.4: echo -n, if implemented as a shell built-in,

Re: bash exorcism experiment ('bug' 762923 & 763012)

On Fri, 2014-10-03 at 00:04 +, brian m. carlson wrote: > The shell you're describing is posh. It implements exactly those > features, and nothing more. You've got me to look at posh. Thanks for that. So we do have a shell that developers can use to test their scripts match Debian policy. >

Re: bash exorcism experiment ('bug' 762923 & 763012)

On Thu, 2014-10-02 at 11:48 +0200, Thorsten Glaser wrote: > This is wrong. Every script starting with #!/bin/sh must work with a > POSIX shell that supports “local” and “echo -n” (Policy §10.4). Solid, working software is hard enough to produce. A policy requiring something you can't test for mak

Re: bash exorcism experiment ('bug' 762923 & 763012)

On Tue, 2014-09-30 at 13:08 +0200, Thorsten Glaser wrote: > You really really should be looking at replacing any > ash variant with mksh. It’s not that much bigger (at > least if you add -DMKSH_SMALL to CPPFLAGS and build > with klibc or dietlibc or so), but much saner. I am not a fan of any parti

Re: bash exorcism experiment ('bug' 762923 & 763012)

On Mon, 2014-09-29 at 08:03 +0200, Matthias Urlichs wrote: > Russell Stuart: > > > > > > - array variables. > > > > No workaround for this one? Pity. This is what usually prevents > > conversion. > > Well, you could use $ary_len to remember t

Re: bash exorcism experiment ('bug' 762923 & 763012)

On Sun, 2014-09-28 at 16:47 +0200, Guillem Jover wrote: > > I've attempted to port the many shell scripts I've written over the > > years to dash. The three irritants are: > > > > - pipefail, > > . That's one of those "scratch my eyes out" solut

Re: bash exorcism experiment ('bug' 762923 & 763012)

On Sun, 2014-09-28 at 09:33 +0100, Colin Watson wrote: > On Sat, Sep 27, 2014 at 09:11:44PM -0500, Troy Benjegerdes wrote: > > Does update-menus really need bash? Why? > > pipefail is actually a fairly useful bashism. I've attempted to port the many shell scripts I've written over the years to da

Re: Alioth tracker

On Tue, 2014-06-24 at 18:05 +0200, Raphael Hertzog wrote: > On Tue, 24 Jun 2014, Оlе Ѕtrеісhеr wrote: > > I thought that usually such requests should be done through an request > > for help? (Is that valid for "pseudo packages" like a hypothetical > > alioth one?) If the alioth admin team would ope

Re: HTTPS everywhere!

On Tue, 2014-06-24 at 08:29 +0200, Matthias Urlichs wrote: > The difference is that while pinning a bunch of certificates is indeed a > lot of on-going work, pinning the CA cert used to sign these is not (set up > the CA and install it into our software once, sign server certificates with > that fo

Re: HTTPS everywhere!

On Mon, 2014-06-23 at 17:26 +0200, Christoph Anton Mitterer wrote: > Maybe my understanding of DKIM is too little... but I thought it would > be only some technique to verify the authenticity of sender addresses? DKIM, OpenPGP, X.509 - they are all the same thing with different names. They all com

Bug#752399: ITP: python-fdb -- Python DB-API driver for Firebird

Package: wnpp Severity: wishlist Owner: Russell Stuart * Package name: python-fdb Version : 1.4 Upstream Author : Pavel Cisar * URL : https://pypi.python.org/pypi/fdb/ * License : BSD Programming Lang: C, Python Description : Python DB-API driver for

  1   2   >