Re: Atlas proposal [and 1 more messages]

I wrote: > you like, checksums) of files more easily. If there were a standard > file registration scheme for files which were in the .deb's filesystem > archive, [...] I meant "weren't" Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@list

Re: dash Debian package - RC bugs

Gerrit Pape writes ("Re: dash Debian package - RC bugs"): > I can't help, I don't understand. I yesterday followed up to a mail > that was additionally addressed to the > mailing list and got an automatic reply telling me that the mail cannot > be delivered because I'm not subscribed. Not a boun

Re: Backports service becoming official

Alexander Reichle-Schmehl writes ("Backports service becoming official"): > Because of limitations in the Debian Bug Tracking System, any bugs > relevant to backported packages still have to be reported to the > debian-backports [3] list, which have now also been moved to > lists.debian.org [4]. W

Re: Bug#560317: dpkg-trigger complains at dpkg-reconfigure time

Raphael Hertzog writes ("Re: Bug#560317: dpkg-trigger complains at dpkg-reconfigure time"): > On Thu, 10 Dec 2009, Joey Hess wrote: > > Does it actually make sense for dpkg-trigger to see those environment > > variables when the postinst is not being run by dpkg? Seems possible that > > any deferr

Re: Bug#560317: dpkg-trigger complains at dpkg-reconfigure time

Raphael Hertzog writes ("Re: Bug#560317: dpkg-trigger complains at dpkg-reconfigure time"): > I agree with not setting DPKG_RUNNING_VERSION, but the others should be > set. [...] Ah, good, then we are in agreement. > > Can you explain why the analysis above is wrong ? > > Did I say it's wrong?

Re: /usr/share/info/dir.gz if install-info is installed

Bernhard R. Link writes ("Re: /usr/share/info/dir.gz if install-info is installed"): > Packages not building in a real environment is a serious problem for our > infrastructure. Having some extremely special build environment for your > software betrays one of the most important principles of free

Re: /usr/share/info/dir.gz if install-info is installed

Sebastian Andrzej Siewior writes ("Re: /usr/share/info/dir.gz if install-info is installed"): > Sounds reasonable. However sometimes package maintainer argueue that the > policy says "clean build environment" and having package X intalled is > no longer clean (thus I have a problem and buildds do

Re: RFC: Rules for distro-friendly packages

Enrico Weigelt writes ("RFC: Rules for distro-friendly packages "): > I've collected several rules that upstreams should follow to make > distro maintainer's life much easier: Thanks for doing this. But I have to say that the tone of your document isn't really appropriate for the social context.

Re: RFC: Rules for distro-friendly packages

Vincent Bernat writes ("Re: RFC: Rules for distro-friendly packages"): > We just don't live in the same world. Keep living in your narrow-minded > world where users are not allowed to compile themselves software and > where all systems are up-to-date. In my real world, I have users that > a

Re: RFC: Rules for distro-friendly packages

Vincent Bernat writes ("Re: RFC: Rules for distro-friendly packages"): > I am not a native English speaker so I fail to see how saying "living in > a narrow-minded world" is rude. I see. I hope I can help by explaining that calling someone narrow-minded is insulting. Telling someone they are "l

Re: RFC: Rules for distro-friendly packages

Enrico Weigelt writes ("Re: RFC: Rules for distro-friendly packages"): > Ian Jackson schrieb: > > We aren't in a position to dictate to upstream. > > No, we aren't. But we (as downstreams) can define rules on what we > consider a good package engineering -

Re: Bug#597571: nodejs: non common executable name

Carl Fürstenberg writes ("Re: Bug#597571: nodejs: non common executable name"): > Policy only states "The maintainers should report this to the > debian-devel mailing list and try to find a consensus about which > program will have to be renamed. If a consensus cannot be reached, > both programs mu

Re: Bug#597571: nodejs: non common executable name

Mehdi Dogguy writes ("Re: Bug#597571: nodejs: non common executable name"): > Wrong. nodejs still provides the binary nodejs and not _node_. So, nodejs can > stay as is. The rename would be necessary if both packages provide the > same binary (same filename), which is not the case here. Sorry, whe

Re: [RFC] Binary packages containing the source

Julien Cristau writes ("Re: [RFC] Binary packages containing the source"): > Why do people hate vowels so much? Bcs f y lv thm t y cn wrt ncmprhnsbl gbbrsh mch mr ffctvly. Ls y sv smll mnt f typng. Ian. (sorry) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject o

Re: [RFC] Binary packages containing the source

Brett Parker writes ("Re: [RFC] Binary packages containing the source"): > On 22 Sep 12:47, Ian Jackson wrote: > > Julien Cristau writes ("Re: [RFC] Binary packages containing the source"): > > > Why do people hate vowels so much? > > > > Bcs f y

Re: [RFC] Binary packages containing the source

Matt Zagrabelny writes ("Re: [RFC] Binary packages containing the source"): > On Wed, Sep 22, 2010 at 12:35 PM, Ian Jackson > wrote: > > No :-).  Perhaps "ls" rather than "Ls" would have been more correct. > > I'm not sure of the correct rule

