Bug#280566: ITP: clit -- Decompiler for Microsoft's .lit ebook format

Package: wnpp Severity: wishlist * Package name: clit Version : 1.8 Upstream Author : [EMAIL PROTECTED] * URL : http://www.lubemobile.com.au/ras/debian/sarge/clit/ * License : GPL Description : Decompiler for Microsoft's .lit ebook format Convert Micr

Bug#280568: ITP: libtommath -- Number theoretic multiple-precision integer library

Package: wnpp Severity: wishlist * Package name: libtommath Version : 0.32 Upstream Author : Tom St Denis <[EMAIL PROTECTED]> * URL : http://www.lubemobile.com.au/ras/debian/sarge/libtommath/ * License : Public Domain Description : Number theoretic multipl

Bug#344359: ITP: flowscan-cuflow -- Flowscan module combining CampusIO and SubNetIO

Package: wnpp Severity: wishlist Owner: Russell Stuart <[EMAIL PROTECTED]> * Package name: flowscan-cuflow Version : 1.5 Upstream Author : Johan Andersen <[EMAIL PROTECTED]>, Matt Selsky <[EMAIL PROTECTED]> * URL : http://www.columbia.edu/acis/networ

Bug#354815: ITP: cups-emailpdf -- PDF printer that emails the result back the user

Package: wnpp Severity: wishlist Owner: Russell Stuart <[EMAIL PROTECTED]> * Package name: cups-emailpdf Version : 1.0 Upstream Author : Russell Stuart <[EMAIL PROTECTED]> * URL : http://www.stuart.id.au/russell/files/debian/sarge/cups-emailpd

Re: ITP: btsco -- ALSA drivers and daemons for using bluetooth audio devices

On Sun, 2006-09-17 at 09:46 +0200, martin f krafft wrote: > also sprach Nobuhiro Iwamatsu <[EMAIL PROTECTED]> [2006.09.17.0559 +0200]: > > * Package name: btsco > > Please coordinate with Kel and Russell (on CC), who have been > working on this package for a while. One of the reasons that we h

Bug#329770: ITP: kern2deb -- Convert RedHat kernel-VER.src.rpm to a Debian package

Package: wnpp Severity: wishlist Owner: Russell Stuart <[EMAIL PROTECTED]> * Package name: kern2deb Version : 1.1 Upstream Author : Russell Stuart <[EMAIL PROTECTED]> * URL : http://www.stuart.id.au/russell/files/debian/sarge/kern2deb/ * License

Bug#465809: ITP: hpt -- Creates a TCP tunnel through http and https proxies

Package: wnpp Severity: wishlist Owner: Russell Stuart <[EMAIL PROTECTED]> * Package name: hpt Version : 1.1 Upstream Author : Russell Stuart <[EMAIL PROTECTED]> * URL : http://www.stuart.id.au/russell/files/http-proxy-tunnel/ * License : EPL

Password Protecting GPG Keys

There was a thread on d-private in early March about the benefits and downsides to to requiring every DD and aspiring DD to sign their messages. One of the reasons raised for not doing it is some felt uncomfortable carrying around their GPG keys when travelling. My initial reaction was "that's be

Re: Password Protecting GPG Keys

On Mon, 2014-06-16 at 12:01 +, Thorsten Glaser wrote: > You completely miss http://xkcd.com/538/ and the fact that some > legislations may require you, with jail penalty, to hand over > any encryption keys, passwords, etc. you have with you when > inside their territory. Quoting the man page:

Re: HTTPS everywhere!

On Wed, 2014-06-18 at 04:54 +0200, Christoph Anton Mitterer wrote: > Well https with X.509 has inherent problems which we won't be able to > solve... Precisely. It has a horrible design bug. Given the nature of the net, where we want to deal securely with some entity never dealt with or of heard

Re: HTTPS everywhere!

On Fri, 2014-06-20 at 22:58 +0200, Christoph Anton Mitterer wrote: > > But after you've sent them money or downloaded their software > > you have formed a trust relationship with whoever controls that cert far > > stronger than the assurances X.509 provides. That is true in the > > positive sense

Re: HTTPS everywhere!

On Sat, 2014-06-21 at 17:58 +0200, Christoph Anton Mitterer wrote: > Take Turktrust as an example... IIRC the case correctly, they > "accidentally" (whoever believes that) issued a cert which was a > intermediate CA and which was used to issue forged Google certs. > After days and only after long d

Re: HTTPS everywhere!

On Sun, 2014-06-22 at 03:34 +0200, Christoph Anton Mitterer wrote: > Well as it should be clear to everyone by now... with a own CA and with > specifically checking for certs issued by *only that* CA you can fully > secure things like apt-listbugs. Sure, but you are no longer discussing a PKI syst

Re: HTTPS everywhere!

On Sun, 2014-06-22 at 15:49 +0200, Christoph Anton Mitterer wrote: > On Sun, 2014-06-22 at 14:21 +1000, Russell Stuart wrote: > > Sure, but you are no longer discussing a PKI system here. If you are > > going to abandon X.509 PKI > Well first of all,... PKI is just "pu

Bug#752398: ITP: python-spyne -- Python RPC library for HttpRpc, SOAP, Json and more

Package: wnpp Severity: wishlist Owner: Russell Stuart * Package name: python-spyne Version : 2.10.10 Upstream Author : Burak Arslan * URL : http://spyne.io/ * License : LGPL Programming Lang: Python Description : Python RPC library for HttpRpc, SOAP

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

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

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: 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: 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: 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 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 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 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 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 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 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 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 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 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 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 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: 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: 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: 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 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 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: Alioth tracker

On Sun, 2014-05-11 at 21:38 +0200, Tollef Fog Heen wrote: > I'm not disagreeing, I think we're providing a much poorer service level > for Alioth than what we should do. Sadly, I don't have the motivation > to spend much time there nowadays. I have for years hosted my own projects in a minimalist

Re: Why not 03 ?

On Fri, 2014-05-30 at 07:21 +0900, Charles Plessy wrote: > For a lot of scientific packages, -O3 is chosen by the upstream > author, and I always feel bad that if we make the programs slower > by overriding it to -O2, it will reflect poorly on Debian as a > distribution for scientific works. In

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: 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: 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: 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 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: 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: 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: 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: 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 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: [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: [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 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 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 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: 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: 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: 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: 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 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 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 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: 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: 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: 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: 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: 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: 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: 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 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 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 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 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: 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: 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 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: 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-

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: 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

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 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 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 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: "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: "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 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 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 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: 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

  1   2   >