Bug#768772: ITP: xkcdpass -- secure passphrase generator inspired by XKCD 936
Package: wnpp Severity: wishlist Owner: Ben Finney * Package name: xkcdpass Version : 1.2.2 Upstream Author : Steven Tobin * URL : https://pypi.python.org/pypi/xkcdpass/ * License : BSD-3 Programming Lang: Python Description : secure passphrase generator inspired by XKCD 936 A flexible and scriptable password generator which generates strong passphrases, inspired by XKCD 936: . $ xkcdpass > correct horse battery staple -- \ “The future always arrives too fast, and in the wrong order.” | `\—Alvin Toffler | _o__) | Ben Finney signature.asc Description: Digital signature
Re: Bad weather in testing ?
On Fri, Nov 07, 2014 at 06:11:45PM +, Simon McVittie wrote: > On 07/11/14 16:15, Ralf Treinen wrote: > > There is only one package in the "each" category, and this is a false > > positive due to multiarch: lib32nss-mdns, which exists only on amd64 > > (this is why it shows up in the each category) and depends on an i386 > > package, which is deliberate in this case. > > That's a transitional hack, and I intend to get rid of it in jessie+1. I > think it's OK that QA tools complain about it. > > (I'm surprised the wine* family of packages don't get similar results > though - that's where I stole the idea from.) can you be more specific? Why do you think that there may be an issue with the wine packages? -Ralf. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141109083802.gb10...@seneca.home.org
Is it harmless to associate more file extensions to application/octet-stream ?
Good evening everybody, I have received the following demand to add associations between media types and file extensions in /etc/mime.types. - Forwarded message - Date: Mon, 03 Nov 2014 01:13:34 -0500 To: mime-supp...@packages.debian.org Subject: Please add these 5 MIME types to support ClickOnce apps To help Microsoft Visual Studio "ClickOnce" applications deploy smoothly, please add to the debian "mime-support" package these MIME types as described here under "Using Third-Party Web Servers" http://msdn.microsoft.com/en-us/library/ms228998.aspx application/x-ms-application application application/x-ms-manifestmanifest application/octet-stream deploy application/octet-stream msu application/octet-stream msp - End forwarded message - While I would prefer to accept only the addition of information that has also been submitted to the IANA, this one is backed by upstream documentation, so I am about to update /etc/mime.types accordingly. However, before doing so and for the avoidance of doubt, I just would like to double-check that adding more file suffixes for application/octet-stream is not going to cause problems. Currently the only suffix is "bin". With search engines I have not found evidence of a problem, but if you know one, please let me know. Have a nice Sunday, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141109091033.ga13...@falafel.plessy.net
Re: so long and thanks for all the fish
Sad news. I wish you all the best for your future endeavours. I hope to cross paths with you from time to time (maybe I should tidy up my half finished ikiwiki patches!) The coincidental timing of Colin leaving the tech-ctte did make me wonder how different things would be if we could have coerced you into joining. Great for Debian but perhaps not so much for you... -- Jonathan Dowland -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141109094140.ga29...@chew.redmars.org
Re: Bad weather in testing ? (was: Re: inconsistent versions of M-A: same packages)
On Sat, Nov 08, 2014 at 12:39:41PM +, Holger Levsen wrote: > Hi Ralf, > > On Freitag, 7. November 2014, Ralf Treinen wrote: > > The issue of architecture=all packages that > > are not installable on some architecture can IMHO not be solved with > > our current setup which makes architectures=all available on every > > architecture. > > The issue would become a non-issue if the "end user tools" (eg apt) would not > show such packages as available, or? Right. But what would be a good way to achieve this? One possible way is to remove non-installable packages from the Packages file, by having dak run dose-debcheck. However, I do not think that we want to do this for sid, and even for a stable release we have to be careful since there may be legitimate cases where we want to include a package that is found to be non-installable. How does the release team feel about this? Having apt run dose-debcheck to filter out the non-installable packages is not an option IMHO as it takes about 20-30 seconds to run on a desktop machine. -Ralf. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141109095016.gc10...@seneca.home.org
Two years later and still no netatalk3 in jessie?
On Thu, Aug 28, 2014 at 01:21:04PM -0400, Igor Bernstein wrote: > - jessie freeze happens in 2 months Happened in the meantime :-/ > 2014/8/4 - Adrian updated the package to 3.1.3 > adi's package (currently @ 3.1.3): > https://github.com/adiknoth/netatalk-debian JFTR, I'm at 3.1.6. The whole situation reminds me of wine, where Debian shipped the same outdated version for multiple releases. Even downstream distributions are suffering: http://raspberrypi.stackexchange.com/questions/23985/why-is-netatalk-not-updated I'd say get some devs behind this, call the package netatalk3 and ship it in parallel. I had it running for months, upstream had worked on it for years, it's not that this is bleeding edge or untested. jessie without netatalk3 would be embarrassing at best, but more importantly, it would be frustrating for everyone who wants to use their Linux file servers as a time machine backup. CC debian-devel for additional momentum. Please stop CCing this bug in case this turns into another bike shedding discussions on the ML. Cheers -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141109094858.ga8...@ltw.loris.tv
Re: Two years later and still no netatalk3 in jessie?
On Sun, Nov 09, 2014 at 10:48:58AM +0100, Adrian Knoth wrote: > On Thu, Aug 28, 2014 at 01:21:04PM -0400, Igor Bernstein wrote: > > > - jessie freeze happens in 2 months > > Happened in the meantime :-/ Well, what is the point in CCing -devel then? If you were trying to set a roadmap for jessie+1, that wasn't very clear from your post I think. Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141109100801.gc14...@raptor.chemicalconnection.dyndns.org
Re: Two years later and still no netatalk3 in jessie?
Hi Adrian, 2014-11-09 10:48 GMT+01:00 Adrian Knoth : > On Thu, Aug 28, 2014 at 01:21:04PM -0400, Igor Bernstein wrote: > >> - jessie freeze happens in 2 months > > Happened in the meantime :-/ > >> 2014/8/4 - Adrian updated the package to 3.1.3 >> adi's package (currently @ 3.1.3): >> https://github.com/adiknoth/netatalk-debian > > JFTR, I'm at 3.1.6. > > > The whole situation reminds me of wine, where Debian shipped the same > outdated version for multiple releases. > > Even downstream distributions are suffering: > > > http://raspberrypi.stackexchange.com/questions/23985/why-is-netatalk-not-updated > > > I'd say get some devs behind this, call the package netatalk3 and ship > it in parallel. I had it running for months, upstream had worked on it > for years, it's not that this is bleeding edge or untested. IMHO the proper way of putting this package into focus is asking the maintainers to file an RFH bug if you don't want help yourself. Helping yourself can be submitting patches through BTS, packaging the new version and uploading it to mentors.debian.net or even hiring someone to do it for you. > > jessie without netatalk3 would be embarrassing at best, but more > importantly, it would be frustrating for everyone who wants to use their > Linux file servers as a time machine backup. Most probably Jessie will not contain netatalk 3, but having it in jessie-backports would be almost as good as having it in jessie. > > CC debian-devel for additional momentum. Please stop CCing this bug in > case this turns into another bike shedding discussions on the ML. Please try the RFH [1] way instead of CC-ing debian-devel. Packages/bugs needing more attention is business as usual and the RFH way is the standard procedure for dealing with it. While the procedure for ensuring better care for our packages (filing RFH, RFA, O bugs) do exist, we, maintainers are not proactive enough using the procedures. If you are a fellow DD/DM/sponsored uploader, please take a look at the packages BTS lists under your name and think for a moment if the package needs help or a new maintainer. Cheers, Balint [1]https://www.debian.org/devel/wnpp/#l2 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAK0OdpxrJr+MNTkJKDu0stoUC3LEeZP6J2m=bofc00fcnxu...@mail.gmail.com
Re: Two years later and still no netatalk3 in jessie?
On 2014-11-09 9:48, Adrian Knoth wrote: On Thu, Aug 28, 2014 at 01:21:04PM -0400, Igor Bernstein wrote: - jessie freeze happens in 2 months Happened in the meantime :-/ [...] I'd say get some devs behind this, call the package netatalk3 and ship it in parallel. I had it running for months, upstream had worked on it for years, it's not that this is bleeding edge or untested. Saying "people should do something" will not work. jessie without netatalk3 would be embarrassing at best, Well, as you noted, we've frozen. And there are no netatalk packages in the archive _anywhere_. So Jessie won't have them. CC debian-devel for additional momentum. Momentum for what? If you mean "to get it in to Jessie", then there is no need for momentum. It's not going to happen. Regards, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cde9230718a2c3af50f5b523bfb2c...@mail.adsl.funky-badger.org
Re: Two years later and still no netatalk3 in jessie?
On 2014-11-09 12:32, Adam D. Barratt wrote: On 2014-11-09 9:48, Adrian Knoth wrote: [...] jessie without netatalk3 would be embarrassing at best, Well, as you noted, we've frozen. And there are no netatalk packages in the archive _anywhere_. So Jessie won't have them. Pretend I didn't lose a "3" there. :( -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/6f9cf3f4bb363529c8b48e743af22...@mail.adsl.funky-badger.org
Re: Two years later and still no netatalk3 in jessie?
On Sun, 09 Nov 2014 12:32:37 + "Adam D. Barratt" wrote: > > jessie without netatalk3 would be embarrassing at best, > > Well, as you noted, we've frozen. And there are no netatalk packages > in the archive _anywhere_. So Jessie won't have them. s/netatalk/netatalk3/ ? netatalk 2.2.5 is in sid and wheezy but has an RC bug #751121, so did not migrate. So there'll be no netatalk package in Jessie, not 2.25 and not 3.* -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpPl2AiIYVjj.pgp Description: OpenPGP digital signature
Re: Please more fish (was: so long and thanks for all the fish)
On 11/08/2014 at 10:57 PM, Christoph Anton Mitterer wrote: > In the end it's quite easy: sysvinit has many deficiencies ans > missing feature, systemd is superior in all places. On 11/09/2014 at 12:01 AM, Christoph Anton Mitterer wrote: > All of these systems were capable of booting a Linux,... and you > really think one of them would have won sooner or later by technical > evolution? I doubt. The technical superior system was IMHO rather > clear from the beginning,... and it were political reasons that > prevented it from winning immediately. If you're *trying* to turn this into yet another systemd flamewar thread, you're certainly using the right sort of rhetoric. On 11/09/2014 at 01:28 AM, Michael Gilbert wrote: > Please actually read Joey's message to understand his concern, which > is not at all about content or systemd, but the harmful actions of > some project members and the complicity of others in those actions > over some significant time now. Agreed. (Or IHO harmful, at least - I'm not taking a position on that myself, not least because I probably haven't seen most of the actions in question.) -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Please more fish (was: so long and thanks for all the fish)
Le samedi 08 novembre 2014 à 23:30 -0500, Michael Gilbert a écrit : > No, the fire is not systemd, it is the politicization of the project > via ctte and GR rather than patient evolution of the best technical > solution. You are definitely right. However, I think we would all appreciate if you could be less antagonistic about it. Especially against the person in the CTTE who has been spending the most time digging actual technical solutions. The harm is done. The question is: how can we improve our decision-making process? -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1415538543.25061.5.camel@tomoyo
Re: Bug#768772: ITP: xkcdpass -- secure passphrase generator inspired by XKCD 936
On 09/11/14 08:21, Ben Finney wrote: > * Package name: xkcdpass ... > A flexible and scriptable password generator which generates strong > passphrases, inspired by XKCD 936: Does this have significant advantages over pwqgen, in the passwdqc package? How many bits of entropy does it typically produce? Example pwqgen output with default settings: % pwqgen wary$Nobody5leafy Regards, S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/545f6b5a.5040...@debian.org
Re: Reminder: Removing < 2048 bit keys from the Debian keyrings
On 8 November 2014 17:05, Thijs Kinkhorst wrote: > On Sat, November 8, 2014 17:09, Jonathan McDowell wrote: >> We had hoped to be down to a small number of special cases to deal with >> by this point, but with the numbers still looking this bad we're not >> yet at a stage where we can work out appropriate next steps for those >> special cases. > > In the list you post, I see lots of names of people I know to be inactive > for years now. Removing all those keys from the ring would therefore maybe > not be such a disaster, because the majority is no longer regularly > contributing to Debian. > > To make this a bit more concrete, I've matched the uids against echelon, > and this is the outcome: > > 160 2014 Can the keys last used in 2013 or earlier (and not yet special cased / migrating) be moved to non-uploading keyring? This should not have any impact - no recent uploading usage, yet can vote still be a DD, etc. > 42 2013 > 54 2012 > 31 2011 > 24 2010 > 31 2009 > 21 2008 > 17 2007 > 7 2006 > 5 2005 > 2 2004 > 1 2003 > 1 2002 > > So 160 keys were used this year, which is cause for concern if they are > removed. However, it means 236 keys have not seen use in 2014 yet. And of > those 160 keys have been used most recently in 2011; of those we can be > rather certain that removing their key from the ring actually confirms the > status quo rather than disrupt it. > > It therefore makes sense not to focus on the number of 436, but on the > ones that have actually been used in 2014; get that first number of 160 > closer to 0. > > > Cheers, > Thijs > > > -- > To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: > https://lists.debian.org/edbe948c76a3d7abd9d0f5d126b237f9.squir...@aphrodite.kinkhorst.nl > -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANBHLUg0dgsiAzQ3JkJKq3=_hie1y_dzhpek5zkmza12rqu...@mail.gmail.com
Re: What is the policy on audio group? and, proposal of a new group for the jack audio server
On Mon, Oct 27, 2014, at 02:58 AM, Marco d'Itri wrote: > On Oct 27, Kaj Ailomaa wrote: > > > Ok, so you are for removing audio group from user default groups? > Eventually, yes. > So, who determined that audio group will not be used as a default user group in Debian, and when you say eventually, do you mean Debian 9? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1415541225.645217.188812509.7715a...@webmail.messagingengine.com
Re: Bug#768772: ITP: xkcdpass -- secure passphrase generator inspired by XKCD 936
Excerpts from Simon McVittie's message of 2014-11-09 05:25:46 -0800: > On 09/11/14 08:21, Ben Finney wrote: > > * Package name: xkcdpass > ... > > A flexible and scriptable password generator which generates strong > > passphrases, inspired by XKCD 936: > > Does this have significant advantages over pwqgen, in the passwdqc package? > > How many bits of entropy does it typically produce? > > Example pwqgen output with default settings: > > % pwqgen > wary$Nobody5leafy With that, I have to remember that Nobody is capitalized, and that the spaces are replaced by $ and 5. The other approach accepts that we are forgetful and so uses spaces. But it also has the weakness that if the approach and the separators are suspected, one can very cheaply run a dictionary attack before brute forcing random characters (and in fact this is what many password cracking tools do). If you add in random separators and capitalization that does nearly achieve the proclaimed complexity that the xkcd article was suggesting. So it seems to this lay-person that pwqgen is a better choice. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1415541625-sup-7...@fewbar.com
Re: What is the policy on audio group? and, proposal of a new group for the jack audio server
On 09/11/14 13:53, Kaj Ailomaa wrote: > So, who determined that audio group will not be used as a default user > group in Debian As far as I know, nobody yet. Marco was expressing what he thinks should happen in future, not what has happened already. I agree with his opinion on this. > and when you say eventually, do you mean Debian 9? I think that would be a good timescale, yes. Members of the audio group can play and record[1] audio via remote logins, even when not physically present at the hardware. To me, that doesn't seem consistent with a "least astonishment" policy for users of a shared machine to have privacy from each other: if I have a private conversation "in real life" while using a shared computer, and Bob has an account on that computer but is not present or logged-in locally, it doesn't seem desirable for Bob to be able to record my conversation. On systems with infrastructure to adjust device ACLs during login, the audio group is unnecessary for normal operation: when you log in locally, the infrastructure can set the ACL to allow you to access the audio device nodes, and when you log out, it can remove that ACL entry. (One of the things systemd-logind does is that it is one implementation of that infrastructure; I think ConsoleKit was another.) As far as I'm aware, if a sysadmin wants to designate privileged users who can play and record audio without being logged-in locally, they can still add those users to the audio group. S [1] assuming a microphone is present; this has not traditionally been the case on desktop- or tower-style PCs, but many laptops do have a built-in microphone, and not all have a mute button or LED for it -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/545f7b52.2090...@debian.org
Re: Bug#768772: ITP: xkcdpass -- secure passphrase generator inspired by XKCD 936
On 09/11/14 14:25, Clint Byrum wrote: > With that, I have to remember that Nobody is capitalized, and that the > spaces are replaced by $ and 5. The other approach accepts that we are > forgetful and so uses spaces. But it also has the weakness that if the > approach and the separators are suspected, one can very cheaply run a > dictionary attack before brute forcing random characters (and in fact > this is what many password cracking tools do). It's a trade-off. I didn't say "this is unacceptable because...", I only asked the question. The cost of a dictionary attack goes up exponentially with the number of bits of entropy in the password or passphrase, which is why I asked how much entropy this tool has. IMO, the right way to assess the quality of the passphrases produced by one of these tools is to assume that the attacker knows which tool you use, and its settings (word list, whether to use punctuation, etc.), and see how many attempts it would take them with that knowledge; then compare that with how memorable the results are. Each bit of entropy doubles the number of possibilities that an attacker needs to try. pwqgen defaults to generating a passphrase with 47 bits of entropy. I think it primarily includes capitals, punctuation and digits as a workaround for sites that require passwords to contain these, rather than as a way to increase entropy: after all, randomly choosing whether each word has an initial capital only adds 1 bit of entropy per word. Diceware[1] is an implementation of a similar algorithm designed to be used via physical dice rather than a computer's pseudorandom number generator. It uses 5 die rolls to choose one of 7776 distinct words, and its author recommends a 6-word passphrase, resulting in about 77.5 bits of entropy. S [1] http://world.std.com/~reinhold/diceware.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/545f7ece.2070...@debian.org
Re: inconsistent versions of M-A: same packages
Hi Josch, On Sat, Nov 08, 2014 at 06:41:24AM +0100, Johannes Schauer wrote: > Hi, > > Quoting Ralf Treinen (2014-11-07 17:35:06) > > It just appeared to me that we probably do not have a syntax to pinpoint a > > package built for a specific architecture. "We" meaning in this case dpkg, > > apt, and dose (if I am not mistaken). > > No. We do have it. [...] > Dpkg and apt allow this just fine. Try to do: > > apt-get install --simulate gcc-4.9-arm-linux-gnueabihf > > And you will end up with a number of armhf packages on your system (you have > to > enable armhf beforehand of course). Interesting, I did not know this. Is this documented somewhere? I just looked through apt-get(1) man page and couldn't find it there. > > Once we can teach dose to accept the pseudo packages as described above we > > could run it with all the Packages files for all archiectures, which makes > > roughly 500.000 packages. > > This might fail not only because of M-A:same conflicts but also because some > packages just conflict with each other through a normal Conflicts:. You > probably need a clever way to partition dependencies. In my understanding these are precisely the cases which we want to find: packages which are supposed to be co-installable for different archiectures (since they are M-A=same), but which are not for some reason. I'll answer about the encoding in dose on the dose-devel list. Cheers -Ralf. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141109145815.gd10...@seneca.home.org
Re: Please more fish (was: so long and thanks for all the fish)
Hi, On 09/11/14 07:28, Michael Gilbert wrote: > On Sun, Nov 9, 2014 at 12:01 AM, Christoph Anton Mitterer wrote: >> On Sat, 2014-11-08 at 23:30 -0500, Michael Gilbert wrote: >>> No accusation, just a statement of fact. Four ctte members were >>> complicit in the vote [0] >> >> Well maybe I read that ruling wrong, but didn't it more or less say >> "we're not deciding anything right now"? >> >> And even if that decision would be the sole reason for Joey to leave > > Please actually read Joey's message to understand his concern, which > is not at all about content or systemd, but the harmful actions of > some project members and the complicity of others in those actions > over some significant time now. Please forgive my naiveness, but I do not understand what you are saying here. Now, I am just an "informed outsider" of this discussion, so maybe that was actually intentional. But I agree with Christoph that it looks to me like the decision in this case was not to have a decision. Also, five CTTE members agreed on that, so I don't understand where you got your number 4 from. I read Joey's message over and over without getting any more clues. He said the CTTE has "Decided it should make a decision", which it seems to me it did not. So I probably misunderstood something more fundamental here. Maybe you were intentionally vague, then please just disregard this message. I don't want to heat the discussion, just understand. Kind regards Ralf -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/545f83d3.90...@ralfj.de
Re: What is the policy on audio group? and, proposal of a new group for the jack audio server
On Sun, Nov 09, 2014 at 02:33:54PM +, Simon McVittie wrote: > On 09/11/14 13:53, Kaj Ailomaa wrote: > > So, who determined that audio group will not be used as a default user > > group in Debian > > As far as I know, nobody yet. Marco was expressing what he thinks should > happen in future, not what has happened already. I agree with his > opinion on this. > > > and when you say eventually, do you mean Debian 9? > > I think that would be a good timescale, yes. > > Members of the audio group can play and record[1] audio via remote > logins, even when not physically present at the hardware. To me, that > doesn't seem consistent with a "least astonishment" policy for users of > a shared machine to have privacy from each other: if I have a private > conversation "in real life" while using a shared computer, and Bob has > an account on that computer but is not present or logged-in locally, it > doesn't seem desirable for Bob to be able to record my conversation. On the other hand, it would break typical uses of using sound remotely. These days, shared computers are almost unheard of save for some school settings -- while loads of people have some raspi mediacenter or press some buttons on their phone to control sound coming from the big computer. Removing the primary user from the audio group would mean you need to do unobvious (for a non-sysadmin) configuration changes for something most people take for granted. -- // If you believe in so-called "intellectual property", please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable and Non-Discriminatory prices. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141109151954.ga17...@angband.pl
Re: Bug#768772: ITP: xkcdpass -- secure passphrase generator inspired by XKCD 936
Excerpts from Simon McVittie's message of 2014-11-09 06:48:46 -0800: > On 09/11/14 14:25, Clint Byrum wrote: > > With that, I have to remember that Nobody is capitalized, and that the > > spaces are replaced by $ and 5. The other approach accepts that we are > > forgetful and so uses spaces. But it also has the weakness that if the > > approach and the separators are suspected, one can very cheaply run a > > dictionary attack before brute forcing random characters (and in fact > > this is what many password cracking tools do). > > It's a trade-off. I didn't say "this is unacceptable because...", I only > asked the question. > > The cost of a dictionary attack goes up exponentially with the number of > bits of entropy in the password or passphrase, which is why I asked how > much entropy this tool has. IMO, the right way to assess the quality of > the passphrases produced by one of these tools is to assume that the > attacker knows which tool you use, and its settings (word list, whether > to use punctuation, etc.), and see how many attempts it would take them > with that knowledge; then compare that with how memorable the results > are. Each bit of entropy doubles the number of possibilities that an > attacker needs to try. > > pwqgen defaults to generating a passphrase with 47 bits of entropy. I > think it primarily includes capitals, punctuation and digits as a > workaround for sites that require passwords to contain these, rather > than as a way to increase entropy: after all, randomly choosing whether > each word has an initial capital only adds 1 bit of entropy per word. > > Diceware[1] is an implementation of a similar algorithm designed to be > used via physical dice rather than a computer's pseudorandom number > generator. It uses 5 die rolls to choose one of 7776 distinct words, and > its author recommends a 6-word passphrase, resulting in about 77.5 bits > of entropy. > Forgive my response. I seemed to forget everything I learned in the last 5 years about passwords after a trans-atlantic flight. Thanks for reminding me. ;) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1415547127-sup-8...@fewbar.com
Re: What is the policy on audio group? and, proposal of a new group for the jack audio server
Hi, > On the other hand, it would break typical uses of using sound remotely. > These days, shared computers are almost unheard of save for some school > settings -- while loads of people have some raspi mediacenter or press > some buttons on their phone to control sound coming from the big computer. This usually happens via UPnP or similar, though - the actual audio is ultimately done by a local user. So the audio group is unrelated to this usecase. Kind regards Ralf -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/545f8ff1.20...@ralfj.de
Re: inconsistent versions of M-A: same packages
Hi, Quoting Ralf Treinen (2014-11-09 15:58:15) > On Sat, Nov 08, 2014 at 06:41:24AM +0100, Johannes Schauer wrote: > > Dpkg and apt allow this just fine. Try to do: > > > > apt-get install --simulate gcc-4.9-arm-linux-gnueabihf > > > > And you will end up with a number of armhf packages on your system (you > > have to > > enable armhf beforehand of course). > > Interesting, I did not know this. Is this documented somewhere? I just looked > through apt-get(1) man page and couldn't find it there. it should definitely be documented in deb-control(5) but is not. I filed #768842. Otherwise, this is documented in https://wiki.ubuntu.com/MultiarchCross in sections "Cross-architecture dependencies" and "Toolchains". There is an ambiguity in the docs whether support for them was introduced in dpkg 1.16.2 or 1.16.7. Confusingly, support seems to have been implemented in dpkg git commit 7acf7afa which was released with version 1.16.5. In any case, wheezy has 1.16.15, so it definitely supports this. > > This might fail not only because of M-A:same conflicts but also because > > some packages just conflict with each other through a normal Conflicts:. > > You probably need a clever way to partition dependencies. > > In my understanding these are precisely the cases which we want to find: > packages which are supposed to be co-installable for different archiectures > (since they are M-A=same), but which are not for some reason. Ah okay! Somehow I misunderstood your initial email that you wanted to say: Depends: foo:i386, foo:amd64, ..., bar:i386, bar:amd64,... But instead you just want... Depends: foo:i386, foo:amd64, ... ...in one package and... Depends: bar:i386, bar:amd64,... ... in the other, right? This sounds very useful, because it does not make sense to mark a package M-A:same if they cannot actually be co-installed across architectures. Instead of creating dummy packages for this task, you can also use dose-deb-coinstall for this job. cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141109161810.6173.86072@hoothoot
Re: Two years later and still no netatalk3 in jessie?
On Sun, Nov 09, 2014 at 12:55:03PM +0100, Bálint Réczey wrote: > >> 2014/8/4 - Adrian updated the package to 3.1.3 > >> adi's package (currently @ 3.1.3): > >> https://github.com/adiknoth/netatalk-debian [..] > > I'd say get some devs behind this, call the package netatalk3 and ship > > it in parallel. I had it running for months, upstream had worked on it > > for years, it's not that this is bleeding edge or untested. > IMHO the proper way of putting this package into focus is asking the > maintainers to file an RFH bug if you don't want help yourself. > Helping yourself can be submitting patches through BTS, You surely have noticed that I actually provided proper Debian packaging in January 2014, right? And proper means 3.0/quilt workflow with signed tags, pristine-tar and everything. I've pinged the maintainers/bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=690227#65 I've updated the package in early August, pinged the bug plus the team mailinglist: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=690227#81 I've updated it a second time to 3.1.6 in late September. I think it's only fair to say that *I* actually did help. Read this timeline: From: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685878#16 2012/7/9 - netatalk 3.0 released upstream 2012/10/11 - Hideki started working on a 3.0.1 package using dh style instead of cdbs, but it was declined because of Jonas' wish to stick with cdbs 2013/3/18 - Igor posted a 3.0.1 cdbs package 2013/4/12 - Martin updated the cdbs package to 3.0.3 2014/1/11 - Tony built a 3.0.6 deb 2014/1/11 - Tony articulated the need for 3.0.6 due to problems w. time machine 2014/1/11 - Jonas stated intent to upgrade to 3.x but cited lack of time 2014/1/14 - Adrian cleaned up tony's 3.0.6 package and posted it 2014/2/10 - Jonas stated intent to continue to maintain the netatalk package & opened a mailing list on alioth 2014/4/18 - Brian cleaned up & updated Adrian's package to 3.1.1 2014/4/19 - Chris suggested to get netatalk 3.x into experimental asap to get it ready for jessie 2014/4/20 - Chris, Brian & Jonas collaborated & pushed 2.2.5 2014/8/4 - Adrian updated the package to 3.1.3 2014/8/27 - HAT reported that 3.1.6 is available 2014/9/29 - Adrian updated the package to 3.1.6 Add at least three wishlist bugs asking for netatalk 3.x, some as early as 2012. Two years of absolutely no progress, despite at least six people helping. I'm only a DM, I cannot upload foreign packages. And if it wasn't for the two friends who needed netatalk3, I wouldn't even care at all. But maybe, just maybe, at some point the maintainers should actually upload stuff? > Most probably Jessie will not contain netatalk 3, but having it in > jessie-backports would be almost as good as having it in jessie. I agree. So is there a DD who actually cares about netatalk? If so, clone my git repo and upload to experimental as suggested seven months ago. The usual git-buildpackage workflow. Or call it netatalk3 and upload it to sid, totally up to you. Or file a RFH bug on behalf of the netatalk maintainers that can be ignored for another two years. ;) Cheers PS: Just in case it wasn't obvious, I have absolutely no interest in maintaining netatalk. Not my package. -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141109162042.gi11...@ltw.loris.tv
Re: inconsistent versions of M-A: same packages
On Sun, Nov 09, 2014 at 05:18:10PM +0100, Johannes Schauer wrote:
>
> Ah okay! Somehow I misunderstood your initial email that you wanted to say:
>
> Depends: foo:i386, foo:amd64, ..., bar:i386, bar:amd64,...
>
> But instead you just want...
>
> Depends: foo:i386, foo:amd64, ...
>
> ...in one package and...
>
> Depends: bar:i386, bar:amd64,...
>
> ... in the other, right? This sounds very useful, because it does not make
> sense to mark a package M-A:same if they cannot actually be co-installed
> across
> architectures.
Yes, exactely.
> Instead of creating dummy packages for this task, you can also use
> dose-deb-coinstall for this job.
But this does only one co-installability check at a time, right ?
Anyway, the script is very simple (attached). The raw result of a run
for amd64 together with i386 can be found at [1]. What one can see from
a cursery inspection of that result :
We have 4415 MA=same packages that exist both in amd and i386 (main/sid).
I didn't expect it to be that many.
1033 of them are not co-installable.
Where they are not co-installable, the reason seems mostly to be that
the packages have dependencies which are not MA-enabled. The first case in
the list, for instance:
audacious-dbg-pseudo is MA=same but depends on audacious which is MA=no.
-Ralf.
[1] https://people.debian.org/~treinen/ma-same-coinstall-amd64-i386
#!/bin/sh
# finds packages with Multi-Arch=same for which the vesions in two different
# architectures are not co-installable.
# $1: name of the first architecture
# $2: Packages file of the first architecture
# $3: name of the second architecture
# $4: Packages file of the second architecture
arch1=$1
packages1=$2
arch2=$3
packages2=$4
archlist1=$(mktemp -t ${arch1}.)
grep-dctrl -F Multi-Arch same -s Package ${packages1} -n | sort > ${archlist1}
archlist2=$(mktemp -t ${arch2}.)
grep-dctrl -F Multi-Arch same -s Package ${packages2} -n | sort > ${archlist2}
(for p in $(comm -12 ${archlist1} ${archlist2})
do
echo 'Package:' ${p}-pseudo
echo 'Version: 1'
echo 'Architecture:' ${arch1}
echo 'Depends:' ${p}:${arch1}, ${p}:${arch2}
echo
done) | \
dose-debcheck\
--deb-native-arch=${arch1} --deb-foreign-archs=${arch2}\
--bg ${packages1} --bg ${packages2} -f -e
rm ${archlist1} ${archlist2}
Re: Please more fish (was: so long and thanks for all the fish)
On Sun, Nov 9, 2014 at 10:10 AM, Ralf Jung wrote: > I read Joey's message over and over without getting any more clues. He > said the CTTE has "Decided it should make a decision", which it seems to > me it did not. So I probably misunderstood something more fundamental here. Read all of #762194 very carefully. Note that no technical disagreement existed between project members, it was initiated by a committee member pushing a particular agenda with no consideration about his own conflict of interest, a technical solution that would have avoided mediation by the committee was in progress, no substantive thought or discussion occurred, and finally rubber stamping without any forethought to potential consequence (except from Steve). Yes, the Debian constitution right now allows the TC to misbehave like that. That is part of the constitutional crisis at hand. The TC power needs to be reigned in. Their actions should be limited solely to disagreement mediation, and only when that doesn't involve a conflict of interest pertaining to one of the TC members, and only when all other attempts at reconciliation have tried and failed. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANTw=MMpLLnnekz8c2w35sc=rzudvvg+9ytxvt_qni797is...@mail.gmail.com
Re: [Pkg-netatalk-devel] Bug#685878: Two years later and still no netatalk3 in jessie?
Quoting Adrian Knoth (2014-11-09 10:48:58) > On Thu, Aug 28, 2014 at 01:21:04PM -0400, Igor Bernstein wrote: > >> - jessie freeze happens in 2 months > > Happened in the meantime :-/ > >> 2014/8/4 - Adrian updated the package to 3.1.3 >> adi's package (currently @ 3.1.3): >> https://github.com/adiknoth/netatalk-debian > > JFTR, I'm at 3.1.6. Thanks to those helping out with Netatalk maintenance, including those working on the Netatalk3 branch! Please - those eager to get Netatalk3 into Debian - clone above Github URL, look at the FIXMEs in its debian/copyright file. Those need fixing for that work to enter Debian at all. If you do it soon and share your findings to <751...@bugs.debian.org>, then as a bonus you raise the chances of Netatalk2 getting into Jessie! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Jessie Freeze -> What is the next release name? (jessie+1)
Hi, Osamu Aoki: > I thought usually this type of announcement comes with next release > name. > > I was going to update web site (later) and debian-reference package (in > November) in proper timing. Did I miss some announcement? > See the debian-devel archives from mid-Fenruary 2014. According to Neil McGovern, the code name shall be "zurg". >>> https://lists.debian.org/debian-devel/2014/02/msg00905.html While that was in no way official, at the time it kindof struck a chord, so I'd like us to just go with it. After all the init/GR/what-have-you brouhaha, we can do with some levity. :-) -- -- Matthias Urlichs signature.asc Description: Digital signature
schroot and "shellshock"
Hi, A reminder for anyone using schroot to update their chroots. Most people will be running dash in the chroot, but if you're running bash you may be vulnerable. Please do update all your chroots. By default, schroot will filter the environment, but if you preserve the user environment with "-p", this will be passed to the shell in the chroot. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 signature.asc Description: Digital signature
Re: Please more fish (was: so long and thanks for all the fish)
On Sun, Nov 09, 2014 at 12:54:39PM -0500, Michael Gilbert wrote: > On Sun, Nov 9, 2014 at 10:10 AM, Ralf Jung wrote: > > I read Joey's message over and over without getting any more clues. He > > said the CTTE has "Decided it should make a decision", which it seems to > > me it did not. So I probably misunderstood something more fundamental here. > > Read all of #762194 very carefully. Note that no technical > disagreement existed between project members, it was initiated by a > committee member pushing a particular agenda with no consideration > about his own conflict of interest I don't understand why a member of TC should be disallowed to raise issues for the TC to discuss. Do you say that if, formally, the submitter would be any other of numerous people who see problems in replacing working inits by systemd, it would be perfectly ok, but if Ian did this this is no longer allowed? I see a choir of voices shaming Ian for "abusing the constitution". Yet it turns out it's you who's picking on a formality rather than the problem at hand. And the issue in #762194 is distinct than #727708 and the GR: #727708: what should be the default init system? #762194: should existing installations be changed? GR: can packages be tied to an init system? None of the above gives an answer to the other two. Thus, the issue Ian raised is valid. And since changing the init system on existing installations is an important _technical_ problem, it is in scope for the CTTE. Bottom line: Ian did nothing wrong. -- // If you believe in so-called "intellectual property", please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable and Non-Discriminatory prices. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141109181953.ga22...@angband.pl
Re: Reminder: Removing < 2048 bit keys from the Debian keyrings
On Sat, Nov 08, 2014 at 09:59:08PM +0100, Richard Hartmann wrote:
> Can you put this list, and a count, in a place I can wget from?
You've trimmed all context so I'm not entirely clear if you're looking
for the key list or something else. If it's the key list you should be
able to calculate it yourself from the keyrings:
rsync -az keyring.debian.org::keyrings/keyrings/ .
gpg --no-default-keyring --list-keys --with-colons \
--keyring ./debian-keyring.gpg \
--keyring ./debian-maintainers.gpg | \
awk -F ':' '/^pub:.:1024:/ { print $5 " " $10 }'
This will give slightly more people than my list as I effectively did
the above on our working tree, which is not public, while the rsync will
provide the currently active keyring. At present the above lists 468
contributors, while the active tree has 429 with weak keys.
J.
--
] http://www.earth.li/~noodles/ []I'm a consultant because I'd [
] PGP/GPG Key @ the.earth.li [] rather be self-unemployed. [
] via keyserver, web or email. [] [
] RSA: 4096/2DA8B985[] [
signature.asc
Description: Digital signature
Re: Jessie Freeze -> What is the next release name? (jessie+1)
On 2014-11-09 9:23, Matthias Urlichs wrote: See the debian-devel archives from mid-Fenruary 2014. According to Neil McGovern, the code name shall be "zurg". https://lists.debian.org/debian-devel/2014/02/msg00905.html While that was in no way official, at the time it kindof struck a chord, so I'd like us to just go with it. I'm afraid you're going to be disappointed; see d-d-a earlier today. Regards, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/578f9520761220405657ac58d0b14...@mail.adsl.funky-badger.org
Re: Please more fish (was: so long and thanks for all the fish)
On 2014-11-09 18:19, Adam Borowski wrote: And since changing the init system on existing installations is an important _technical_ problem, it is in scope for the CTTE. Where does the constitution make "important technical problems" in scope for the tech committee? (Not being awkward, but there's a reason that they're explicitly chartered to make decisions _as a point of last resort_.) Regards, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2ec0e5d4aa41bd836ea2d3d82db8b...@mail.adsl.funky-badger.org
Re: [Pkg-netatalk-devel] Bug#685878: Two years later and still no netatalk3 in jessie?
On Sun, 09 Nov 2014 19:04:42 +0100 Jonas Smedegaard wrote: > Quoting Adrian Knoth (2014-11-09 10:48:58) > > On Thu, Aug 28, 2014 at 01:21:04PM -0400, Igor Bernstein wrote: > > > >> - jessie freeze happens in 2 months > > > > Happened in the meantime :-/ > > > >> 2014/8/4 - Adrian updated the package to 3.1.3 > >> adi's package (currently @ 3.1.3): > >> https://github.com/adiknoth/netatalk-debian > > > > JFTR, I'm at 3.1.6. > > Thanks to those helping out with Netatalk maintenance, including > those working on the Netatalk3 branch! > > Please - those eager to get Netatalk3 into Debian - clone above > Github URL, look at the FIXMEs in its debian/copyright file. Those > need fixing for that work to enter Debian at all. > > If you do it soon and share your findings to > <751...@bugs.debian.org>, then as a bonus you raise the chances of > Netatalk2 getting into Jessie! Don't raise hopes, Jonas. The opportunity for getting packages removed from testing before the freeze began, back into testing has closed. netatalk2 is not in testing. Fixing the RC bug now is too late to get the package back into testing. (I forgot this when I did the same with midori #768458 - the unblocked was refused.) E: package midori not in testing -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpITlwk6lgx3.pgp Description: OpenPGP digital signature
Re: Bug#768329: grub-common: Please enable splash for jessie
* Colin Watson [141106 16:32]: > In principle this makes sense; I'm just a bit nervous about this at this > point, and changing this will cause a ucf prompt for large numbers of > people, so I want to get it right first time. CCing debian-devel; does > anyone know of reasons why adding "splash" to the default command line > would be a bad thing? I just did a test upgrade from wheezy to jessie, and it appears that there is already a ucf prompt for /etc/default/grub (removal of OS prober settings). -- ,''`. Christian Hofstaedtler : :' : Debian Developer `. `' 7D1A CFFA D9E0 806C 9C4C D392 5C13 D6DB 9305 2E03 `- signature.asc Description: Digital signature
Re: [Pkg-netatalk-devel] Bug#685878: Two years later and still no netatalk3 in jessie?
Quoting Neil Williams (2014-11-09 19:53:38) > On Sun, 09 Nov 2014 19:04:42 +0100 > Jonas Smedegaard wrote: > >> Quoting Adrian Knoth (2014-11-09 10:48:58) >>> On Thu, Aug 28, 2014 at 01:21:04PM -0400, Igor Bernstein wrote: >>> - jessie freeze happens in 2 months >>> >>> Happened in the meantime :-/ >>> 2014/8/4 - Adrian updated the package to 3.1.3 adi's package (currently @ 3.1.3): https://github.com/adiknoth/netatalk-debian >>> >>> JFTR, I'm at 3.1.6. >> >> Thanks to those helping out with Netatalk maintenance, including >> those working on the Netatalk3 branch! >> >> Please - those eager to get Netatalk3 into Debian - clone above >> Github URL, look at the FIXMEs in its debian/copyright file. Those >> need fixing for that work to enter Debian at all. >> >> If you do it soon and share your findings to >> <751...@bugs.debian.org>, then as a bonus you raise the chances of >> Netatalk2 getting into Jessie! > > Don't raise hopes, Jonas. The opportunity for getting packages removed > from testing before the freeze began, back into testing has closed. Thanks for your concern, but don't worry: Since the rejection of Nodejs for Wheezy (in working condition for quite some time but stalled until days before freeze by a tech-ctte ruling), my hopes for getting anything done during freeze has been low. But not lower than low. > netatalk2 is not in testing. Fixing the RC bug now is too late to get > the package back into testing. Freeze != release. We do not know if too late - it might be that bugfix need zero change to the package, and that release team treats that as acceptable. > (I forgot this when I did the same with midori #768458 - the unblocked was > refused.) > E: package midori not in testing That rejection is indeed quite unfortunate. My appreciation for midori is (half of) reason Jessie will not have a Debian Pure Blend for Designers: https://packages.qa.debian.org/d/debian-design.html I do still have (low but existing) hope that that midori rejection is not a definitive indication for netatalk. Release team explanation for rejecting Nodejs was lack of time in unstable, which arguably is similar for midori bugfix too, but might is not for netatalk bugfix. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Please more fish
On Sat, Nov 08, 2014 at 08:20:29PM -0800, Russ Allbery wrote: > I thought Zlatan's message was beautiful, and it really touched me, and I > wanted to say that. It may have been better if I'd said that in private. No, such public appreciation messages are a pleasure to read. Please do not refrain in future. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141109195523.ge29...@chew.redmars.org
Re: Bug#768329: grub-common: Please enable splash for jessie
On Thu, Nov 06, 2014 at 05:19:40PM +0100, Christian Hofstaedtler wrote: > Nothing in a default install currently Depends or Recommends > plymouth, so don't worry about getting a graphical splash screen or > anything. Anyway, if you were to install plymouth, the default > "theme" is *text*. In other words, plymouth installed but no 'splash' argument to the boot results in no change; adding 'splash' results in plymouth being activated albeit in text mode (so no modechange?) > Plymouth is a terminal multiplexer. Without it, if, f.e., there is > prompting for an encrypted disk passphrase, you'll end up with other > messages writing over the password prompt and so on. [1] With plymouth > installed you'll get a nice standalone prompt for the passphrase. > I imagine this being the same for systemd and upstart and any other > event-based inits. > http://web.dodds.net/~vorlon/wiki/blog/Plymouth_is_not_a_bootsplash/ > has some additional background. I'm reminded that the plymouth package short and long descriptions need adjusting to reflect this as they are presently quite misleading (but I'm as guilty as anyone else for not filing a wishlist bug for this yet, let alone supplying suggested text) > Why's there a new boot parameter? > > I don't know, but currently at least Ubuntu, Tanglu (both via > grub-common), and Fedora do it this way. > It's certainly nice to have the parameter so the recovery boot > option can skip plymouth (esp. if you were to enable a graphical > theme). I presume the option is interpreted by systemd or plymouth, rather than the kernel. (raises an interesting question, where is this handled, and is it handled differently for different init systems?) I see no reason why Debian couldn't default to the opposite (plymouth installed? plymouth runs - some 'nosplash' command line argument passed? plymouth doesn't run) if that was determined to be preferential. IMHO on-by-default is a good idea, especially if boot-time password prompts are likely useless without it (at least with systemd, but this is functionally a regression from wheezy). -- Jonathan Dowland -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141109200345.gf29...@chew.redmars.org
Re: "done with consensus decisionmaking", "war", "rearguard battles" [was: Re: REISSUED CfV: General Resolution: Init system coupling]
[CCed to a wider audience, but reply-to and mail-followup-to set to avoid a prolonged cross-list thread.] Sune Vuorela wrote: > I have a hard time assuming good faith from people who are at war. > > /Sune > > [17:35:34] > http://meetbot.debian.net/debian-ctte/2014/debian-ctte.2014-10-30-17.00.log.html Sune, Thank you for calling attention to that very disturbing IRC log. I'd recommend reading the whole thing, but I've called out a few particularly disturbing quotes below that make me quite done with assuming anything even remotely close to good faith anymore. (Note that "Diziet" is Ian's IRC nick.) 17:14:02 bdale: The GR is going to be another 3 weeks. 17:14:09 We should decide on the automatic switch before then IMO 17:15:30 I don't think it's reasonable to say that we need a tested alternative given how bad the situation is right now. (After repetition of the exact wording of the "We aren't convinced" wording that ended up passing, and people pointing out that it *will* be interpreted as TC opposition to the switch, which sure enough it did...) 17:34:12 Diziet: I don't think that stating that we don't want to swap on upgrades is something we can agree on 17:34:25 Diziet: at least, not while the GR is happening which seems to directly address this part of the question 17:34:28 dondelelcaro: That's not the question. The question is whether it's something that would pass a TC vote. 17:34:32 I'm done with consensus decisionmaking. 17:35:34 That's not to say I'm not open to convincing. But everything done by my opponents in this whole war has been done on a majoritarian basis and I see no reason to limit myself to consensual acts. 17:36:48 Diziet: we can always go to majoritarian, but if we can agree, so much the better. 17:37:17 dondelelcaro: I and my allies have been being shat on by the majoritarians since February. It's too late for that. (I'll also point out the pile of #action items Ian self-assigned, as well as the pile of times Ian has effectively self-referred items to the TC in the first place.) I've already felt from the more public portions of the TC discussions that Ian has been using the TC as a personal stick to hit people with. This makes it even more clear. See also Joey Hess's near-final mail at https://lists.debian.org/debian-ctte/2014/11/msg00045.html , pointing out the same issues. Calling this a war, being "done with consensus decisionmaking", "bitter rearguard battles" indeed... To put it bluntly: I don't believe this is even remotely acceptable behavior from a member of the TC (or a member of the project in general, but in the latter case someone has less potential to cause damage). Does anyone, in light of the above, feel even remotely comfortable having Ian continue to wield^Wserve on the technical committee? I don't care *how* you feel about init systems or any other issue; the above actions, tactics, and statements, and similarly consistent ones elsewhere are not even remotely acceptable on any side. The frothing-mad rampage and the battle-on-every-possible-front needs to end. I think it's safe to say that there's a substantial number of people hoping that the current GR will actually *settle* this question, with the project having spoken. We clearly have a pile of people who want to discuss and deal with the init system issue, many of whom are still capable of productive discussion and consensus-building. Many people are actively developing solutions to make the situation better. I've seen very impressive reasoning and careful judgement by various people in this and other issues. Russ Allbery comes to mind as the high standard we should expect from our TC members. And every other member of the TC, on *both* sides, seems quite reasoned and reasonable. So, at the risk of making things worse before they get better, since nobody else seems willing to explicitly say it: What's the procedure for removing someone from the technical committee? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141109202203.GA1700@thin
Re: "done with consensus decisionmaking", "war", "rearguard battles" [was: Re: REISSUED CfV: General Resolution: Init system coupling]
On Sun, 09 Nov 2014, Josh Triplett wrote: > (After repetition of the exact wording of the "We aren't convinced" > wording that ended up passing, and people pointing out that it *will* be > interpreted as TC opposition to the switch, which sure enough it did...) The "we are currently skeptical" wording was not present in the passed resolution; it was amended in 7a000[1]. That paragraph 4 of that decision could be interpreted as deciding the switching issue was only clear to me in retrospect, and was certainly not my intention (and I don't believe it reflects the intention of anyone else on the CTTE.) Indeed, paragraph 4 of that decision is actually a reflection of my personal reluctance to decide this issue in the CTTE without a very specific technical proposal and thorough testing. Especially considering that we would be overriding the transition plan announced in https://lists.debian.org/debian-devel/2014/07/msg00611.html at a very late date. See https://lists.debian.org/msgid-search/20141107211930.gm29...@teltox.donarmstrong.com for my specific response to this issue when it was raised. 1: http://anonscm.debian.org/cgit/collab-maint/debian-ctte.git/commit/?id=7a0009d350d57b89aa848f4d66a0b40959893373 -- Don Armstrong http://www.donarmstrong.com If you have the slightest bit of intellectual integrity you cannot support the government. -- anonymous -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141109212136.gg29...@teltox.donarmstrong.com
Re: Please more fish (was: so long and thanks for all the fish)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, On 09.11.2014 04:57, Christoph Anton Mitterer wrote: > In the end it's quite easy: sysvinit has many deficiencies ans > missing feature, systemd is superior in all places. - From your perspective. I can completely understand why we (and that includes me) want systemd as a default: it gives the best possible integration of desktop components possible. However, there are use cases where systemd does not work because of software design choices that, again, are in the best interest of its users. This is a common pattern in software development. When designing a complex system, you have two extremes: 1. A system that covers all use cases by building a minimal framework and letting users fill in the rest via a scripting language. 2. An elaborate system that simplifies use for the majority of cases, uses a descriptive language for configuration, and falls flat for any case that is out of scope. Neither approach is inherently "better" than the other, but they can be better suited for particular applications, and the choice which to use is up to the user. The vast majority of software in the world can be compiled by invoking a compiler on all source files, and passing the compiler output to a linker. With that knowledge, we can create a simple build system that needs nothing but the name of the project, whether it is a program or a library and a list of dependencies. - From the point of view of an application developer, this is the best thing since sliced bread. Comparing - --- SOURCES = foo.c bar.c OBJECTS = $(SOURCES:.c=.o) DEPENDS = $(SOURCES:.c=.d) PREFIX = /usr/local foo: $(OBJECTS) $(CC) -o $@ $^ %.o: %.c $(CC) -MD -MF $*.d -c $< %.d: touch $@ clean: $(RM) foo *.o *.d install: foo $(INSTALL) -d $(DESTDIR)$(PREFIX)/bin $(INSTALL) foo $(DESTDIR)$(PREFIX)/bin/ - -include $(DEPENDS) - --- with the much shorter - --- bin_PROGRAMS = foo foo_SOURCES = foo.c bar.c - --- I think it is immediately clear which one is preferable. However, I doubt you'd get far trying to move the Linux kernel to automake, as it has additional requirements that cannot be represented in this way, and extending automake to handle these is a herculean task. > The only thing *I* regret is that it's not really used to it's > full potential - i.e. in some places it rather seem we just try to > rebuild sysvinit in systemd, restricting ourselfs. The systemd architecture is, in my opinion, similar to automake. There is a descriptive language with lots of keywords, which allows you to do a lot of cool stuff easily, and at the same time, it is possible to leave the framework behind for missing functionality, with the same results for complexity and potential for error. The blog post[1] by joeyh about his alarm clock illustrates this, however you can already see that the framework is at its limits here, as it is necessary to run the job with root permissions so it can use an external tool to call back into the framework and inhibit lid switch handling while the job is running. At this point, I have to start asking questions: 1. What does "inhibit" mean? Will it ignore the events or just delay processing? 2. Is this behavior guaranteed, or is that an implementation detail? 3. Does this have security implications, like a lid switch event not being delivered to the screensaver? 4. Does this mean that other jobs will not start if they depend on the lid switch being open, when the lid was opened while the alarm clock was playing? 5. Is there a mechanism to be exempted from inhibit states? 6. If the events are queued, will similar events be coalesced, and will obsolete events be dropped? 7. Why "inhibit handling the lid switch"? Wouldn't it be better to have a mechanism to effect what we really want to do, stopping the system from going to sleep, rather than assuming that the reason the system would want to go back to sleep is the closed lid switch? The alarm clock example already escalated into a round of Cambridge Standard Five Cards Mao, with the condition of a rule being fulfilled leading to a temporary change of the rules. Managing this at a system level is a pure nightmare, especially when third party packages and local policies come into the mix as well. Restricting ourselves to a conservative default policy without any assumptions thus sounds sensible to me. One such assumption is whether we're running on a server, desktop or laptop system, which basically limits us to starting programs on conditions because we cannot really define a one-size-fits-all power policy. Simon [1] https://joeyh.name/blog/entry/a_programmable_alarm_clock_using_systemd/
Re: Please more fish (was: so long and thanks for all the fish)
2014-11-10 0:38 GMT+03:00 Simon Richter : > automake With autotools one can always use plain shell code in configure.ac and plain make in Makefile.am ;-) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/call-q8zejcqrokhyk0gxsczk+p6oz7ft8ro3jlawlkucmle...@mail.gmail.com
Re: "done with consensus decisionmaking", "war", "rearguard battles" [was: Re: REISSUED CfV: General Resolution: Init system coupling]
[Please CC me on replies.]
Don Armstrong wrote:
> On Sun, 09 Nov 2014, Josh Triplett wrote:
> > (After repetition of the exact wording of the "We aren't convinced"
> > wording that ended up passing, and people pointing out that it *will* be
> > interpreted as TC opposition to the switch, which sure enough it did...)
>
> The "we are currently skeptical" wording was not present in the passed
> resolution; it was amended in 7a000[1].
I stand corrected; thank you. However, I don't think that changes the
point. The resulting decision had effectively the same tone.
Linking to the resolution announcement for reference:
https://lists.debian.org/debian-devel-announce/2014/11/msg0.html
> That paragraph 4 of that decision could be interpreted as deciding the
> switching issue was only clear to me in retrospect, and was certainly
> not my intention (and I don't believe it reflects the intention of
> anyone else on the CTTE.)
I completely believe that it was not the intention of most of the people
voting for the resolution that passed. However, the combination of item
1 (explicitly narrowing the scope of the previous TC decision), item 4
(inviting proposals towards one specific approach), and item 5 ("After
the result of the General Resolution is known, we intend to formally
resolve the question", as though the TC *should* continue to take action
after the GR) comes across as both threatening and interminable, and
makes it fairly clear what action the TC wants to take.
Furthermore, the very top of the announcement in
https://lists.debian.org/debian-devel-announce/2014/11/msg0.html is
a lie of omission as well: "The technical committee was asked". As Joey
Hess put it in
https://lists.debian.org/debian-ctte/2014/11/msg00045.html:
> I am astounded that, in #762194, the technical committe has
>
> 1. Decided it should make a decision, when no disagreement
>between maintainers of affected packages is involved.
> 2. Ignored evidence of ongoing work.
>(specifically, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762194#25)
> 3. Plowed ahead with a vote that decides a massively complicated
>issue with a grand total of 3 days of discussion.
>
> This is not a decision-making process that will yeild a high-quality
> distibution. Or one that I can be proud to be involved with. Or one
> that, frankly, gives me any confidence in the technical committee's
> current membership or indeed reason to continue to exist.
I agree almost completely with Joey's thoughts above, with one
exception. Personally, I still have plenty of confidence in almost all
of the technical committee's current membership, including those on
*both* sides of the current debate, with one very glaring exception.
I would also suggest that it's a bad idea to let a single member of an
arbitration body refer in a pile of issues, write up draft resolutions
for those issues, push for rapid discussion and votes on those issues,
and send out the resulting decisions. Those do not seem like signs of a
healthy process, and they certainly contribute to the impression of the
TC being used as a weapon.
- Josh Triplett
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141109220125.GA1457@thin
Re: Please more fish (was: so long and thanks for all the fish)
Michael Gilbert wrote: > How can you possibly think no more need said? You are one of four > complicit in the act that finally pushed Joey over the edge [0]. > > [0] https://lists.debian.org/debian-ctte/2014/11/msg00045.html Please take that message with a pound of salt. I was upset when I wrote it, it's probably not accurate, and I've left[1] for reasons that are much more broadly structural, and are certianly not the fault of the technical committee, or indeed of any one person. -- see shy jo [1] Almost. Still need to orphan git-annex, git-repair, and github-backup. #768516: (O: etckeeper -- store /etc in git, mercurial, bzr or darcs) #768518: (O: mpdtoys -- small command line tools and toys for MPD) #768520: (O: liblingua-en-words2nums-perl - convert English text to numbers) #768525: (O: jetring) #768527: (O: pdmenu -- simple console menu program) #768528: (O: ticker) #768529: (O: moreutils -- additional Unix utilities) #768530: (O: filters) signature.asc Description: Digital signature
Re: "done with consensus decisionmaking", "war", "rearguard battles" [was: Re: REISSUED CfV: General Resolution: Init system coupling]
* Don Armstrong (d...@debian.org) [141109 22:22]: > On Sun, 09 Nov 2014, Josh Triplett wrote: > > (After repetition of the exact wording of the "We aren't convinced" > > wording that ended up passing, and people pointing out that it *will* be > > interpreted as TC opposition to the switch, which sure enough it did...) > > The "we are currently skeptical" wording was not present in the passed > resolution; it was amended in 7a000[1]. > > That paragraph 4 of that decision could be interpreted as deciding the > switching issue was only clear to me in retrospect, and was certainly > not my intention (and I don't believe it reflects the intention of > anyone else on the CTTE.) I fully agree to that statement (and to the rest of your mail). > Indeed, paragraph 4 of that decision is actually a reflection of my > personal reluctance to decide this issue in the CTTE without a very > specific technical proposal and thorough testing. Also, we shouldn't decide on things not ready, and so in case someone would like the ctte to overrule here, there is just no ground currently. So anyone wanting a specific decision from the ctte (like "the default shouldn't switch on dist-upgrade", "the default should switch on dist-upgrade", or whatever else) needs to show before the decision that this is reasonable possible, what are the downsides of the decision and also why the ctte needs to decide (especially as the ctte only decides as last-resort). Details see paragraph 4, for any decision. So we could clone paragraph 4 to an 4a, 4b etc for any of other cases people would like us to decide here. In hindsight it might have been better to not decide yet but to suspend that topic until we had that plan but it's easier to say so afterwards. In theory our decision is nothing else, but some people interpret it different which makes me quite sad. Andi -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141109221450.gb...@mails.so.argh.org
Re: Please more fish (was: so long and thanks for all the fish)
On Sun, 2014-11-09 at 18:12 -0400, Joey Hess wrote: > I've left[1] + >Almost. So you still could (and perhaps should[0]) reconsider not to leave Debian. Guess you've read the lists and saw how many people were emotionally hit and upset about this. (well I think it's worth a try ^^) Cheers, Chris. [0] Even though I don't believe you just randomly decided to leave in the first place. smime.p7s Description: S/MIME cryptographic signature
Re: so long and thanks for all the fish
On Fri, Nov 7, 2014 at 10:04 PM, Joey Hess wrote: > It's become abundantly clear that this is no longer the project I > originally joined in 1996. We've made some good things, and I wish > everyone well, but I'm out. see shy jo :( Richard -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cad77+gskxgomhyzkh22d1tb3ikcwswdjkypvfmo0jcmkhv6...@mail.gmail.com
Re: Please more fish (was: so long and thanks for all the fish)
On Sun, 2014-11-09 at 22:38 +0100, Simon Richter wrote: > I can completely understand why we (and that includes me) want systemd > as a default: it gives the best possible integration of desktop > components possible. I even think it's best on a server (that means, if it was used as it could be)... With sysvinit it was basically not possible to make any guarantees, e.g. like start XYZ only when firewall rules were successfully loaded, at least not in a systematic fashion. Or things like: When iptables rules are reloaded, stop fail2ban before, restart it afterwards. Unforunately, even if systemd would support such nice things, nothing of this is deployed to the masses,... which is also why I wrote, that it sometimes feels as if we'd only try to map sysvinit into systemd. > However, there are use cases where systemd does not work because of > software design choices that, again, are in the best interest of its > users. Well I guess that goes back into the init-system discussion ^^ That being said, I personally would welcome, if it was policy that it's not allowed to require a specific init-system (unless specifically related software). > This is a common pattern in software development. When designing a > complex system, you have two extremes: > > 1. A system that covers all use cases by building a minimal framework > and letting users fill in the rest via a scripting language. ... which, especially in the complex cases, often lead to just more problems... I mean it's of course nice to be able to edit the init-scripts, add debug output, or adapt something to one's own very personal need. But often this also just means that either one isn't doing things right in the first place OR that the init script wasn't generically configurable enough. > 2. An elaborate system that simplifies use for the majority of cases, > uses a descriptive language for configuration, and falls flat for any > case that is out of scope. > > Neither approach is inherently "better" than the other, but they can > be better suited for particular applications, and the choice which to > use is up to the user. Which is why I'm definitely in favour of init-system diversity. > I think it is immediately clear which one is preferable. However, I > doubt you'd get far trying to move the Linux kernel to automake, as it > has additional requirements that cannot be represented in this way, > and extending automake to handle these is a herculean task. Well I for the matter always hated autotools... (perhaps one should lobby Linus for CMake? ;) )... I think: an init-system shouldn't be programming,... one could always see that this basic idea is somehow broken, when programs (shell scripts) need to go to /etc,... and when people realised that this causes only troubles, they've started trying to make them generic enough to handle all cases and configurable via /etc/default/* > The systemd architecture is, in my opinion, similar to automake. Well, in a way, surely... but then one need to question: Should an init system be a universal programming language or should it be a systematised framework to boot the system, start software and perhaps manage all this after boot. And *I* don't think it should be a universal programming language. In most cases where I've ever needed to manipulate init-scripts and doing "advanced" things, like not only starting one apache http but several, running as different user and that like (which is IIRC nowadays even supported by the init script, at least partially), one could also simply say, that the original init script was simply not powerful enough and should have been implemented better in the first place, to avoid any need to manipulate it. And speaking of things like autotools,... I'd also say that the world has mostly just benefit from systematising build procedures. > Restricting ourselves to a conservative default policy without any > assumptions thus sounds sensible to me. One such assumption is whether > we're running on a server, desktop or laptop system, which basically > limits us to starting programs on conditions because we cannot really > define a one-size-fits-all power policy. Uhm, I absolutely agree with that,... but I don' think it's a problem of systemd per se - it's rather a problem of how it's used/configured. Unfortunately the general direction seems to be to assume a single user PC or even tablet,... which is why we have default settings like: mount a USB stick if plugged in, or what I recently found in virt-manager/libvirt/spice,... forward any usb stick plugged in automatically to guest VMs. But these problems aren't inherent to systemd or polkit,... it's rather bad default decisions being made by people who have only their won usage scenario in mind. This is one of the main reasons why I got more and more of a gnome and utopia-stuff critic. I also think it's potentially dangerous when systemd upstrem tries to "revolutionise" more and more things, which go far beyond any
Re: Bug#768329: grub-common: Please enable splash for jessie
* Jonathan Dowland [141109 21:04]: > In other words, plymouth installed but no 'splash' argument to the boot > results in no change; adding 'splash' results in plymouth being activated > albeit in text mode That is my observation, yes. > (so no modechange?) Not by the default plymouth setup; the kernel does a KMS init in any case, whether plymouth is installed or not. > > Why's there a new boot parameter? > > > > I don't know, but currently at least Ubuntu, Tanglu (both via > > grub-common), and Fedora do it this way. > > It's certainly nice to have the parameter so the recovery boot > > option can skip plymouth (esp. if you were to enable a graphical > > theme). > > I presume the option is interpreted by systemd or plymouth, rather than the > kernel. (raises an interesting question, where is this handled, and is it > handled differently for different init systems?) I see no reason why Debian > couldn't default to the opposite (plymouth installed? plymouth runs - some > 'nosplash' command line argument passed? plymouth doesn't run) if that was > determined to be preferential. IMHO on-by-default is a good idea, especially > if boot-time password prompts are likely useless without it (at least with > systemd, but this is functionally a regression from wheezy). There's sysvinit (/etc/init.d/plymouth) and systemd (/lib/systemd/system/*/plymouth*) specific code for the 'splash' command line option, plus some additional code for initramfs-tools. I think the current behaviour should be retained for these reasons: - GRUB has a way of passing additional options to the "default" boot option, but it can't do that for the "recovery" option (so no way to pass nosplash from /etc/default/grub) - We don't unnecessarily deviate from other distros for no good reason. On-by-default is likely a good idea, which is why I'd like to see 'splash' being added to /e/d/g. -- ,''`. Christian Hofstaedtler : :' : Debian Developer `. `' 7D1A CFFA D9E0 806C 9C4C D392 5C13 D6DB 9305 2E03 `- pgpRTnQsG8hCG.pgp Description: PGP signature
Re: What is the policy on audio group? and, proposal of a new group for the jack audio server
* Ralf Jung [141109 17:02]: > Hi, > > > On the other hand, it would break typical uses of using sound remotely. > > These days, shared computers are almost unheard of save for some school > > settings -- while loads of people have some raspi mediacenter or press > > some buttons on their phone to control sound coming from the big computer. > > This usually happens via UPnP or similar, though - the actual audio is > ultimately done by a local user. So the audio group is unrelated to this > usecase. It very much is, because those users are usually daemon users that are not logged in through a session manager, and thereby don't get access granted by PolicyKit (or equiv). -- ,''`. Christian Hofstaedtler : :' : Debian Developer `. `' 7D1A CFFA D9E0 806C 9C4C D392 5C13 D6DB 9305 2E03 `- pgpNUvb5czB6Z.pgp Description: PGP signature
Re: Bug#768772: ITP: xkcdpass -- secure passphrase generator inspired by XKCD 936
Simon McVittie writes: > Does [xkcdpass] have significant advantages over pwqgen, in the > passwdqc package? Significant advantages: * ‘xkcdpass’ provides an implementation of a much-discussed scheme for strong passphrase generation. (Which is not to say the results are stronger than all others; only that these are relatively strong.) I don't know of any other tool implementing the scheme discussed in XKCD 936. * The passphrases produced by ‘xkcdpass’ have, compared with other schemes, excellent properties for accurate human memorisation (meaningful words with normal spelling, no punctuation) while still being acceptably strong for many uses. Since both these are true – the passphrases are strong, and the other properties are interesting and useful – this IMO makes the tool sufficiently unique to be included in Debian. > How many bits of entropy does it typically produce? The example given at the top of its web page merely reproduces the four-word example from XKCD 936 (presumably for easy association with the existing meme). As discussed there, this would be 44 bits of entropy. The tool by default produces longer passphrases: $ xkcdpass included soundless instruct housecoat arena shove $ xkcdpass millionth legume styling traveller fleeting gallon $ xkcdpass dumpiness androgyny radii domiciled ribaldry determine >From a small dictionary of common words, say 2000–3000, a single randomly-chosen word has about 11 bits (= log₂(2048)) of entropy. So these passphrases have around 66 bits of entropy. Given that these passphrases are quite strong *and* have comparatively superior properties for human memorisation, I think this tool deserves inclusion in Debian. -- \ “The process by which banks create money is so simple that the | `\ mind is repelled.” —John Kenneth Galbraith, _Money: Whence It | _o__) Came, Where It Went_, 1975 | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/8561eoc5jz@benfinney.id.au
Re: What is the policy on audio group? and, proposal of a new group for the jack audio server
On 09/11/14 23:34, Christian Hofstaedtler wrote: >>> On the other hand, it would break typical uses of using sound remotely. >> >> This usually happens via UPnP or similar, though - the actual audio is >> ultimately done by a local user. So the audio group is unrelated to this >> usecase. > > It very much is, because those users are usually daemon users that > are not logged in through a session manager, and thereby don't get > access granted by PolicyKit (or equiv). Fine, put those daemon users in the audio group - in their packages' postinst scripts, if necessary. I'm not saying that the audio group should be abolished, only that "normal user" accounts (as created by d-i, gnome-control-center, etc.) should ideally not be members of it. FYI, PolicyKit is not actually relevant here: the actual access control for (most uses of) the audio group is done by the kernel, when an application running as the target user (often something like PulseAudio or JACK, rather than the actual user-facing application) tries to open the audio device nodes. systemd-logind implements "locally-logged-in users may use audio devices" by setting ACLs on the device nodes for those users: % getfacl /dev/snd/pcmC0D0p getfacl: Removing leading '/' from absolute path names # file: dev/snd/pcmC0D0p # owner: root # group: audio user::rw- user:smcv:rw- group::rw- mask::rw- other::--- (In this case, smcv is the only locally-logged-in user.) S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/545ffecd.4050...@debian.org
Re: inconsistent versions of M-A: same packages
Hi,
Quoting Ralf Treinen (2014-11-09 18:05:15)
> But this does only one co-installability check at a time, right ?
correct, this makes your solution the better choice.
> Anyway, the script is very simple (attached).
Nifty! I didn't know that dose-debcheck can read from stdin!
> The raw result of a run for amd64 together with i386 can be found at [1].
> What one can see from a cursery inspection of that result :
>
> We have 4415 MA=same packages that exist both in amd and i386 (main/sid).
> I didn't expect it to be that many.
>
> 1033 of them are not co-installable.
>
> Where they are not co-installable, the reason seems mostly to be that
> the packages have dependencies which are not MA-enabled. The first case in
> the list, for instance:
>
> audacious-dbg-pseudo is MA=same but depends on audacious which is MA=no.
On top of that it seems that there are many instances where the reason for a
package not being co-installable is a package from the same source package.
Thus, it would probably be very helpful to generate this information regularly
and display in the pts/tracker if a package makes another one
un-co-installable.
Here some quick results of why packages are not co-installable:
Missing:
>>> import yaml
>>> from collections import Counter
>>> d = yaml.load(open("out"))
>>> Counter([p['reasons'][0].get('missing',
>>> {'pkg':{'unsat-dependency':0}})['pkg']['unsat-dependency'] for p in
>>> d['report']])
Gives as the top 10:
[unsat dependency] [X times encountered]
ttf-bitstream-vera 22
dh-python18
poppler-data (>= 0.4.5-3~) | gs-cjk-resource 16
augeas-lenses15
libgsf-1-common (>= 1.14.30-2) 9
lxmenu-data 8
openmpi-common (= 1.6.5-9) 6
krb5-config 4
vlc-plugin-pulse 4
gnat 3
From a purely dependency point of view, the above would be solved by making the
packages depended upon by the first column Multi-Arch:foreign. Of course this
is not the technically correct solution in many cases.
Conflict:
>>> Counter([p['reasons'][0].get('conflict',
>>> {'pkg1':{'package':0}})['pkg1']['package'] for p in d['report']])
Gives as the top 10:
[packages][makes X packages not co-installable]
perl-base 147
libtbb2 43
libglib2.0-dev35
libglu1-mesa-dev 32
libatlas3-base24
liblog4cpp5 22
libboost1.54-dev 21
libevdev2 20
libopenmpi1.6 14
libgupnp-1.0-413
From a purely dependency point of view, the above would be solved by making the
packages in the first column Multi-Arch:same. Of cource this is not the
technically correct solution in many cases.
Incidentally, I was just producing very similar results in the realm of
crossbuild satisfiability today. Unsurprisingly, the results look very similar
to the above. I posted a message about this to the debian-cross list today:
https://lists.debian.org/20141109152937.6173.82192@hoothoot
The important links from that message:
1. http://bootstrap.debian.net/cross.html (regenerated daily with 550 source
packages)
2. https://mister-muffin.de/p/Lc4-.html (static but all of sid)
3. https://mister-muffin.de/p/xOJO.html (static and package selection as in 1.
but multiple reasons)
The two sections in all three above links are also "Missing" and "Conflicts",
just as I made the destinction above with Ralf's results.
cheers, josch
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/2014111009.6173.73845@hoothoot
Re: inconsistent versions of M-A: same packages
+++ Marc Glisse [2014-11-01 11:45 +0100]: > > A few random packages that currently have an inconsistent version: > zlib1g (+b1 on ppc64el) examining this I notice that whilst this page on p.d.o: https://packages.debian.org/jessie/zlib1g shows the issue, and so does this buildd one (for unstable): https://buildd.debian.org/status/package.php?p=zlib&suite=sid this one (testing buildd view) says all the versions are the same: https://buildd.debian.org/status/package.php?p=zlib&suite=jessie Is there any reason why the last URL shows the wrong version for ppc64el or is it just a bug? Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141110005906.gw28...@stoneboat.aleph1.co.uk
Re: Bug#768772: ITP: xkcdpass -- secure passphrase generator inspired by XKCD 936
Why are we still using passphrases at all? -- bye, pabs https://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caktje6hsb+lxgw3d112c1vahc2yau32uvsu-douyaolf6ck...@mail.gmail.com
A plea to worry about what matters, and not take ourselves too seriously
Good afternoon, This message comes on the heels of Sam Hartman's wonderful plea for compassion [1] and the sad news of Joey Hess's resignation from Debian [2]. I no longer frequently post to this list, but when you've been a Debian developer for 18 years, and still care deeply about the community and the project, perhaps you have a bit of perspective to share. Let me start with this: Debian is not a Free Software project. Debian is a making-the-world-better project, a caring for people project, a freedom-spreading project. Free Software is our tool. As many of you, hopefully all of you, I joined Debian because I enjoyed working on this project. We all did, didn't we? We joined Debian because it was fun, because we were passionate about it, because we wanted to make the world a better place and have fun doing it. In short, Debian is life-giving, both to its developers and its users. As volunteers, it is healthy to step back every so often, and ask ourselves two questions: 1) Is this activity still life-giving for me? 2) Is it life-giving for others? I have my opinions about init. Strong ones, in fact. [3] They're not terribly relevant to this post. Because I can see that they are not really all that relevant. 14 years ago, I proposed what was, until now anyhow, one of the most controversial GRs in Debian history. It didn't go the way I hoped. I cared about it deeply then, and still care about the principles. I had two choices: I could be angry and let that process ruin my enjoyment of Debian. Or I could let it pass, and continue to have fun working on a project that I love. I am glad I chose the latter. Remember, for today, one way or another, jessie will still boot. 18 years ago when I joined Debian, our major concerns were helping newbies figure out how to compile their kernels, finding manuals for monitors so we could set the X modelines properly, finding some sort of Free web browser, finding some acceptable Office-type software. Wow. We WON, didn't we? Not just Debian, but everyone. Freedom won. I promise you - 18 years from now, it will not matter what init Debian chose in 2014. It will probably barely matter in 3 years. This is not key to our goals of making the world a better place. Jessie will still boot. I say that even though my system runs out of memory every few days because systemd-logind has a mysterious bug [4]. It will be fixed. I say that even though I don't know what init system it will use, or how much choice there will be. I say that because it is simply true. We are Debian. We will make it work, one way or another. I don't post much on this list anymore because my personal passion isn't with posting on this list anymore. I make liberal use of my Delete Thread keybinding on -vote these days, because although I care about the GR, I don't care about it enough to read all the messages about it. I have not yet decided if I will spend the time researching it in order to vote. Instead of debating the init GR, sometimes I sit on the sofa with my wife. Sometimes I go out and fly the remote-control airplane I'm learning to fly. Sometimes I repair my plane after a flight that was shorter than planned. Sometimes I play games with my boys, or help them with homework, or share my 8-year-old's delight as a text file full of facts about the Titanic that he wrote in Emacs comes spitting out of the printer. Sometimes I write code or play with the latest Linux filesystems or build a new server for my basement. All these things matter more to me than init. I have been using Debian at home for almost 20 years, at various workplaces for almost that long, and it is not going to stop being a part of my life any time soon. Perhaps I will have to learn how to administer a new init system. Well, so be it; I enjoy learning new things. Or perhaps I will have to learn to live with some desktop limitations with an old init system. Well, so be it; it won't bother me much anyhow. Either way, I'm still going to be using what is, to me, the best operating system in the world, made by one of the world's foremost Freedom projects. My hope is that all of you may also have the sense of peace I do, that you may have your strong convictions, but may put them all in perspective. That we as a project realize that the enemy isn't the lovers of the other init, but the people that would use law and technology to repress people all over the world. We are but one shining beacon on a hill, but the world will be worse off if our beacon winked out. My plea is that we each may get angry at what matters, and let go of the smaller frustrations in life; that we may each find something more important than init/systemd to derive enjoyment and meaning from. [5] May you each find that airplane to soar freely in the skies, to lift your soul so that the joy of using Free Software to make the world a better place may still be here, regardless of what /sbin/init is. [1] https://lists.debia
Re: Bug#768772: ITP: xkcdpass -- secure passphrase generator inspired by XKCD 936
Paul Wise writes: > Why are we still using passphrases at all? This is only temporary, as we transition to uncrackable brain–computer interfaces for every device. Until that future arrives for every device, I'd like people who use those remaining services still requiring passphrases, to have tools for generating good passphrases. -- \ “Leave nothing to chance. Overlook nothing. Combine | `\ contradictory observations. Allow yourself enough time.” | _o__) —Hippocrates | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/85tx27bxvx@benfinney.id.au
Re: inconsistent versions of M-A: same packages
+++ Wookey [2014-11-01 14:19 +]: > +++ Marc Glisse [2014-11-01 11:45 +0100]: > > Hello, > > > > sorry for the naive question, but is there a plan for massively > > rebuilding all "Multi-Arch: same" packages that have inconsistent > > version numbers across architectures before releasing Jessie? > > I am happy to spend some time scheduling rebuilds to resync all arches > to whichever number is highest. If I schedule rebuilds for expat (for example), to get all arches to +b3, I then need to check if anything has a versioned dep on libexpat1 that this will break, and then rebuild those too, right? OK. in fact some grep-dctrl runes suggest that nothing in the archive does, except libexpat1-dev, so that's OK. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141110024253.gx28...@stoneboat.aleph1.co.uk
Re: Bug#768772: ITP: xkcdpass -- secure passphrase generator inspired by XKCD 936
On Mon, Nov 10, 2014 at 10:19 AM, Ben Finney wrote: > This is only temporary, as we transition to uncrackable brain–computer > interfaces for every device. I'm not looking forward to the denial-of-service attacks that could introduce :) > Until that future arrives for every device, I'd like people who use > those remaining services still requiring passphrases, to have tools for > generating good passphrases. I would encourage this approach: For remote services that don't yet support sane authentication mechanisms (anything other than a passphrase), complain to their operators, use very long non-memorable randomly generated passphrases (since those have more entropy), automatically rotate them regularly (I joke, rotation of keys/passphrases is still ridiculously impractical) and encrypt them using a local key. For local authentication and local keys, use pass-phrases that are generated using the diceware method (aka not on a computer) and strong enough that they will last until replacement. In both cases, something like xkcdpass isn't needed. -- bye, pabs https://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caktje6f_dm63zfpkbfrno_tmdvrrsnysdw4piz491tbz+my...@mail.gmail.com
Re: What is the policy on audio group? and, proposal of a new group for the jack audio server
* Simon McVittie [141110 00:55]: > On 09/11/14 23:34, Christian Hofstaedtler wrote: > >>> On the other hand, it would break typical uses of using sound remotely. > >> > >> This usually happens via UPnP or similar, though - the actual audio is > >> ultimately done by a local user. So the audio group is unrelated to this > >> usecase. > > > > It very much is, because those users are usually daemon users that > > are not logged in through a session manager, and thereby don't get > > access granted by PolicyKit (or equiv). > > Fine, put those daemon users in the audio group - in their packages' > postinst scripts, if necessary. I'm not saying that the audio group > should be abolished, only that "normal user" accounts (as created by > d-i, gnome-control-center, etc.) should ideally not be members of it. I fully agree; it's just that the audio group can't just vanish. > FYI, PolicyKit is not actually relevant here: the actual access control > for (most uses of) the audio group is done by the kernel, when an > application running as the target user (often something like PulseAudio > or JACK, rather than the actual user-facing application) tries to open > the audio device nodes. systemd-logind implements "locally-logged-in > users may use audio devices" by setting ACLs on the device nodes for > those users: > [..] I vaguely remember PolicyKit being involved in the daemon situation, when mpd tries to talk to a pulseaudio server which magically gets spawned ... I'll probably just have to figure out the details again when any of the moving bits change. Cheers, -- ,''`. Christian Hofstaedtler : :' : Debian Developer `. `' 7D1A CFFA D9E0 806C 9C4C D392 5C13 D6DB 9305 2E03 `- pgpOr3V1e568B.pgp Description: PGP signature
Re: Bug#768772: ITP: xkcdpass -- secure passphrase generator inspired by XKCD 936
Paul Wise writes: > I would encourage this approach: [not using memorable > computer-generated passphrases at all] Thanks for the recommendation; I don't agree it is suitable for the majority of Debian users. I'm working on the assumption – reasonable, I think – that generation of strong memorable passphrases is still a useful task in a free operating system today. -- \ “I must say that I find television very educational. The minute | `\ somebody turns it on, I go to the library and read a book.” | _o__)—Groucho Marx | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/85mw7zbvdv@benfinney.id.au