Re: Bug#597571: nodejs: non common executable name (exclusive alternatives ?)

Jérémy Lal writes ("Re: Bug#597571: nodejs: non common executable name (exclusive alternatives ?)"): > On might object "node" would have a different meaning, depending > on the packages installed ; still, nodejs or x25node (if its maintainer > cares to follow) would be there, and unambiguous. I t

Re: Re: Google Summer of Code 2010 Debian Report

Christian PERRIER writes ("Re: Re: Google Summer of Code 2010 Debian Report"): > Aller suggérer un manque de transparence ou de la négligence est > insultant. I disagree, at least about transparency. I think it is entirely appropriate to comment on a lack of transparency (or to "suggest a lack of

Re: delegation for FTP Masters

Stefano Zacchiroli writes ("delegation for FTP Masters"): > As it's painful to track multiple delegation mails for a single group of > people, I'm (re-)delegating all FTP masters at once. A reference to the > present delegation will shortly be available at >

Re: delegation for FTP Masters

I wrote: > Stefano Zacchiroli writes ("delegation for FTP Masters"): > > As it's painful to track multiple delegation mails for a single group of > > people, I'm (re-)delegating all FTP masters at once. A reference to the > > present delegation will shortly be available at > >

Re: delegation for FTP Masters

Raphael Hertzog writes ("Re: delegation for FTP Masters"): > Your mail did not end up on d-d-a... d-d-a forwards what looks like a > reply (subject =~ /^Re:/ or In-Reply-To:) to debian-devel. Indeed so. Excellent. Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a s

Re: delegation for FTP Masters

Stefano Zacchiroli writes ("Re: delegation for FTP Masters"): > On Wed, Sep 29, 2010 at 12:21:12PM +0100, Ian Jackson wrote: > > That's fine, but can you next time please tell us what the changes are > > between this new delegation and the previous one ? That would

Re: Work-needing packages report for Oct 8, 2010

w...@debian.org writes ("Work-needing packages report for Oct 8, 2010"): > Total number of orphaned packages: 0 (new: 0) > Total number of packages offered up for adoption: 0 (new: 0) > Total number of packages requested help for: 0 (new: 0) Our work is done! Congratulations, everyone :-) Ian.

Re: [RFC] disabled root account / distinct group for users with administrative privileges

Carsten Hey writes ("Re: [RFC] disabled root account / distinct group for users with administrative privileges"): > A group named sudo or sudoroot is somehow linked to sudo as tool used to > gain administrative privileges. No one knows if in future an other tool > will be the de facto standard to

Re: [RFC] disabled root account / distinct group for users with administrative privileges

Guido Günther writes ("Re: [RFC] disabled root account / distinct group for users with administrative privileges"): > Imho we should use diffrent groups for PolicyKit and sudo. d-i would > need to add the user to two groups then but it would allow for polkit > and sudo only configurations: Why sh

Re: [buildd-tools-devel] testers wanted: sbuild and build-dependencies

Roger Leigh writes ("Re: [buildd-tools-devel] testers wanted: sbuild and build-dependencies"): > The existing approach to determinism is not to support alternatives > at all, which is clearly not ideal. While I don't think we should > be encouraging the use of alternative build-deps, this is one

Re: How to add dependencies that exist in another repository

Henrique de Moraes Holschuh writes ("Re: How to add dependencies that exist in another repository"): > On Wed, 10 Nov 2010, Bob Proulx wrote: > > The packages for Debian there add a source.list.d file as you > > describe. (And it really confused me until I figured out what it had > > Which begs

Re: Bug#605009: serious performance regression with ext4

Olaf van der Spek writes ("Re: Bug#605009: serious performance regression with ext4"): > On Fri, Nov 26, 2010 at 10:52 PM, Ted Ts'o wrote: > > I am guessing you are doing (a) today --- am I right? =C2=A0(c) or (d) > > would be best. > > Are there any plans to provide an API for atomic (non-durab

Re: Bug#605009: serious performance regression with ext4

Olaf van der Spek writes ("Re: Bug#605009: serious performance regression with ext4"): > Probably not an issue for dpkg, but in general: > Don't you reset meta-data that way? Yes. If you want to keep the metadata you must copy it. > Require a second file (name), permission to write to it and as

Re: Reportbug not translated (Was: Bug#605892: please state that mails will be publically archived)

Andreas Tille writes ("Re: Reportbug not translated (Was: Bug#605892: please state that mails will be publically archived)"): > If backed up by a proper patch an automatic translation might make sense. > What about some intermediate step like: > > The recipient of your export does most probably

Re: exim-using packages - are you relying on -C or -D options?

Andreas Metzler writes ("exim-using packages - are you relying on -C or -D options?"): > Do you know packages that rely on the -D or -C options? For -C > option, in which directory is the alternate configuration file searched > for? sauce uses the -C option. And chiark's mail system relies on -C

Re: exim-using packages - are you relying on -C or -D options?

Stephen Gran writes ("Re: exim-using packages - are you relying on -C or -D options?"): > This one time, at band camp, Ian Jackson said: > > sauce uses the -C option. And chiark's mail system relies on -C very > > heavily in other ways. Please don't break it.

Re: exim-using packages - are you relying on -C or -D options?

Stephen Gran writes ("Re: exim-using packages - are you relying on -C or -D options?"): > This one time, at band camp, Ian Jackson said: > > Are you saying the current exim4 package in lenny-security already has > > the disability you are discussing ? > > AIUI, no

Re: exim-using packages - are you relying on -C or -D options?

Peter Samuelson writes ("Re: exim-using packages - are you relying on -C or -D options?"): > [Stephen Gran] > > Currently exim will accept -C to any file in any location. This > > makes it trivial for an attacker to escalate from exim to root by > > making any expansion in the config file run cod

Re: exim-using packages - are you relying on -C or -D options?

Stephen Gran writes ("Re: exim-using packages - are you relying on -C or -D options?"): > It doesn't appear to care about symlinks, from a quick read of exim.c. > It seems that so long as the directory name for the file passed to it > matches the configured directory name, it's happy. I would tes

Re: exim-using packages - are you relying on -C or -D options?

Andreas Metzler writes ("Re: exim-using packages - are you relying on -C or -D options?"): > The current status (GIT head) simply adds a file which contains a *list* > of trusted configuration files instead of a prefix. That's good enough for me. And it should be good enough for anyone else beca

Re: Full install/removal/upgrade test results available

Mike Hommey writes ("Re: Full install/removal/upgrade test results available"): > Unfortunately, while some cases were fixed, the original case for which > the pre-depends was added fails again :( > > (starting from xulrunner-1.9.1 already installed, and installing > python-xpcom, case which I for

Re: Full install/removal/upgrade test results available

Mike Hommey writes ("Re: Full install/removal/upgrade test results available"): > On Mon, Dec 27, 2010 at 11:59:16PM +, Ian Jackson wrote: > > So the problem is that python-xpcom does not work when it has been > > previously installed, and then during an upgrade the

Re: Safe file update library ready (sort of)

Shachar Shemesh writes ("Safe file update library ready (sort of)"): > This is not a formal release just yet (plus one function is still > missing an implementation, trivial though it might be). It's just that > the list obviously has a few people knowledgeable on the subject who can > give my c

Re: Safe file update library ready (sort of)

Shachar Shemesh writes ("Re: Safe file update library ready (sort of)"): > I'm sorry, it might be me, but I fail to see the overlap between the > functionalities of safewrite vs. userv. The premises for safewrite is > that a program wants to make sure data integrity is maintained when > writing

Re: Source code

Olaf van der Spek writes ("Re: Source code"): > Renaming open files works, so that should no longer be a problem. They have to be able to be deleted. But this is just the start of your woes. I advise against the attempt. Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org

Re: Safe File Update (atomic)

Ted Ts'o writes ("Re: Safe File Update (atomic)"): > Then I invite you to implement it, and start discovering all of the > corner cases for yourself. :-) As I predicted, you're not going to > believe me when I tell you it's too hard. How about you reimplement all of Unix userland, first, so that

Directories named after packages

Many of the bits of the policy manual, and informal practice, suggest naming directories after your package. I just wanted to make a point that perhaps hasn't been entirely clear: when we say that you should name the directory after your package, you should think carefully about what aspect of and

Re: Directories named after packages

Russ Allbery writes ("Re: Directories named after packages"): > Ian Jackson writes: > > > For example, there has been a recent trend for FOO's documentation > > package FOO-doc to contain /usr/share/doc/FOO-doc/html/index.html (or > > whatever). I think

Re: Forwarding bugs upstream

John Goerzen writes ("Re: Forwarding bugs upstream"): > I'm going to have a slightly different viewpoint on this. I agree with John, basically. > I'm adding zero value here. Zero. [...] Some people have replied suggesting scenarios where the Debian maintainer is adding something. That's fine

Re: Forwarding bugs upstream

brian m. carlson writes ("Re: Forwarding bugs upstream"): > On Tue, Jan 11, 2011 at 09:15:41PM -0600, John Goerzen wrote: > > I think it is perfectly fine for a user to submit a bug report to > > the Debian BTS first. They may not always be equipped to know what > > is a Debian and what is an upst

Re: Forwarding bugs upstream

Olaf van der Spek writes ("Re: Forwarding bugs upstream"): > On Thu, Jan 13, 2011 at 12:12 AM, Sune Vuorela wrote: > >> Will this mean that the problem will somehow disappear from > >> Debian? Because if it's a problem detected within Debian it's my > >> feeling that it will have to be tracked wi

Re: Forwarding bugs upstream

Felipe Sateler writes ("Re: Forwarding bugs upstream"): > On Wed, 12 Jan 2011 16:56:56 +, Ian Jackson wrote: > > I think it is always reasonable for the maintainer to forward the bug > > upstream. > > > > But what I think is bad is _demanding_ or _requiri

Re: Forwarding bugs upstream

Olaf van der Spek writes ("Re: Forwarding bugs upstream"): > Maybe some tools (PTS) should warn about bugs that are older than X > days and are still unclassified? That's just a way to make more noise. They show up in the BTS searches already. Ian. -- To UNSUBSCRIBE, email to debian-devel-req

Re: Forwarding bugs upstream

Bernhard R. Link writes ("Re: Forwarding bugs upstream"): > The maintainer should of course assess where their work is best invested > and act accordingly. > > But a package where bug reports to Debian are not properly handled or > users are required[1] to report them elsewhere is definitely not f

Re: Forwarding bugs upstream

Ben Finney writes ("Re: Forwarding bugs upstream"): > Ian Jackson writes: > > But if a maintainer tells me "please go and talk to them yourself" or > > even "please stop filing these kind of upstream bugs in Debian - you > > know how to do it you

Re: Forwarding bugs upstream

Don Armstrong writes ("Re: Forwarding bugs upstream"): > I personally would love to see patches to the BTS to enable forwarding > these kinds of bug reports to upstreams more easily and integrate > everything tightly with the BTS. Unfortunately, I am perpetually short > of time to implement them my

Re: Forwarding bugs upstream

Olaf van der Spek writes ("Re: Forwarding bugs upstream"): > The point is focus on solving bugs shouldn't be limited to BSPs and > the end of the release cycle. No, Stefano's point was that if you want something done, you should go and do it rather than whining here that it isn't being done. Ian

Re: Forwarding bugs upstream

Ansgar Burchardt writes ("Re: Forwarding bugs upstream"): > Ubuntu has a team (Bug Squad[1]) that tries to triage incoming bug > reports, including forwarding them upstream when applicable. > > I don't know how successful this is, but if it has success, then maybe > we could try to recruit volunte

Re: Can insserv made better?

At the risk of contributing to what is already often an ill-tempered and unconstructive thread: Roger Leigh writes ("Re: Can insserv made better?"): > You're saying that an unwieldy ad-hoc fixed list of numbers and names > is superior to detailed dependency information? This is patently > untrue.

Re: Why is help so hard to find?

Don Armstrong writes ("Re: Why is help so hard to find?"): > A possible hack would be to have insserv ignore any initscripts which > are conffiles which when run without options exit with zero status. It could probably safely invoke them with: /etc/init.d/obsolete --fail-please > But this proba

Re: Can insserv made better?

Gunnar Wolf writes ("Re: Can insserv made better?"): > As it was already pointed out to you, such occurences were due to > incomplete dependencies declared in the initscripts - And as such, > they were bugs in the respective packages. The right way to fix them > is to provide the needed dependency

Re: security updates introducing breakage

Stefan Fritsch writes ("Re: security updates introducing breakage"): > Ack. There is no automatic way the security team is notified of such bugs. > Please CC us in such cases. Would it be worth defining a [user]tag of some kind that would allow this kind of thing to be dealt automatically ? An a

Re: security updates introducing breakage

Stefan Fritsch writes ("Re: security updates introducing breakage"): > On Thu, 20 Jan 2011, Ian Jackson wrote: > > An alternative would be to look for bugs which are "fixed" in the > > previous version but "found" in the update, and ask submitters of

Re: packages with hook interfaces and no documented hook policy

Olaf van der Spek writes ("Re: packages with hook interfaces and no documented hook policy"): > On Fri, Jan 21, 2011 at 1:04 PM, Michael Vogt wrote: > > If you have better suggestions how to solve this problem, I'm happy to > > hear (and implement) them. Until then I would recomment that you run

Re: binNMU for Arch: all packages.

Marco Túlio Gontijo e Silva writes ("Re: binNMU for Arch: all packages."): > Excerpts from Goswin von Brederlow's message of Qua Jan 26 11:28:59 -0200 > 2011: > (...) > > But having some generated html files depend on the exact ghc version > > seems extrem. > > Yes, I don't see the need of adding

Re: package testing, autopkgtest, and all that

Stefano Zacchiroli writes ("package testing, autopkgtest, and all that"): > Regarding this specific point (tests run on packages as if they were > installed), IIRC Ian Jackson worked a bit on the matter, producing some > code (autopkgtest---as mentioned elsewhere in

Re: package testing, autopkgtest, and all that

I wrote: > * A specification which allows a source package to declare that it >contains tests, and how those tests need to be run. This >specification was discussed extensively on debian-devel at the >time and a copy is in the autopkgtest package, but I'll follow up >this email wi

Re: package testing, autopkgtest, and all that

Iustin Pop writes ("Re: package testing, autopkgtest, and all that"): > As it seems to me, right now this is most useful for individual > maintainers to declare, and run, their own tests to ensure the built > packages are fine. A good start, I'd say. Yes, you can certainly use it that way. > I th

Re: package testing, autopkgtest, and all that

Stefano Zacchiroli writes ("Re: package testing, autopkgtest, and all that"): > I find "INSTALLED version of the program" to be ambiguous. It might > refer to installed in the sense of 'debian/rules install' (or, to be > more precise, 'debian/rules binary', given that 'install' is not > dictated by

Re: package testing, autopkgtest, and all that

Stefano Zacchiroli writes ("Re: package testing, autopkgtest, and all that"): > > I confess that this seems to be exactly one of those cases where the > DEP process (should) shine. By putting the specification in a more > visible place than (only) in an archive package we can give it more >

Re: package testing, autopkgtest, and all that

Lucas Nussbaum writes ("Re: package testing, autopkgtest, and all that"): > If there's a packaged tool to run the test suite on a given package, > then it's quite easy to integrate it into my infrastructure. But I > clearly do not have the time to get autopkgtest's code back in shape > first. Yes,

Re: Upstream "stable" branches and Debian freeze

Thijs Kinkhorst writes ("Re: Upstream "stable" branches and Debian freeze"): > In the past such things have not been allowed with the argumentation that > even though stable may contain bugs, users rely on the behaviour that > stable has. They may know about a bug but may have worked around it (and

Re: package testing, autopkgtest, and all that

Yaroslav Halchenko writes ("Re: package testing, autopkgtest, and all that"): > First a brief question: > > The source package provides a test metadata file > > debian/tests/control. This is a file containing zero or more > > RFC822-style stanzas, along these lines: > > Do you still have somewhere

Re: package testing, autopkgtest, and all that

Stefano Zacchiroli writes ("Re: package testing, autopkgtest, and all that"): > All that considered, I'd like to know the rationale of this initial > design choice as well. In particular, it would be nice to know if anyone > see disadvantages in having *also* (rather then "instead") support for > r

Re: package testing, autopkgtest, and all that

Michael Hanke writes ("Re: package testing, autopkgtest, and all that"): > On Wed, Feb 02, 2011 at 02:28:14PM +, Ian Jackson wrote: > > As for "also" running tests which are "not part of a source package", > > it is very easy to wrap up some test

Re: package testing, autopkgtest, and all that

Yaroslav Halchenko writes ("Re: package testing, autopkgtest, and all that"): > in the core -- users usually do not deal with source packages; many of > them do not even have deb-src lines for apt. They do not care how > things are built, but if we want them to contribute by testing their > system

Re: package testing, autopkgtest, and all that

Michael Hanke writes ("Re: package testing, autopkgtest, and all that"): > But to get many machines, we need to make it dead-simple to participate > in this type of croud-testing. We can have GUI frontends to let people > do specific tests, or offer "backfill" job configurations for compute > clust

Re: The "node" command in Debian

Jonathan Nieder writes ("The "node" command in Debian"): > (please follow-up to debian-devel only) > If no consensus emerges, policy §10.1 in its Solomon-like wisdom says > _both_ commands must be renamed. I hope we can do better. I will be > happy to file release-critical bugs against both pack

Re: The "node" command in Debian

Henrique de Moraes Holschuh writes ("Re: The "node" command in Debian"): > 1. they can declare a conflict with each other, so that the packaging >system will never let both get installed in the same system. No, this is explicitly forbidden by policy and quite rightly so. Ian. -- To UNSUBSC

Re: The "node" command in Debian

brian m. carlson writes ("Re: The "node" command in Debian"): > The definition of "filename" here is unclear. AX.25's node is in > /usr/sbin (IIRC) and nodejs's is in /usr/bin. This, of course, poses > practical problems for people that have both in their path. This is > usually the case for roo

Re: The "node" command in Debian

Simon McVittie writes ("Re: The "node" command in Debian"): > On Mon, 07 Feb 2011 at 04:46:57 -0600, Jonathan Nieder wrote: > > Problem: scripts may use the 'node' name to refer to either of these > > programs. Which should get the name? You decide, based not on > > popularity or priority but ---

Re: Make Unicode bugs release critical? (was: Re: RFA: all my packages)

Josselin Mouette writes ("Re: Make Unicode bugs release critical? (was: Re: RFA: all my packages)"): > Kicking out software that doesn?t work at all in UTF-8 locales and > requires the user to set a broken locale, OTOH, sounds like a sanitary > emergency. Excellent, I look forward to the removal

Re: OT: Python (was: Make Unicode bugs release critical?)

Jakub Wilk writes ("Re: OT: Python (was: Make Unicode bugs release critical?)"): > * Klaus Ethgen , 2011-02-14, 14:37: > >~> LC_CTYPE=en_GB.utf-8 perl -e 'print "\x{00a3}\n";' > >~> LC_CTYPE=en_GB.utf-8 perl -e 'print "\x{00a3}\n";' | cat > > Let me try... > > $ LC_CTYPE=en_GB.utf-8 perl -e 'prin

Re: OT: Python (was: Make Unicode bugs release critical?)

Klaus Ethgen writes ("Re: OT: Python (was: Make Unicode bugs release critical?)"): > No, it is not. 00a3 is just not a utf-8 character, it is unicode. To get > a correct utf-8 character you need to print \x{c2a3} and then isutf8 is > happy. When LC_CTYPE=en_GB.utf-8, programs which attempt to pri

Re: Default Homedir Permissions

Olaf van der Spek writes ("Default Homedir Permissions"): > Default homedir permissions are 755. World-readable (and listable). > Common (security) sense says that permissions that are not required > should not be granted. For example, accounts mysql and www-data should > not have access to my docu

Re: Default Homedir Permissions

Olaf van der Spek writes ("Re: Default Homedir Permissions"): > chmod 755 ~ is not a hard way to remove the barrier. We are arguing about defaults, so this is not a relevant answer. > What are those assumptions based on? I could ask you the same question. We are arguing in a vacuum. I don't th

Re: Default Homedir Permissions

[Someone] writes ("Re: Default Homedir Permissions"): > [stuff] We are in danger of wasting a lot of time with this discussion. The general pattern is that someone who is unhappy with the state of the world proposes a substantial change. The worry amongst the rest of us is that the change might

Re: Default Homedir Permissions

Austin English writes ("Re: Default Homedir Permissions"): > On Thu, Feb 17, 2011 at 07:14, Ian Jackson > wrote: > > [Someone] writes ("Re: Default Homedir Permissions"): > >> [stuff] > > > > We are in danger of wasting a lot of time with

Re: [Adduser-devel] Default Homedir Permissions

Stephen Gran writes ("Re: [Adduser-devel] Default Homedir Permissions"): > I don't want to prolong this thread, but this seemed useful to answer. Thanks. > I certainly have no intention of changing the default on my own. > My hope is that Debian is used in ways I can't imagine, and I can not > be

Re: re buildd's resolver and package's build deps

Roger Leigh writes ("Re: re buildd's resolver and package's build deps"): > Taking one of php5's dependencies as an example: > > libdb-dev (>= 4.7) | libdb4.8-dev | libdb4.6-dev > > This dependency permits building against no less than *three* different > Berkeley DB versions. Given that these

Re: re buildd's resolver and package's build deps

Roger Leigh writes ("Re: re buildd's resolver and package's build deps"): > I agree that these do serve a useful purpose for these uses, and that > ease of reuse backporting and other types of porting are important. > However, there is no way to know which of those alternatives applies > to which s

Re: Packaging an RGTP server and client

Thomas Thurman writes ("Packaging an RGTP server and client"): > There is a bulletin board system at Cambridge University called GROGGS[1]. > Since 1995 it has used a TCP protocol called RGTP[2], which also finds > limited use at a few other sites. Various pieces of software related to > RGTP exist

Re: Packaging an RGTP server and client

Thomas Thurman writes ("Re: Packaging an RGTP server and client"): > Ian Jackson writes: > > Why not package the GROGGS RGTP server ? > > I'd far rather package the original rgtpd than Spurge. I'm not > aware offhand of where to get the source; could you let

Re: potential MBF: first alternate depends not available in main

Holger Levsen writes ("potential MBF: first alternate depends not available in main"): > piuparts in master-slave mode currently cannot test packages which first > alternate depends is not available in main, ie the secvpn package depends > on "adduser, bc, ssh, ppp, timeout | coreutils (>= 7.5-1

Re: What bug reports are for

Jesús M. Navarro writes ("Re: What bug reports are for"): > Hi, Josselin: > > You seem to forget the very reason bug reports are here. Their point is > > not to offer a service to our users - if you want that, you?ll need paid > > support. Bug reports are here to help improving the distribution. >

Re: enable/disable flags in /etc/default

Drake Wilson writes ("Re: enable/disable flags in /etc/default"): > Quoth Bob Proulx , on 2011-03-02 17:00:19 -0700: > > Having daemons started automatically at installation time is a very > > nice feature of Debian IMNHO. > > Is there any harder data on which behavior various proportions or > seg

Re: Pre-Depends: dpkg (>= 1.15.7.2) for dpkg-maintscript-helper okay?

Raphael Hertzog writes ("Re: Pre-Depends: dpkg (>= 1.15.7.2) for dpkg-maintscript-helper okay?"): > Of course, the pre-depends become mostly irrelevant when the version in > oldstable supports it but that's not the case yet. And it's not unusual for > people to try an upgrade that skips a release.

Re: new scripts and patches for devscripts

Benjamin Drung writes ("new scripts and patches for devscripts"): > 1. ubuntu-dev-tools contains a bunch of scripts. Some of them are useful > only for Ubuntu, but some of them are general usable for packaging. > These scripts are: > > add-patch > check-symbols > cowbuilder-dist > debian-distro-inf

Re: Ruby changes for Wheezy

Lucas Nussbaum writes ("Ruby changes for Wheezy"): > We are planning a rather large set of changes in Ruby packaging for > Debian wheezy, and would appreciate some external feedback on our > proposals. > > Our plans are described on > http://wiki.debian.org/Teams/Ruby/RubyInWheezy > Don't hesitate

Re: new scripts and patches for devscripts

Benjamin Drung writes ("Re: new scripts and patches for devscripts"): > Am Mittwoch, den 09.03.2011, 16:42 +0000 schrieb Ian Jackson: > > > add-patch > > > check-symbols > > > cowbuilder-dist > > > debian-distro-info > > > distro-info &

Re: new scripts and patches for devscripts

Benjamin Drung writes ("Re: new scripts and patches for devscripts"): > Am Mittwoch, den 09.03.2011, 22:28 +0000 schrieb Ian Jackson: > > udt-* for all applicable *, where "udt" stands for "ubuntu-dev-tools". > > Why? These scripts are not ubuntu

Re: Best practice for cleaning autotools-generated files?

Marcin Owsiany writes ("Best practice for cleaning autotools-generated files?"): > The current best practice for dealing with packages using GNU autotools > (as described in /usr/share/doc/autotools-dev/README.Debian.gz) is to > run autoreconf in a prerequisite of a build target, and to remove its

Re: Transitional packages with conffiles

Goswin von Brederlow writes ("Transitional packages with conffiles"): > Looking into the cause we discovered that the problem is that > dhcp3-client is now a transitional package that pulls in > isc-dhcp-client. The new package expects its config files in /etc/dhcp > while the old had /etc/dhcp3/.

Re: Best practice for cleaning autotools-generated files?

Vincent Danjean writes ("Re: Best practice for cleaning autotools-generated files?"): > On 16/03/2011 14:59, Ian Jackson wrote: > > I think this is bad advice. These files should be shipped in the > > source package. > > > > Doing that makes it much easi

<    5   6   7   8   9   10   11   12   13   14   >