Re: Putting default config files in /usr [was; (newbie) Disruptive LIRC package update.]
[ ⏰ 11/11/2015 23:28 ] [ ✎ Jeroen Dekkers ] > Documentation should be put in /usr/share/doc, not in /etc. I always > find it annoying to have to review lots of comment changes in > configuration files during upgrades instead of simply the options that > actually changed. With big config files it often results in running > "grep -v '^#'" to figure out what the actual differences between the > old and new file are... I even remember having to validate some $DocId or something like that lines at the top of config files being the only difference. But alas, I had modified one option in /etc, so I had to go through extra loops to end this stupid "delta" (only cme-enabled packages know the difference between a changed comment and a changed directive). signature.asc Description: OpenPGP digital signature
Re: Putting default config files in /usr [was; (newbie) Disruptive LIRC package update.]
[ ⏰ 11/11/2015 18:14 ] [ ✎ Marc Haber ] > Once and for all we're doing _SOMETHING_ right, let's keep it that > way. I do not agree that we are doing something exactly right. I would like /etc to only contain what I changed (as a sysadmin), and nothing else ; AND I would like to be warned if something I changed conflicts with a change in the default. Currently, /etc is large, much too large (dozens of MB of data, and I changed maybe 1 kB of data in that). It's just that we need something, probably akin to systemd-delta, to automatically see the difference between the version carefully crafted by the Debian packager, and the one carefully crafted by the local sysadmin. We also need something that monitors this diff. Possibly, this can be an enhanced ucf. But saying that the current situation is right, is... wrong. We do something good wrt some feature, but we miss other (and yes, reading 74 MB of data in /etc to know what was set for a machine is wrong, and no, etckeeper helps but fails to be really exploitable). I don't even want to speak about the /etc files that act as cache data and config mixed together (I am looking at you, CUPS). Sincerely, JCD signature.asc Description: OpenPGP digital signature
Re: Bug#777643: general: possibly, some keyboard layouts should use U+22C5 DOT OPERATOR instead of U+00B7 MIDDLE DOT
[ ⏰ 12/02/2015 06:15 ] [ ✎ Nikolaus Rath ] How dare you write ... instead of the proper … :-P I'm curious, how do you type that in conviently? I hope it's not copying and pasting from a template file, and remembering (and/or finding out) the X11 Compose sequence seems cumbersome too. Best, -Nikolaus In most gnome-apps, CTRL+SHIFT+u,2,0,2,6 will give you the … character. Likewise, CTRL+SHIFT+u,2,5,9,B will propulse you back to the ZX81 charset (▛) (you can use pretty much any unicode hexadecimal codepoint). Sincerely, -- JCD signature.asc Description: OpenPGP digital signature
Re: apache2 issues
[ ⏰ 29/07/2014 07:55 ] [ ✎ Wouter Verhelst ] Op dinsdag 29 juli 2014 10:51:45 schreef Brian May: So ideally I only want to depend on libapache2-mod-wsgi if apache2 is installed, but this is not possible. Sure it is. Depends: apache2 | libapache2-mod-wsgi, apache2 | httpd is perfectly legal and will do what you want. You surely meant |httpd | libapache2-mod-wsgi, apache2 | httpd| . signature.asc Description: OpenPGP digital signature
Re: MATE 1.8 has now fully arrived in Debian
[ ⏰ 26/06/2014 12:05 ] [ ✎ Svante Signell ] On Thu, 2014-06-26 at 11:59 +0200, Ansgar Burchardt wrote: On 06/26/2014 11:34, Thorsten Glaser wrote: No, it didn't work. You had to be root for operations as simple as shutting down the computer. Only on Debian. OpenBSD and MirBSD have: -r-sr-x--- 1 root operator 122716 Sep 10 2013 /sbin/shutdown* I never understood why Debian doesn't. Google says the operator group also has (read) access to raw disk devices. What about creating a unique group then, e.g. calling it it shutdown? So that students can do eg ssh mybuddymachine /sbin/shutdown ? (and they need to be able to shutdown their own machine, power is not free). This is simply a long-standing bug in Linux that you got used to (or got used to its workarounds), but as a solution now exists, the status quo is threatened. Sincerely, -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
Re: MATE 1.8 has now fully arrived in Debian
[ ⏰ 26/06/2014 15:34 ] [ ✎ Thorsten Glaser ] Jean-Christophe Dubacq wrote: So that students can do eg ssh mybuddymachine /sbin/shutdown ? (and they need to be able to shutdown their own machine, power is not free). Why do people always think that a proposal will automatically exclude all others? In your student scenario, you do *not* add them to the shutdown group (or you show some trust into them). In your scenario, you use all those *kit (or their successors) packages. You are what those GNOME/systemd people target their new things at. But neither you nor Svante/me are the *only* use cases. Rather, both coexist. Just as I do not want to tell you to add all your students to the shitdown group, which would be inappropriate, I do not want to be told to use systemd, just to shut down a box. Use the right tool for the job. However, in your scenario, somebody will bug base-files asking that the shutdown group be added to the base groups of everybody. I do not want that. My ideal setup is that nobody has any groups but his own. I would like audio and video groups removed for everybody. This is not needed with the correct framework. I agree that this model may work for special needs (fuse, maybe?). So I say, if you want to use this kind of backward setup, install systemd-equivs, setup whatever you need, modifying pam groups and everything, like I used to setup the IRQ number for my sound card twenty years ago, and be done with it. Sincerely, -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
Re: Dealing with emacs21 (and related) bugs [was: Re: ignoring bugs with no maintainer]
On 15/05/2014 17:06, Russ Allbery wrote: Andrei POPESCU andreimpope...@gmail.com writes: For this concrete case, might I suggest following course of action: 1. ping all submitters of emacs21 (and related) bugs to test against recent emacs (at a minimum emacs23 from wheezy) and deal with the bug as needed 2. if no response within a reasonable amount of time (3 months?) mass-close them According to my script this applies to 162 bugs, of which some are in the 5 (five) digit range and only 1 (one) bug number is higher than 50. List attached. If everyone reading this who uses Emacs (probably a lot of people!) takes a moment to do a bit of triage on the list you posted (thank you!), we could make most of this go away, actually. I started doing that since I was curious how easy it would be and was able to resolve five or six bugs as previously fixed in just a few minutes. I'll do a bit more of that this morning before I have to go do other work. Completely at random, I tested this one: • #128748 [w| | ] [emacs21] emacs21: M-x word-count (from xemacs) is missing? It happens that this one is solved in emacs24, not in emacs23. What should be done: reassign to emacs23 (which obviously will never fix it), or just close it? Sincerely, -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
Re: Ghostscript licensing changed to AGPL
On 07/05/2014 18:59, Bas Wijnen wrote: * texlive-bin (texlive-binaries) Actually with this one is worst, since the LPPL is not compatible with the GPL, lets not even talk about GPLv3 or AGPLv3 :-/ If it's incompatible with the GPL and the way they distributed it was acceptable, then I can't see why anything would have changed now. texlive-bin uses the software (gs), As you, yourself, said, the difference between the AGPL and the GPL is that the AGPL protects the user, not only the people that download the software. This means that by some interpretation (Ian Jackson said so, for example), the AGPL will contaminate texlive, whereas the GPL did not. Do you see what changed there? Sincerely, -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
Re: Point 1 of Social Contract
On 04/05/2014 13:59, Solal wrote: I think we shouldn't support proprietary software creaters, and we should warn proprietary software users about proprietary software unethicality (this does not mean that we will not help users proprietary software but just that we warn of dangers. howewer, we will not help proprietary software creaters). [[[ To any NSA and FBI agents reading my email: please consider]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] This is your idea. However, as shown by [GR2004-2], this is not the opinion of the project. [GR2004-2]: http://www.debian.org/vote/2004/vote_002 Sincerely, -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
Re: Point 1 of Social Contract
On 04/05/2014 14:24, Solal wrote: [GR2004-2] have nothing to do with it. My proprosition is just warn about proprietary software dangers, but users would still install non-free software from repositories, get help from developers, etc. But they are warned. Le 04/05/2014 14:20, Jean-Christophe Dubacq a écrit : On 04/05/2014 13:59, Solal wrote: I think we shouldn't support proprietary software creaters, and we should warn proprietary software users about proprietary software unethicality (this does not mean that we will not help users proprietary software but just that we warn of dangers. howewer, we will not help proprietary software creaters). [[[ To any NSA and FBI agents reading my email: please consider]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] This is your idea. However, as shown by [GR2004-2], this is not the opinion of the project. [GR2004-2]: http://www.debian.org/vote/2004/vote_002 Please do not top-post if possible. I'd rather not annoy our users more than the current warning about enabling non-free at install time. However, this warning may be rewritten if the project feels it is not informative enough. However, your proposition also has the sentence we shouldn't support proprietary software creaters. This is subject to many interpretations. The first interpretation that comes to my mind is in contradiction with point 5 of the Debian social contract (for example in Thus, although non-free works are not a part of Debian, we support their use and provide infrastructure for non-free packages). As for other interpretations, the project generally does not distinguish between uses of the software, be it for creating free software, curing cancer, being evil, or worse: creating non-free software. Not supporting proprietary software creaters would probably, in some of these interpretations, require considering not allowing Debian to be used for non-free software, which would bar us from using almost all currently DFSG-free software. Is that what you meant by we shouldn't support proprietary software creaters? Because providing them our wonderful distribution is supporting them. Sincerely, -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
Re: Debian default desktop environment
On 28/08/2014 15:39, Kevin Chadwick wrote: I am talking about focus follows mouse but raise only on clicking say the border or bar, you can still enter text into any layered windows that have focus. So you can quickly switch for entry to or from web pages on one screen or read a web page in the background. Reference 4 open windows at once, use the scroll upon focus etc.. Basically the closest thing to a panelling window manager like scrotwm (which I could learn) without needing to learn the commands (works for my users too and I should test what I provide) and allowing overlapping for redundant web edges, saves time re-sizing etc.. And this is a so tiny detail that it does not matter for what should be the default desktop environment. No matter how configurable is your thing, what matters is how usable is it out of the box. For the rest, apt-get or any other package management interface is your friend. Sincerely, -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
Re: pulseaudio related problems....
Le 2014-02-21 09:57, John Paul Adrian Glaubitz a écrit : On 02/21/2014 09:29 AM, Mario Lang wrote: I am sorry, both are not an option for me, since alsamixer is a ncurses program, and pavucontrol apparently requires $DISPLAY to be set. I guess that explains why the accessibility community has problems with PA. What's wrong with the accessibility mechanisms provided in GNOME (screen reader, magnifier)? (Serious question). I had the impression that accessibility works rather well in GNOME and upstream actually puts efforts into making that happen. Not the same accessibility. And the screen reader will not work if PA does not work. This is quite difficult to debug remotely; if the user cannot describe the output of commands, then we are doomed. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/d5b89c3d8296a02c6cb1edd96d75b...@oberon.tenebreuse.org
Re: pulseaudio related problems....
On 18/02/2014 10:57, Andrew Shadura wrote: Hello, On 18 February 2014 09:33, Lars Wirzenius l...@liw.fi wrote: On Tue, Feb 18, 2014 at 12:09:11AM +0100, Andrew Shadura wrote: Is it not? It's much more convenient than fighting with a broken audio server which was written by a bunch of not really sane people suffering from some extreme form of a NIH syndrome. I think that attacking people isn't a good way to make one's point, or to foster a constructive discussion. It also makes me, and probably other people, feel uninterested in participating in any discussions on this and other Debian mailing lists. Sorry if that looked like an attack. Probably that was a very poor choice of words. However, my point is still that I can't see how said server improves the situation, my feeling is that it makes it only worse. This is obviously a feeling. Facts would be better. Pulseaudio is not broken, not by large. Many linux users use it without any problems; it is default on almost all distributions, including the largest ones (Debian is the exception here). It may have bugs in specific cases of hardware, but this is not the pulseaudio maintainer/bug list address here. -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
Re: pulseaudio related problems....
On 18/02/2014 12:13, Salvo Tomaselli wrote: In data martedì 18 febbraio 2014 12.03.57, John Paul Adrian Glaubitz ha scritto: That works here just fine, just tested it while listening to music on Youtube. You really must be doing something completely wrong when you are having so much trouble with Pulse Audio. A certain number of users seem to be having troubles with pulseaudio, yet you keep insisting that it's just their fault and that since you can't reproduce (have you even tried?) then the problem doesn't exist. We understood it, for you pulseaudio is completely bug free and all the problems about it are just the users. Do you need to repeat it many more times? Because I can see that for your opinion the number of people claiming to have encountered problems with it is completely irrelevant. Did you at least try to get to the point described in the wiki page: http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/PerfectSetup/ If going step by step in this file does not make your Pulseaudio setup work for you, then it is a bug in pulseaudio (the program or the documentation). If it works, then it's either a bug in pulseaudio (the debian package) or another package (incompatible with pulseaudio; either the debian packaging or the program). Sincerely -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
Re: pulseaudio related problems....
Le 2014-02-17 16:00, Thomas Goirand a écrit : On 02/17/2014 04:02 PM, John Paul Adrian Glaubitz wrote: Well. You can't blame PulseAudio if you have an .asoundrc in your home directory which configures your sound card incorrectly. Oh !!! Now I do remember why my pulseaudio system works. It's because I followed to the letter this howto: http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/PerfectSetup/ Well, having a look at it, it seems it changed quite a bit. But that's what I followed. The question is: why don't we have this by default in Debian? Why would it be up to the user to configure each and every software to use the correct audio stack? IMO, it'd be great if we had consistency. Probably because, Debian is about choice, which makes such wide-ranging changing impossible. Because pulseaudio is not assumed, because udev is not assumed, one can not put a configuration in /etc/asound.conf that says to use pulse. Because that would remove choice, which is important to these non-PA users. Remark that it is important to them especially because we cannot configure this by default, so PA does not work (by default), so does not work, so it is important to be able to go without PA :-/ In my experience, sound not working in PA was due to one program using the alsa driver while the other uses PA, and not saying Alsa to use PA for mixing. Sincerely, -- JC Dubacq -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/65cd884ec39b7ad6593170128d6f7...@oberon.tenebreuse.org
Re: Bug#738839: ITP: mps -- Poor Man's Spotify - Search and stream music
On 13/02/2014 21:25, Tiago Bortoletto Vaz wrote: Hi, On Thu, Feb 13, 2014 at 12:38:55PM -0600, Matt Zagrabelny wrote: On Thu, Feb 13, 2014 at 12:31 PM, Holger Levsen hol...@layer-acht.org wrote: Hi, On Donnerstag, 13. Februar 2014, Jakub Wilk wrote: https://en.wiktionary.org/wiki/poor_man%27s I knew that :) I still don't think it's appropriate nor helpful to describe software with these attributes. (Hints: free software is always free as in gratis, and men, well, men^wmeh.) Packager is using upstream description. From their website, https://github.com/np1/mps Poor Man's Spotify - Search and stream music In English, the phrase doesn't carry a negative connotation. It is a clever way to replace something expensive with something less expensive. It doesn't mean we should use gender-specific words in package descriptions. Also, there're too many non-english people in Debian world, so avoiding such expressions we avoid annoying emails coming from annoying non-english people like me. Regards, That's why there is a project to translate the package descriptions. Poor man's something is correct English, is a fixed expression and should not be changed (even if gender specific). I would be much more worried about trademark dispute with spotify, but as said elsewhere, the description was already changed to remove this reference anyway. Sincerely, -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
Le 12/02/2014 12:10, Salvo Tomaselli a écrit : There is no bug if its not installed. Which is the case for most programs. We could close almost all our bugs on this ground. But the normal case is that uninstalling a software you also stop getting the functionality it provides, with pulseaudio you START getting the functionality it claims to provide by uninstalling it. No. You get a basic functionality, not all the features provided by pulseaudio. And I, for one, could never get out of the box mixing of audio streams when not using pulseaudio. I should have configured this manually with esoteric writings in a non-existent file (not remove a comment from a file). Go figure, listening to music and wanting a sound when I receive a message is not default? Could we move on from this subject? Unless you have a bug number to back your affirmations with technical informations (and a date), this is not useful. Sincerely, -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
Re: Bug#729660: ITP: xemacs21 -- highly customizable text editor
On 16/11/2013 13:30, John Paul Adrian Glaubitz wrote: I have yet to see someone who does. I'm a long-time emacs user and so are many of other developers I work together with and everyone I know of who uses emacs as their primary editor doesn't use X11 support, you just don't need it in most cases. emacs is powerful through it's keyboard shortcuts and you are much more efficient and faster when using them as opposed to navigating through the menus with your mouse. I, for one, use emacs24 in graphical mode. This means I have a menu up there, I preview html pages and graphics inside emacs, and other things like that. I never got to remember the procedure for copy-pasting something from another window (say, a browser) inside emacs -nw. However, I find Xemacs terrible, and inferior to emacs24 on all accounts, and I think xemacs really doesn't need to be in Debian. But who am I to prevent somebody caring about that package? Now, if somebody maintaining a package that I don't care for comes forward and cries for help, so be it. I will not care for it any more. It's a pity there is so much to be duplicated between Xemacs and emacs. Out of curiosity, what is in Xemacs and not in a recent emacs? Sincerely, -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
Re: Bug#727833: ITP: node-bytes -- Byte string parser and formatter - Node.js module
Le 27/10/2013 15:37, Jérémy Lal a écrit : Package: wnpp Severity: wishlist Owner: Jérémy Lal kapo...@melix.org * Package name: node-bytes Version : 0.2.1 Upstream Author : TJ Holowaychuk t...@vision-media.ca * URL : https://github.com/visionmedia/bytes.js * License : Expat Programming Lang: JavaScript Description : Byte string parser and formatter - Node.js module This module parses strings representing an amount of bytes, like 1kb, 2mb, 1gb; and inversely converts positive integers to a readable format representing an amount of bytes. It is useful for parsing or writing log files. . Node.js is an event-based server-side javascript engine. I have looked at the code, and it seems to me that, again, we introduce some code in debian that decide they can name the units any way they like (see http://en.wikipedia.org/wiki/Binary_prefix). They decide, for example, to use k, m and g prefixes for 2^10, 2^20 and 2^30, where usage should point to at least k, M and G and correct usage to Ki, Mi, Gi. They also call bytes 'b' (usage is more 'B'). Of course, this is a library, it may be used to scan other (external) data, I understand this may be part of something bigger, but: 1. This is a bad habit 2. This is bad code 3. Seriously, one package for _18_ lines of code? Sincerely, -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
Re: Please assume good faith (was Re: systemd effectively mandatory now due to GNOME)
Le 25/10/2013 00:39, Brian May a écrit : On 25 October 2013 03:33, Christoph Anton Mitterer cales...@scientia.net mailto:cales...@scientia.net wrote: Well arguably, one shouldn't be too surprised if people get more and more pissed off by GNOME _upstream_ . They continuously try to push their agenda through and force their blessings (most of the time broken, e.g. NM, GNOME Shell) on all users. If you don't like Gnome, nobody is forcing you to use it. There are alternatives. e.g. KDE. I use Awesome myself. Trying to say [GNOME upstream] continuously try to [...] force their blessings on all users. is just wrong. Nobody is forced to use Gnome. I agree with you. As an other datapoint, I use the latest gnome and I am quite happy with it. I also use systemd on my laptop and I am quite happy with it. If I were unhappy, I would have switched to something else. Sincerely, -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
Re: Berkeley DB 6.0 license change to AGPLv3
Le 02/07/2013 16:35, Ondřej Surý a écrit : Thanks Dan for this comprehensive email. I'll take ITP bug for libmdb (#694757) under pkg-db umbrella, as it will affect Berkeley DB, so it makes sense to have it there. People are most welcome to join the team, as I am the only active person in the team. O. I happen to already have a private version of liblmdb packaged. As far as I know, I met the following problems: * The library has no SONAME * I used a git (unreleased) version ; no tarballs of the source code were made * the executables were statically linked. I would be happy to continue the work on this library, albeit as a sponsoree or something (I am not a DD nor a DM). The git tree was not made public, but I can provide all of my work. Sincerly, -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
Re: default MTA
Le 17/06/2013 06:12, Bob Proulx a écrit : David Weinehall wrote: Bjørn Mork wrote: The issue that worries me most about these desktop notification plans is the possibility that some package may decide to unnecessarily drop support for non-desktop systems, adding dependencies on the desktop notification system. I believe we already have had a few examples of such unnecessary dependencies on services which are nice to have, like GNOME depending on NetworkManager for example. I'm having a hard time understanding this particular gripe. If you're running a non-desktop system (by this I take it to mean that you're not using a GUI), why would you worry about GNOME's dependencies anyhow? Here is an example: The emacs24-nox package, a typical headless server package for many of us, depends upon dbus. Feature creep. Putting emacs (which I use as my primary editor) and feature creep in the same sentence is quite funny: You are at a dead end of a dirt road. The road goes to the east. In the distance you can see that it will eventually fork off. The trees here are very tall royal palms, and they are spaced equidistant from each other. There is a shovel here. Please remarke that there is libasound2 in there, too. I can see why notifications (and not desktop notifications) are useful on a headless server. Much less for sound. Sincerly, -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
Re: Survey answers part 1: systemd has too many dependencies, …
Le 12/06/2013 09:49, Marc Haber a écrit : On Sun, 09 Jun 2013 01:04:38 +0200, Michael Stapelberg stapelb...@debian.org wrote: since some people might not read planet debian, here is a link to my first blog post in a series of posts dealing with the results of the Debian systemd survey: http://people.debian.org/~stapelberg/2013/06/09/systemd-bloat.html Thanks for a remarkably unbiased view on the matter. I have to object against one part though: |While it is sad that those machines cannot profit from systemd, switching |to systemd as a default has no downside either: Debian continues to |support sysvinit for quite some time, so these machines will continue |to work even with upcoming Debian versions. I doubt this will happen. Once systemd is the default on Deban/GNU Linux, people will stop testing their init scripts, or they will even stop shipping init scripts, leaving the task of writing or testing init scripts to the non-Linux porters, which will of course decrease their quality since init scripts should be written and tested by people knowing the initted software very intimately. However, the set of machines not able to switch to systemd and needing complicated init scripts is probably quite small. And the init scripts won't suddenly deteriorate. And I suspect that all suspicious cases will receive bugs, and then patches, and that maintainers will integrate these patches. Sincerly, -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
Re: Debian/Wheezy general rant Was: mount point gets (deleted) / unable to unmount
On 06/06/2013 15:31, Florian Lohoff wrote: On Wed, Jun 05, 2013 at 04:19:04PM +0200, Josselin Mouette wrote: That said, we provide GNOME Classic in wheezy for good reasons. Some of Florian’s concerns are clearly among them. I have tried that and the annoyances with the systray, multihead and nautilus manages backdrop are the same. I am not per se against Gnome3 - Some stuff like the launcher from the win keys are perfect for me, although i think its unusable without cairo-dock. But why on earth did very simple thing like multihead management break? Very simple thing ‽ Clearly, you have no idea. Sincerly, -- Jean-Christophe Dubacq -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51b0a8b5.9010...@free.fr
Re: default MTA
Le 31/05/2013 13:10, Marc Haber a écrit : On Fri, 31 May 2013 08:41:56 +0200, Jean-Christophe Dubacq jcduba...@free.fr wrote: Le 30/05/2013 18:29, Marc Haber a écrit : On Thu, 30 May 2013 13:56:02 +0200, Olav Vitters o...@vitters.nl wrote: Seems the solutions are very focussed on the assumption that things cannot be changed. E.g. programs currently send email, so email it has to be forever. It is not a good idea to drop the way that 90 % of programs use to deliver messages. I really hate the idea of having a thing as fragile as dbus on a server just to collect status messages. 73.6% of all statistics are made up. You have a point here. I shold have written the vast majority. The way most programs deliver messages is actually syslog. Which is an epic nightmare to parse automatically if one needs to put messages in relation to each other and is only readable if all messages are shorter than, say, 160 characters. Even firewall log messages are way longer than that already. And yet, I remain convinced that I do redirect many root accounts to my own account, and I have yet to see very important messages coming that way. When I stop receiving useless messages from one machine, *that* means something, namely, that the machine is broken. But anyone seriously keeping an eye on server will install some kind of munin/nagios, and on desktops, disk tools will notify the user when the computer is used. All the rest belongs to syslog. I seem to recall that some init system has a specific additional format to store logs and make them easily searchable, by the way. Sincerly, -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
Re: default MTA
Le 30/05/2013 18:29, Marc Haber a écrit : On Thu, 30 May 2013 13:56:02 +0200, Olav Vitters o...@vitters.nl wrote: Seems the solutions are very focussed on the assumption that things cannot be changed. E.g. programs currently send email, so email it has to be forever. It is not a good idea to drop the way that 90 % of programs use to deliver messages. I really hate the idea of having a thing as fragile as dbus on a server just to collect status messages. 73.6% of all statistics are made up. And in my experience, email tends to be much more fragile than dbus. How many times have I suddenly looked at the queue of a computer that has been mis-configured and that accumulated thousands of email from its system trying to repeatedly warn the user that, well, the email smarthost cannot be contacted? The way most programs deliver messages is actually syslog. The most important of them being the kernel. We've been over it several times. As far as I know, the kernel does not send emails. Exaggerating this way just removes credit from all your mails. I can see you are passionate about this issue (and several others), but this does not help. Most logs I receive on my email account come from cron (also a few from the fetchmail daemon, but I suppose that one can live with sending local emails, due to its nature). And I use a large variety of services. By the way, parts of cron can even be replaced by systemd's services, and at this point this will use whatever system for information transmission systemd uses (I do not use systemd, I am not interested yet in knowing how information is conveyed in systemd to the user or admin; I doubt this is email). A utility to scan syslog and convey important information to the user would be much more useful than configuring all mailers in Debian to read root's local mail by default. I know how to redirect root's mail elsewhere, thank you for not making another mail account to check. Sincerly, -- -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
Re: jessie release goals
Le 16/05/2013 08:43, Vincent Lefevre a écrit : On 2013-05-15 20:27:09 +0200, Jean-Christophe Dubacq wrote: No. Your server comes unconfigured, you do configure it while the other is still working, and then you stop the service on the first, finish syncing the mailboxes, switch the MX record, and then you can go to rest. This is not possible, as I have only one server (which is sufficient for a personal server). If this is a first configuration, then the mail was not working before anyway. So you are not losing thousands of emails. It this is not, then you are already configured, and debconf will not touch your files. Sincerly, -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
Re: jessie release goals
Le 15/05/2013 16:40, Vincent Lefevre a écrit : Here this is more than a mail server being down. It is a domain without a MX; doesn't this mean a direct reject? Actually removing the MX pointer wouldn't be OK, as the client may look at the A record instead, which can't be removed without temporarily affecting other services. So, I'm not sure what should be done (except iptables...). start anything that does not speak SMTP on port 25. while true; do nc -l 25; done should be enough for all your needs. This does not require knowing any iptables stuff. But someone managing a SMTP server at this level of care should know something about networking. Hmm, OK, it seems that postfix works differently from exim (with exim, the daemon is not needed to send a local mail: the sendmail interface does all the job). Then, I think that it would be better to have another debconf question for the Internet Site case (and Internet with smarthost?) in order to let the admin decide whether he wants to listen to all interfaces now or later. The goal would be to benefit from the automatic config from the first debconf questions, but let the admin terminate advanced configuration. No. Your server comes unconfigured, you do configure it while the other is still working, and then you stop the service on the first, finish syncing the mailboxes, switch the MX record, and then you can go to rest. This is no black magic. What you want is being over-cautious and will lead to people not understanding the basics or misanswering a debconf question to have non-functional servers and not being aware of it. I am definitely in the camp of you install a service, you get a working, minimal, safe configuration. Sincerly, -- -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
Re: Bug#705850: ITP: gti -- Animates a car and launches git if you type gti by mistake
Le 21/04/2013 00:25, Felix Crux a écrit : Package: wnpp Severity: wishlist Owner: Felix Crux fel...@felixcrux.com * Package name: gti Version : 1.0.4+1 Upstream Author : Richard Wossal rich...@r-wos.org * URL : http://r-wos.org/hacks/gti * License : Old-Style MIT Programming Lang: C Description : Animates a car and launches git if you type gti by mistake The gti package would provide a fun little launcher application similar to the existing sl package, except aimed at git instead of ls. When the user accidentally types gti instead of git, an ASCII animation of a car driving by appears, and then git is run. Please merge that with sl? -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
Re: Git packaging workflow discussion on planet.d.o
On 04/04/2013 16:00, Andreas Tille wrote: Hi, as a non-regular planet reader I'd like to move the discussion here. I have read the following blog entries [1] http://joeyh.name/blog/entry/upstream_git_repositories/ [2] http://www.eyrie.org/~eagle/journal/2013-04/001.html [3] http://thomas.goirand.fr/blog/?p=94 I personally would like to follow Russ[2] most closely because I consider tarballs definitely as relevant for reasons that are somehow not mentioned in the blog entries: 1. Not all Git repositories enable proper watch files (I know GitHub does but there are others out there that don't) 2. Uscan does not support extraction from VCS repositories (even if this is a shame and should be fixed fow Wheezy+1 either in uscan or a to be developed tool say vcsscan) 3. It is hard to get a MD5sum identical upstream tarball if you do not use pristine-tar and MD5sum identical tarballs are quite an important thing for teams or sponsor/sponsees Yesterday, however, I just had the case of a project with no tarballs (as the library I wanted to package is part of a larger project, it's not released independently). I stumbled (too long) on having a good workflow for this (I ended up tagging myself the upstream tree). Sincerly, -- Jean-Christophe Dubacq -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/515d8a13.2090...@ens-lyon.org
Re: Go (golang) packaging, part 2
On 30/01/2013 22:23, Игорь Пашев wrote: 2013/1/30 Marc Haber mh+debian-de...@zugschlus.de: On Wed, 30 Jan 2013 16:25:12 +, Steve McIntyre st...@einval.com wrote: To be fair, it's similar in reverse. Some Debian developers prefer to _not_ install Ruby *at all*. Given how utterly awful the internals of the language implementation are, I'd happily support dropping Ruby from Debian altogether. Maybe that's just me... Ruby is actually a pretty nice language, and it is needed by the two major Configuration Management tools that are both widely used in business, puppet and chef. Don't forget vim-addon-manager! Don't forget package.el for emacs! -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
Re: GFDL in main
On 01/12/2012 12:10, Jakub Wilk wrote: These packages include documentation licensed under GFDL with Invariant Sections or Cover Texts: bash binutils tar As per GR 2006-001 such works are not suitable for main: http://www.debian.org/vote/2006/vote_001 Any volunteers to file bugs? Yes, exactly what we needed: file a RC bug against essential packages at this point of release :) And before it starts a flame war: it will probably be ignored or fixed in a simple upload, it will not delay the release any way, and thanks for spotting these bugs that are, after all, real bugs in our distribution (even though spotting these one year ago would have made things simpler). Sincerly, -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
Re: mass bug filing about packages manipulating/deleting shipped files
On 17/09/2012 13:10, Bernd Zeimetz wrote: On 09/17/2012 12:49 PM, Philipp Kern wrote: On Mon, Sep 17, 2012 at 11:59:44AM +0200, Bernd Zeimetz wrote: On 09/17/2012 11:56 AM, Andreas Beckmann wrote: Modifying conffiles is forbidden by policy 10.7.3 Well, conffiles are sometimes modified due to the result of asking questions with debconf - at least the md5sum might change, although the content stays the same with debconf priority=high. Are you sure you didn't find such things? If you modify conffiles through debconf config scripts, your package is RC buggy. See also [1]. So we shall drop things like automatic configuration of postfix? It actually even asks the user if the config file should be modified. That is just one example of a lot others that jump into my mind. This just means that the concept of conffile is dying. When trying my hand at some automatic /etc management, I discovered that many files under /etc are not conffiles (and not in dpkg managed-files) because of this rule. And this means that automatic management is hard, because they are generated by scripts, and as such, not easy to store, compare to default, etc. Sincerly, -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
Re: mass bug filing about packages manipulating/deleting shipped files
On 19/09/2012 17:52, Jonas Smedegaard wrote: On 12-09-19 at 05:27pm, Tollef Fog Heen wrote: ]] Jean-Christophe Dubacq And this means that automatic management is hard, because they are generated by scripts, and as such, not easy to store, compare to default, etc. «default» doesn't really make any sense when it's a template that's filled in by debconf/maintainer scripts. In most cases default means what is consistently resolved when installing the package non-interactively. ...but for packages whose postinst scripts actually taking MAC address, moon phase or other out-of-band data into account, you are right. What one wants usually is all manually entered modifications. So, the result of the postinst script in non-interactive mode is exactly what I want (to be able to diff against). Sincerly, -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
Re: Gnome classic mode
On 12/09/2012 15:53, Jerome BENOIT wrote: Claiming that ``What is on CD1 is really anecdotic, since most people use (or should use) the netinst'' really sounds as claim of a newbie who has never installed Debian on a computer. So do not be surprised to get newbie like responses. Otherwise, I can manage anecdotic situations without reading newbie FAQ: thanks ! I am pretty sure the claim is that people installing Debian either use netinst or use a larger support (such as USB key or DVD). Debian requires so many CD that I do not see the practical use of the CD image except in very specific contexts. I do not say it has no uses; I think Josselin is right when saying that it's anecdotic. More computers everyday do not have a CD-reader. In wheezy+2, CD will probably have become really obsolete. This surely could be backed by numbers of downloads, that I do not have. Oh, and this has been discussed this summer already. Sincerly, -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
Re: Bug#687103: ITP: maps -- OpenStreetMap client for the GNOME Desktop
On 10/09/2012 11:26, Jon Dowland wrote: On Sun, Sep 09, 2012 at 10:42:35PM +0200, Alessio Treglia wrote: OK, so let's go on picking 'gnome-osm-maps'. Thank you all folks! No, one package in the archive with a misleading name doesn't mean we should have more! See also: gnuplot, not related to GNU, and no doubt many more. In the case of gnome-* this is not just one package. gnome-split ? gnome-gpg ? gnome-icon-theme-dlg-neu ? gnome-shell-timer ? (and dozens of similarly named packages)... Let's acknowledge that the gnome-* prefix means to be used mostly in the GNOME Desktop environment and not officially endorsed by GNOME. Or something like that. The fact that it uses only gtk may change in the future; I do not know about that, but if upstream thinks it works with gnome and not gtk, even if it works with both at the moment, we should not expect a gtk-only application in the future. Sincerly, -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
Re: Bug#687103: ITP: maps -- OpenStreetMap client for the GNOME Desktop
On 09/09/2012 19:54, Alessio Treglia wrote: On Sun, Sep 9, 2012 at 7:39 PM, David Paleino da...@debian.org wrote: It would be nice if you could use a less generic name. :) Honestly, I've been thinking about that even before you raised your objection :-) Any suggestions? Would 'maps-client' be a good name? gnome-maps ? Sincerly, -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
Re: Bug#687103: ITP: maps -- OpenStreetMap client for the GNOME Desktop
On 09/09/2012 20:26, Alessio Treglia wrote: On Sun, Sep 9, 2012 at 8:09 PM, Jean-Christophe Dubacq jcduba...@free.fr wrote: gnome-maps ? I'd avoid gnome-maps, as upstream != GNOME I am not a specialist, but it looks to me like p gnome-inm-forecast - the Spanish weather forecast applet for the GNOME Desktop whose homepage is http://kutxa.homeunix.org/trac/gnome-inm-forecast is official gnome either. (I picked this one among others; I have no grudge against that package, nor against any package using the gnome- namespace whose upstream is not GNOME). Sincerly, -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
Re: Bug#687103: ITP: maps -- OpenStreetMap client for the GNOME Desktop
On 09/09/2012 20:48, Jean-Christophe Dubacq wrote: I am not a specialist, but it looks to me that p gnome-inm-forecast - the Spanish weather forecast applet for the GNOME Desktop whose homepage is http://kutxa.homeunix.org/trac/gnome-inm-forecast is official gnome either. is *not*, of course. Sorry for the noise, -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
Re: emacs23 and/or emacs24 in Wheezy?
On 26/07/2012 02:39, Vincent Lefevre wrote: On 2012-07-25 21:28:16 +0100, Neil Williams wrote: On Wed, 25 Jul 2012 21:58:20 +0200 Svante Signell svante.sign...@telia.com wrote: Is emacs24 going to be the default package for Wheezy? emacs24 is not in Wheezy yet and has been uploaded to sid since the automatic freeze exception was granted, so it does not have a free pass into Wheezy. Note that emacs24 has a very annoying regression: bug 680933. There is a patch, which works well for me. If emacs24 goes to Wheezy, it should include this patch. emacs24 wouldn't seem to meet any of the criteria for a freeze exception and emacs23 currently doesn't have any RC issues in Wheezy, so there would be no particular reason to do anything with emacs24. emacs23 doesn't have RC issues, but bug 608417 is close to one. This bug is worse that I expected in the first place. I got corrupted files several times without noticing the problem because of this bug. And it is fixed in emacs24. And AucTeX does not work with emacs24. Even following some indications in the bug reports I didn't succeed in having it work, so I uninstalled it. Sincerly, -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
Re: Fixing the mime horror ini Debian
On 13/07/2012 11:13, Norbert Preining wrote: Hi everyone, can we somehome make $subject a target for the *next* release? It is ridiculous that it is in fact completely arbitrary what program is used to open files. Currently in my gnome-shell pdfs are opened with a file-manager, as well as .txt files, as well as anything. That is when using xdg-open or gnome-open of gvfs-open. When I try see, in contrast the funny okular from KDE is started, together with these very useful services of KDE. So maybe someone can explain what are the problems, that these things are simply not fixd. Cannot be so complicated, right? As a comparison point, when I use xdg-open or gnome-open, the Gnome PDF viewer is launched. When I use see, xpdf is launched (okular not installed). Sincerly, -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
Re: Recommends for metapackages
On 11/07/2012 11:12, Andrei POPESCU wrote: On Mi, 11 iul 12, 10:55:16, Jonas Smedegaard wrote: The feature of _allowing a subset of packages to be removed that was _ensured_ to be installed: Impossible without defeating the feature of _ensuring_ those same package are installed. Agreed. However, unless I missed something I haven't seen any arguments for why gnome-core really needs to _ensure_ that network-manager-gnome is installed, other than upgrade issues without any other details. If my memory does not fail me, support from upstream (since network-manager is a core component of Gnome). I may be wrong. Sincerly, -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
Re: Idea: mount /tmp to tmpfs depending on free space and RAM
On 16/06/2012 03:43, Serge wrote: 2012/6/15 Jean-Christophe Dubacq wrote: This is often seen as not a good move to have a user-writable directory on the system partition(s), since this provides for easy DOS DoS like what? /tmp on disk have a 5% safety limit available for system, user can DoS only his own processes, and he can do that anyway. But /tmp on tmpfs is even worse move, since it does not have 5% safety. 1) With 2TB disks, I certainly do not use 5% any more How is that? Isn't it a default value for 2TB disks any more? Or you mean that you manually reduced it to e.g. 1%? Yes. That's the thing I do on most partitions (large ones). 2) Mysql, apache, postfix, all kind of vital systems, do not run as root. And if /tmp is full (and mounted on /), / is full (and so is /var). All kind of mayhem may happen there (I have seen it). You talk about mysql/apache/postfix, so I assume you mean a server. And since it's about users filling /tmp I assume it's a multiuser server (or rather at-least-one-user server). Then putting /tmp on tmpfs is a bad idea there, because doing that will force users to use /var/tmp for large files and will (not can, but will, since /var/tmp is not cleaned) eventually fill /var partition, which is exactly what you need to prevent. Strangely enough, most users do not seem to know about /var/tmp. So, when they put large files, they tend to do that in (IMO better) other places: * $HOME/Desktop * $HOME * $HOME/Downloads * $HOME/theplaceIamworking which is better in terms of system management (except that it is also on NFS, and they suffer terrible pain because of that). Sincerly, -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
Re: Idea: mount /tmp to tmpfs depending on free space and RAM
On 15/06/2012 03:11, Serge wrote: 2012/6/13 Jean-Christophe Dubacq wrote: Why do people repeat that tmpfs is easy to resize? Yes, you need about 3 commands to resize tmpfs, but you need 0 (zero!) commands to resize /tmp on disk, because it's large by default and you don't need to resize it. It's easier to NOT resize /tmp on disk then resize /tmp on tmpfs, isn't it? ;) Obviously, you only think of /tmp as mounted on /. It was about /tmp on disk in general, but as long as default is to have everything on a root partition - it does not matter where exactly it is. For more complex configurations I suggested several Alternatives (e.g. mount-bind to /home/tmp), each of them is usually better than tmpfs, and don't need tmpfs-like resizes. This is often seen as not a good move to have a user-writable directory on the system partition(s), since this provides for easy DOS DoS like what? /tmp on disk have a 5% safety limit available for system, user can DoS only his own processes, and he can do that anyway. But /tmp on tmpfs is even worse move, since it does not have 5% safety. 1) With 2TB disks, I certainly do not use 5% any more 2) Mysql, apache, postfix, all kind of vital systems, do not run as root. And if /tmp is full (and mounted on /), / is full (and so is /var). All kind of mayhem may happen there (I have seen it). (even involuntary; I know of people daily working with 30GB files, and this easily fills the / partition). Is there anything better for them than /tmp on disk? If it's a desktop with single disk I would suggested them a single root partition (with /tmp on it). If it's a server with small root but large /home on RAIDs then I would mount-bind /tmp to /home/tmp... Learning not to use /tmp to place large files. Setting TMPDIR=/home/tmp is a start, indeed. Sincerly, -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
Re: Idea: mount /tmp to tmpfs depending on free space and RAM
On 13/06/2012 03:53, Serge wrote: 2012/6/12 Bjørn Mork wrote: I still think that the easy tmpfs resizing makes it superior for /tmp. Why do people repeat that tmpfs is easy to resize? Yes, you need about 3 commands to resize tmpfs, but you need 0 (zero!) commands to resize /tmp on disk, because it's large by default and you don't need to resize it. It's easier to NOT resize /tmp on disk then resize /tmp on tmpfs, isn't it? ;) Obviously, you only think of /tmp as mounted on /. This is often seen as not a good move to have a user-writable directory on the system partition(s), since this provides for easy DOS (even involuntary; I know of people daily working with 30GB files, and this easily fills the / partition). -- Jean-Christophe Dubacq (beating a dead horse) signature.asc Description: OpenPGP digital signature
Re: Starting services automatically after install
Le 04/06/2012 16:58, Aaron Toponce a écrit : On Sun, Jun 03, 2012 at 02:46:21PM +0800, Chow Loong Jin wrote: Is there even a point in having DHCP listening on localhost? So, why even bother starting it? Thus, the whole point of this thread. Because a dhcp daemon listening only on localhost is rarely useful, so the default configuration is not to listen on localhost only. Sincerly, -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
Re: /tmp on multi-FS set-ups, or: block users from using /tmp?
On 26/05/2012 20:32, Ted Ts'o wrote: On Sat, May 26, 2012 at 09:29:30PM +0700, Ivan Shmakov wrote: … But that makes me recall a solution to both the /tmp and quota issues I've seen somewhere: use ~/tmp/ instead of /tmp. This way, user's temporary files will be subject to exactly the same limits as all the other his or her files. (Still, we may need to identify the software that ignores TMPDIR and tries to write to /tmp unconditionally.) (Snark aside, does tmpfs support quotas yet/will it ever?) These days I'd argue that multi-user is such a corner case that it's not worth optimizing for it as far as defaults are concerned. If you're trying to run a secure multi-user system, you need to be an expert system administrator, keep up with all security patches, and even then, good luck to you. (The reality is that these days, no matter what OS you're talking about, shell == root. And that's probably even true on the most unusably locked down SELinux system.) What I'd do in that situation is to use per-user /tmp directories, where each user would get its own mount namespace, and so each user would have its own /tmp --- either a bind-mounted $(HOME)/tmp to /tmp if you want to enforce quotas that way, or a separate tmpfs for each user --- and then you can specify the size of the per-user tmpfs mounted on each user's version of /tmp. Cheers, Again, I thought that: There is a single base directory relative to which user-specific non-essential (cached) data should be written. This directory is defined by the environment variable $XDG_CACHE_HOME. There is a single base directory relative to which user-specific runtime files and other file objects should be placed. This directory is defined by the environment variable $XDG_RUNTIME_DIR. (http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html) I think these two definitions cover what most users (i.e. *human* users) would use /tmp for. -- Jean-Christophe Dubacq -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fc12517.3060...@free.fr
Re: Moving /tmp to tmpfs makes it useless
Le 25/05/2012 04:00, Steve Langasek a écrit : On Fri, May 25, 2012 at 03:57:28AM +0300, Serge wrote: Every file that exists in /tmp on the system from which I'm writing this exists there not because the application is saving memory but because the application needs to share that file with other applications. That includes a bunch of Kerberos ticket caches, several X server IPC rendezvous points, gnupg-agent and ssh-agent data, and a bunch of UNIX domain sockets for ORBit. I agree, not everybody read FHS, some software may have bugs. According to FHS these should go to /var/run (or /run, if you like). I mean, if you want to fix this, you should move those files to /run, you should not turn /tmp into /run because of them. Absolutely not. /run is a root-only directory, suitable only for system-wide data/sockets. It absolutely must not be used for non-root data. For normal users, shouldn't the applications use ~/.cache/ or whatever the xdg vars point to? -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
Re: RFC: OpenRC as Init System for Debian
On 11/05/2012 08:47, Vincent Bernat wrote: OoO Pendant le journal télévisé du jeudi 10 mai 2012, vers 20:29, Jean-Christophe Dubacq jean-christophe.dub...@ens-lyon.org disait : I do not know about trivially merging changes in the etc-overrides-lib model, but in the current model, I am presented with the dpkg prompt about conffiles for some programs where I added (or changed) only one line (off the top of my head: only the servers list in roundcube, for example), and dpkg does not propose to merge the two files: I am either stuck with keeping my old file, taking the new, or using a shell. All these things are interactive and prevent unattended upgrades without disruption of services. roundcube uses ucf for its main configuration file and therefore, you should have a prompt with possibility to merge. Never got it. But I can quote other (courier, for example). Even /etc/default/locale was updated (only to include a bunch of comments). Is it really necessary ? BTW, for standard workstations, there is less and less need to change things in /etc. My current quota is 1346 files in /etc for about 30 of them with local changes. This is quite a bad signal/noise ratio. If dpkg kept a copy of the original configuration file (to be retrieved at all times), it would be easier to spot local changes. I use etckeeper to do that, but it's a bit tiresome to isolate all local changes (I have to save the diffs somewhere) (and a lost hope if you do install etckeeper late in the workstation life). My git-fu is probably not good enough (I am probably looking for a pristine branch and a rebased local branch used in production). -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
Re: RFC: OpenRC as Init System for Debian
On 11/05/2012 15:29, Thomas Goirand wrote: The setting of unix rights 0440 is indeed very amusing. Yes. Maybe the mean to chmod a-w everything, for some applications will not work with so large modes (sudo, for example). The only nice point about this proposal is that it's going to make happy hard drive factories: they will be able to sell bigger hard drive for no valid good reasons. Come on! Less than 20M, it could trivially be compressed. Seriously, can't someone who broke his configuration wget the package, and use mc to get into the .deb and get the original configuration file??? Not necessarily. 1) Many configuration files are dynamically generated through debconf questions, which root may not be able to rerun to obtain the same result. 2) What if you borked your network configuration? What if the malfunction is due to a complex interaction between several packages (let's say, a FORCESSL option on some service A, and a libssl upgrade breaks A but only if the FORCESSL option is used?) Being able 3) I think etckeeper could do the job without much development. However, it will make the hard drive factories happy (according to you). Overall, all this proposal assumes that users are idiots who love to change things they don't understand, and aren't smart enough to restore. I can't believe that newbies favorite game would be changing randomly the content of /etc/init. And at the same time, I can't believe that experts tweaking upstart jobs wouldn't know how to restore them. I find your attitude assumes users always have the knowledge and the time to investigate everything. This is not the reality. Sincerly, -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
Re: RFC: OpenRC as Init System for Debian
On 11/05/2012 19:03, Thomas Goirand wrote: On 05/12/2012 12:22 AM, Jean-Christophe Dubacq wrote: I find your attitude assumes users always have the knowledge and the time to investigate everything. This is not the reality. Sincerly, Not at all. Anyone without the knowledge will not be able to restore anything anyway. Anyone with the knowledge will know how to get the original file. Yes, it will take more time to do that, but do you think this is the kind of operation you need to do every day? I'd say, once every 5 years maybe? Very rarely, I do a purge then reinstall, but never it happened to me that my system was in such state that I had to recover by hand a configuration file, using the single user boot. Did this happen to you at some point? Anyone else? Yes, several times indeed. Most times when upgrading network packages at the same time. I'm not bashing the idea so much, as it is a harmless one, I just think it is simply a useless feature, and I don't think it's worth investing any human time on this. I think it would be really great to have some program being able to output all manual differences to all /etc files really useful for maintenance. I used to do that, but some rapidly evolving configuration files make it quickly unmaintainable (php.ini comes to mind: I always have to put back the upload_max_filesize to a superior value, and this one-line difference makes something that should be really, really simple (upgrading php, even using stable+security) a pain because one gets manually prompted about the differences, even if they are trivial to merge. -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
Re: RFC: OpenRC as Init System for Debian
On 10/05/2012 19:34, Marco d'Itri wrote: On May 10, Bjørn Mork bj...@mork.no wrote: Agree. Copying a large set of default policies into /etc just because they *can* be overridden is not user friendly. And it does not make the defaults any more configuration either. It just hides important local changes and makes it difficult both for the user and the application itself to distinguish between defaults and configuration overrides. Wrong: since you have to copy the whole file to override it, and files in /lib have no conffiles handling, after an upgrade you will not know what was changed by you and what was changed upstream. Obviously this is not a problem for Red Hat since they do not support upgrades between major releases. There are cases where file in /etc overrides only the directives present in /etc and not the rest. I prefer this way. -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
Re: RFC: OpenRC as Init System for Debian
On 10/05/2012 19:55, Don Armstrong wrote: On Thu, 10 May 2012, Uoti Urpala wrote: You're pretty much just saying that dpkg and helpers like ucf have implemented better functionality than rpm. I don't see how that's relevant to the discussion. The reason why it is relevant is because in the etc-overrides-lib model you are unable to trivially merge local changes with upstream or packaging changes unless you add additional logic in the postinst to handle etc-overrides-lib. Having configuration files in /etc and using ucf or similar enables you to deal with this problem easily. Don Armstrong I do not know about trivially merging changes in the etc-overrides-lib model, but in the current model, I am presented with the dpkg prompt about conffiles for some programs where I added (or changed) only one line (off the top of my head: only the servers list in roundcube, for example), and dpkg does not propose to merge the two files: I am either stuck with keeping my old file, taking the new, or using a shell. All these things are interactive and prevent unattended upgrades without disruption of services. When the merging possibilities of dpkg will have been enhanced, I may reconsider, but currently, I prefer the etc-overrides-lib-only-where-present as superior to the current state. Sincerly, -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
Re: RFC: OpenRC as Init System for Debian
On 10/05/2012 21:12, Don Armstrong wrote: On Thu, 10 May 2012, Jean-Christophe Dubacq wrote: I do not know about trivially merging changes in the etc-overrides-lib model, but in the current model, I am presented with the dpkg prompt about conffiles for some programs where I added (or changed) only one line (off the top of my head: only the servers list in roundcube, for example), and dpkg does not propose to merge the two files: I am either stuck with keeping my old file, taking the new, or using a shell. This is because dpkg's conffile support currently does not do what ucf can do. Presumably this will be addressed eventually, but packages where this will be a significant problem are often already using ucf or similar. All these things are interactive and prevent unattended upgrades without disruption of services. It's basically not possible to have a non-interactive unattended upgrade without the possibility of interruptions of service without outside input as to the decisions that the package manager should be making. ucf and similar gets us closer, but at the end of the day, it's impossible to handle all possible configuration changes. I meant: I test on one server, then replicate the upgrade on other servers. dpkg is lacking in the merge department, and the fact that there is no good possibility to keep one's local changes and only those is simply not helping the user. Sincerly, -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
Re: usefulness of ITPs (Re: mosh ITP not done, just package name taken over)
On 28/03/2012 00:46, Joey Hess wrote: Jon Dowland wrote: That was Joey's hypothetical, iirc, and I don't really agree with his supposition that initial packaging is such quick work that the ITP delay is significant. The typical package is fairly trivial to create. Often the rules file doesn't need modifications anymore, so unless a man page has to be written (which can be put off anyway), the control and copyright file are probably what takes the longest. But, writing an ITP requires looking up most of the control file data, and requires researching the copyright too. For that matter, I'll bet that many developers do some basic compiling and running of the program before sending off the ITP -- why ITP something that you've never used? So the package can easily be half way complete before the ITP is sent. Running reportbug WNPP, filtering the existing reports to find a duplicate, and filling in basic data with cut-n-paste takes two or three minutes. Add the several minutes it takes to get a number back, add the interrupt needed to go check mail and get the bug, avoid getting dragged into some thread on debian-devel while doing it, and you've spent 10 minutes on the ITP if you're lucky, and I would guess, more likely half an hour. The best way to become hyper-efficient is to avoid this kind of overhead, automate everything, and be prepared to fail quickly and iterate. What about a dev. script that would be run in debian/ and would parse debian/control and send the ITP? I can write that! -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
Re: Bug#662080: ITP: hadori -- Hardlinks identical files
Le dimanche 04 mars 2012 à 00:31 +0100, Timo Weingärtner a écrit : Advantages over other hardlinking tools: * predictability: arguments are scanned in order, each first version is kept * much lower CPU and memory consumption * hashing option: speedup on many equal-sized, mostly identical files The initial comparison was with hardlink, which got OOM killed with a hundred backups of my home directory. Last night I compared it to duff and rdfind which would have happily linked files with different st_mtime and st_mode. There is also fdupes that does mostly the same thing. I do not know how it compares to your program. I, for one, would like a program that (starting from some paths on same harddrive), would find all identical files (not considering mtime and mode, this is for backups and I do not care), hardlink them (choosing whatever comes first for mtime and mode), and *store the function [filename (or inode), size, mtime] = hash*, so that files not modified since last run are not hashed again. This would reduce drastically the time of offline deduplication on my backup volumes (and people that modify files without modifying mtimes should be thrown in a large lake of boiling vinegar). Options for considering mtime and modes discriminant are a plus (one day, I'll write this myself, if this is not reinventing something). If anyone happens to see such a beast, please tell me :) -- Jean-Christophe Dubacq jcduba...@free.fr -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1331141143.10626.7.camel@oberon.localnet
Re: Bug#662080: ITP: hadori -- Hardlinks identical files
Le mercredi 07 mars 2012 à 18:46 +0100, martin f krafft a écrit : also sprach Jean-Christophe Dubacq jcduba...@free.fr [2012.03.07.1825 +0100]: I, for one, would like a program that (starting from some paths on same harddrive), would find all identical files (not considering mtime and mode, this is for backups and I do not care), hardlink them (choosing whatever comes first for mtime and mode), and *store the function [filename (or inode), size, mtime] = hash*, so that files not modified since last run are not hashed again. Try backuppc or Git, both of which are designed not to require any deduplication. Thanks for the tip. At least git keeps an history in its normal usage, which I do not want. backuppc is fine for backup, but I also use deduplication for live data (for example, photo storage between different programs). I will explore backuppc for other purposes however. -- Jean-Christophe Dubacq jcduba...@free.fr -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1331145745.11950.3.camel@oberon.localnet
Re: Source package without a binary
On 05/01/2012 18:26, Joachim Breitner wrote: Dear devel, I have an interesting case for a hypothetical „source package without binary packages“: The haskell compiler comes with an extensive test suite. This test suite 1. is distributed separately from the sources, 2. takes a long time to run and 3. partly depends on libraries that do not come with the compiler packages, and which in turn Build-Depend on the compiler. Now point 1 could be solved with dpkg’s multi-tarball-feature, and point 2 is also somewhat minor (but not irrelevant, compiling GHC already takes more than a day on weak architectures, delaying this further is undesireable), but point 3 clearly prevents running the test suite during the build of the GHC package itself. From my point of view, it seems desirable to package the testsuite as a source-package of its own, build-depending on GHC and the additional libraries required, and upload that. Our autobuilding infrastructure would thus run the testsuite on the various architectures, which is very desirable, given that we are talking about a compiler that is not well-tested by upstream on the more exotic architectures. Theoretically, there is no interesting binary package produced from this source package and it seems that the policy does not explicitly require that a source package produces binary packages... but I am certain that this is an assumption buried deep within so many parts of our infrastructure that it is not a good idea to actually try this. So the logical conclusion is to build a binary package from the source that contains nothing (or maybe a log of the test results) and clearly states in its description that there is no point in installing this binary package. Is this something that we want to allow? If not, how else should I proceed? And are there developers who think that having a source package without binary package is a good way to stress-test our infrastructure for corner-case-bugs? :-) Greetings, Joachim You could build a binary package that just contains one file (the test suite log, maybe?). This way, anyone could check that the test suite was passed by the version of ghc being compiled by installing the binary package. -- Jean-Christophe Dubacq -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f05e115.2090...@free.fr
Re: packages with hook interfaces and no documented hook policy
On Mon, Jan 17, 2011 at 08:19:01PM +, Neil Williams wrote: Huh? I use unattended-upgrades on my laptop as a way to keep it updated without having to create the cron job myself. But I don't expect it to force itself to run at times where I want to the laptop to sleep. Use cron-apt instead? unattended-upgrades is more commonly used on servers with a PSU attached. I wouldn't ever use any form of automated upgrades on a laptop - no guarantee the laptop has a connection even if it is on. I'm afraid this comes down to error between chair and keyboard. Most people just wouldn't put those packages on a laptop. sudo LC_ALL=C aptitude why unattended-upgrades i gnome Depends software-center i A software-centerDepends python-aptdaemon (= 0.11+bzr342) i A python-aptdaemon Depends python-software-properties i A python-software-properties Depends unattended-upgrades Yes, this is a laptop answering. I did not install unattented-upgrades myself. NB: this may be a bug in any of the last three packages. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110117223643.ga3...@oberon.tenebreuse.org
Re: packages with hook interfaces and no documented hook policy
On 18/01/2011 07:53, Philipp Kern wrote: | This script can install security upgrades automatically and | unattended. However, it is not enabled by default. Most users | enable it via the Software Sources programm (available in | System/Administration), which has a simple radiobutton in the UI | for enabling unattended upgrades. I do understand that and of course I know it does not work. I was merely suggesting that the conflict with pm-utils was not the answer. -- Jean-Christophe Dubacq -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d35482a.90...@free.fr
Re: Bug#595820: ITP: woof -- A small, simple, stupid webserver to share files
On 07/09/2010 11:17, Salvo Tomaselli wrote: On Tuesday 07 September 2010 10:47:08 Josselin Mouette wrote: Oh, please. If you want to setup such schemes, why would you not want to spend 5 minutes to configure apache or lighttpd instead of spending at least the same time to configure such an obscure piece of software? If all you care about is sharing a few files in the simplest way, there are much better tools to do it, like gnome-user-share. 1 you are assuming to have root permissions (read my previous email) 2 you are assuming to be working on a desktop 3 you are assuming you want to share the same file all the time. But this might not be the case, and change the configuration every time you want to share a different file could annoying. What about using nc ? nc -l /etc/passwd http://localhost:/ = bingo. We will probably not convince you, but there are way too many alternatives to make the packaging effort worth the time. -- Jean-Christophe Dubacq -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c860dbe.4090...@free.fr
Re: Recent changes in dpkg
On 27/05/2010 21:17, Tollef Fog Heen wrote: I wasn't around for the libc5 = libc6 transition, but my understanding is it was larger than 20% of the archive. I would guesstimate the removal of /usr/X11R6 at being around the 20% mark (including binNMUs and all). So while they're uncommon, they're not unheard of. There is also the /usr/doc = /usr/share/doc transition. -- Jean-Christophe Dubacq -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bfec9b1.7080...@free.fr
Re: bindv6only again
On 08/05/2010 20:33, Petter Reinholdtsen wrote: [Niels Thykier] I do not think the maintainers can do anything about sun-java6 other than ask users to modify the netbase config file. To the best of my knowledge there is no source code available for sun-java6. It could add a file in /etc/sysctl.d/ to override the current /etc/sysctl.d/bindv6only.conf setting, and disable net.ipv6.bindv6only = 1 when sun-java6 is installed. :) Happy hacking, What if it is just installed from the tarball? -- Jean-Christophe Dubacq -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4be5e2aa.8090...@free.fr
Re: bindv6only again
On 09/05/2010 01:45, Clint Adams wrote: On Sun, May 09, 2010 at 12:16:10AM +0200, Jean-Christophe Dubacq wrote: What if it is just installed from the tarball? Then that person is still using buggy, non-free software. Which should not prevent this person from running it, especially when all other distributions allow that. -- Jean-Christophe Dubacq -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4be64851.5040...@free.fr
Re: Binary package names for mozilla plugins [Was: Bits from the Mozilla Extension Packaging Team]
On 26/04/2010 09:52, Stefano Zacchiroli wrote: On Sun, Apr 25, 2010 at 11:54:41PM +0200, Benjamin Drung wrote: We didn't discussed browser-plugin-*. Should we make a poll with *-browserplugin and browser-plugin-*? I'd rather say that generally binary packages split words at '-', so if you've a choice among these two the latter is preferable. Cheers. If this is so, then browserplugin-* should content everyone. -- Jean-Christophe Dubacq -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bd5514b.8080...@free.fr
Bug#577087: ITP: spim -- MIPS R2000/R3000 emulator
Package: wnpp Severity: wishlist Owner: Jean-Christophe Dubacq jcduba...@free.fr Owner: Jean-Christophe Dubacq jcduba...@free.fr This package previously existed in Debian/non-free, but was removed due to lack of maintainership and being non-free. Since I use this for teaching, and that the license changed to BSD (except for one documentation file with no source), I am willing to package and maintain it (with a sponsor). A (lintian-clean) preliminary package is available at http://debian.lipn.fr/html/package.spim.html Since this package has been maintained in Ubuntu, I intend to contact the Ubuntu maintainer and merge her changes if they fit (such as a .desktop file, which I deemed at first unnecessary). * Package name: spim Version : 8.0 Upstream Author : James R. Larus la...@cs.wisc.edu * URL : http://www.cs.wisc.edu/~larus/SPIM/ * License : BSD Programming Lang: C Description : MIPS R2000/R3000 emulator Emulates a MIPS R2000/R3000 processor in software. Useful for students who are taught MIPS R2000/R3000 assembly. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100409135223.16930.78463.report...@oberon.localnet
Re: Best practices for development workstations
On Wed, Mar 31, 2010 at 02:44:48PM +0800, Paul Wise wrote: I'm having a bit of trouble visualizing how that works; can you spell out your apt settings? Something like this (not my exact settings): Package: * Pin: release a=stable Pin-Priority: 700 Package: * Pin: release a=testing Pin-Priority: 650 Package: * Pin: release a=unstable Pin-Priority: 600 Package: * Pin: release a=experimental Pin-Priority: 550 The priorities need to be 500 and 1000. == /etc/apt/preferences.d/experimental == Package: * Pin: release a=experimental Pin-Priority: 50 == /etc/apt/preferences.d/testing == Package: * Pin: release a=testing Pin-Priority: 800 == /etc/apt/preferences.d/unstable == Package: * Pin: release a=unstable Pin-Priority: 700 == /etc/apt/preferences.d/stable == Package: * Pin: release a=stable Pin-Priority: 500 (actually I do not have the last one: 500 is the value given to non-specified versions). If you have a default release, it is given 990 without any other intervention. What you should care for is giving priorities between 101 and 989 to non-default release. I use a script called apt-origins to check where my packages come from (for example, I only have unison-2.13.16 and xpdf installed from stable). I prefer to always rate stable lower than testing, because a package that is no more in testing but is in stable is suspicious at best (it was removed from testing at some point). And for the rest of the thread, I use pbuilder chroots. Testing of non-controversial packages goes on either my home box (unstable/testing, arch=amd64) or my lab box (testing/unstable, arch=amd64 kernel+i386 userland) or my laptop (testing/unstable, arch=i386). The more complicated things I have a kvm virtual machine for, except for drivers and such. Sincerly -- Jean-Christophe Dubacq -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100331090029.ga9...@oberon.tenebreuse.org
Re: e2fsprogs not esential anymore?
On 14/03/2010 19:25, Steve Langasek wrote: On Sun, Mar 14, 2010 at 06:04:16PM +, Neil Williams wrote: Personally, I'm not that fussed about Essential anymore - Emdebian just removes the tag from any and every package automatically. No ill effects have been identified so far. Sometimes I wonder if Debian actually needs Essential any more for anything particularly useful or commonplace. Then you clearly don't understand the purpose of Essential. I have seen strange side-effects of Essential, especially when using multiple (pinned) sources (esp. stable+testing+unstable). Example is mktemp and diff which are (according to the tool I use for upgrade) regularly proposed for deinstallation and then proposed for reinstallation. Not that it is a big problem, tough. -- Jean-Christophe Dubacq -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4b9f8f6b.2050...@free.fr
Re: Bug#540215: Introduce dh_checksums
On 09/03/2010 14:24, Bernhard R. Link wrote: It it's that straight forward, please help with the cruft package. Last time I looked (several years ago) it was severly limited by that problem (there not being a way to know which files should be there and which not). I personally think without something in this direction, intrusion detection based on file lists is not really possible. I for one pledge the addition of a dpkg-register (or dpkg --register or anything), bound with dpkg, that would allow maintainers to specify that a file belongs to their package (it could be managed through postinsts, via ucf...) The number of files under /etc that belong to no package (in the sense of dpkg -S) makes it very hard to keep a clean system. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4b964e0b.3060...@free.fr
Re: md5sums files
On 06/03/2010 09:27, Andreas Metzler wrote: Russ Allbery r...@debian.org wrote: Don Armstrong d...@debian.org writes: [...] Is there any reason why we can't just modify dpkg-deb to create DEBIAN/md5sums and DEBIAN/sha512sums and get archive coverage relatively quickly, automatically, as things get rebuilt? Figuring out a better solution for why the files in /var/lib/ispell and /var/lib/aspell are excluded from the md5sums generation because they change after installation is probably needed [...] Hello, I think these hash files are not arch independent. Which is why the packages only ship empty files in the deb and generate the correct binary data in postinst. This way the hash files are listed in dpkg -L, and dpkg takes care of removal instead of relying on maintainerscripts. Anyway, there are many more cases where dpkg -L does not list all files pertaining to a single package. Configuration files managed by postinsts, for example, instances data, etc. It's a shame there is no standard way to declare the (package-)ownership of a file (the cruft(1) format is good enough, but is under-used, to say the least). I have recently taken an interest in obsolete conffiles and it's a real mess to check whether a conffile is really obsolete (can be removed) or is now managed by postinst (or ucf). Some conffiles left behind can have side-effects (usually not important ones). -- Jean-Christophe Dubacq -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4b9223ef.6040...@free.fr
Re: Bug#555743: dpkg-gencontrol: add support for Description:-s in the Source package stanza
On 02/03/2010 14:04, Raphael Hertzog wrote: On Tue, 02 Mar 2010, Stefano Zacchiroli wrote: On Tue, Mar 02, 2010 at 01:03:57PM +0100, Emilio Pozuelo Monfort wrote: The substvars approach sounds good to me. I think I'd use it quite a lot, specially in libraries. That, however, does not solve the problem of how to access a source package description from infrastructure tools such as DDPO, the PTS, etc. The sensible answer is putting this information in the .dsc and thus in the Sources files. But it means that the file would get somewhat bigger and it might meant again supplementary changes in the infrastructutre if people want to see those descriptions translated (but I'm not convinced we need translations on Sources, users of those are mostly developers contrary to Packages). Moreover, if the Sources descriptions are essentially the same as the descriptions of binary packages, the translation effort would not be that great (essentially, splitting the current binary descriptions). I agree that it entails some infrastructure adaptations, and that putting it in .dsc is the way to go. I am no DD, anyway. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4b8d1125.9090...@free.fr
Re: Downgrading a package to get it into upcoming release
On 16/02/2010 17:04, Antonin Kral wrote: Hi all, I am looking for some advise / opinions. I am working with guys from MongoDB project to get stable package in Debian. We have currently version 1.3.1 in unstable, this is considered as development branch which is not very stable. Is there any way how to reasonably push older version (1.2.x which is considered stable), which has not been in Debian before to enable its inclusion in upcoming Debian freeze/stable release? 1) Can the two programs be installed together? If yes, simply build a MongoDB1.2 and a MongoDB1.3. If not, then you should use epochs: upload MongoDB 1:1.2 to unstable, and MongoDB 1:1.3 to experimental. -- Jean-Christophe Dubacq -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4b7ad49b.4070...@free.fr
Re: Is tabular data in binary format acceptable for Debian ?
Charles Plessy a écrit : Dear all, I would like to ask on this list a question I asked to the FTP team last December, and for which I have not received answer yet. Is tabular data in a binary format that can be read, written, modified and exported using free software acceptable for Debian, or shall we contact the upstream author to check if he used an intermediate format (be it text, or binary like .odt or .xls) and require the addition of this file to the source, or shall we provide a text export? I had a question similar to that for a program which comes bounded with a trained neural network. There are files with raw weights. It is possible to retrain on build the program, but it would take a very long time, and the resulting network wouldn't even be the same. What is the source in this case? I do not see what editing means in this context. -- Jean-Christophe Dubacq -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [RFC] DEP-6: Meta-Package debian/control field
Felipe Sateler a écrit : In this particular case, none. But in the general case there are reasons to keep the metapackage installed. For example, I want to try out gnome. So I install the gnome metapackage. I do not want (say) brasero. But I still want everything removable by just saying aptitude remove gnome. Just wait until somebody implements somepackagemanager dummy brasero that would pull brasero, use equivs (or some other internal system) to build a brasero equivalent (but without any files), remove brasero and install it instead, put it in a special list, and do that everytime brasero (real package) is meant to be installed. *That* would be reasonable, and would not interfere with what the packagers do. And you could get somepackagemanager undummy brasero and somepackagemanager dummylist, which would be a must. -- Jean-Christophe Dubacq -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bits from the FTPMaster meeting
Luk Claes a écrit : Charles Plessy wrote: Le Tue, Nov 17, 2009 at 08:27:22AM +0100, Yves-Alexis Perez a écrit : Unless your proposal is just for unstable but doesn't want to change the policy for testing migration? Hi, Testing migration works the way it should: if a package is never built on an architecture, testing migration is not prevented. The problem is that for the sake of universality, some programs are built where nobody wants them. Then when there is a build failure, nobody wants the ‘hot potato’. Upstream does not support non-mainstream arches, the porters are busy porting more central packages, the package maintainer has user requests to answer and knows that nobody will send him kudos for building the package where it is not used. The reason we want everything to be built everywhere if possible is not universality, but quality. If your package FTBFS on some architecture, then that is a bug. A bug that was already there, it just was not noticed yet. In most cases the bug is rather easy to fix, even for non porters as most of the architecture specific FTBFS issues are due to wrong assumptions like 32bit/64bit, little endian/big endian... Is there somewhere a list of how to fix? Something simple so that maintainers may do the right things as soon as a package is FTBFS? -- Jean-Christophe Dubacq -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debconf and PackageKit
Daniel Nicoletti a écrit :
Hey Josselin,
De: Josselin Mouette
This solution is not implemented as I don't know debconf verry well
but there is one problem that I'd like to know if there is a already a way
to deal with this:
when aptcc backend starts installing packages it's status are in a fd
which might be localized is LANG is set, so I clean LANG
and get dpkg to give strings like
removing, unpacking, that can be converted to an enum.
Ugh, that’s an absolutely horrible and broken solution. You should use
the --status-fd dpkg option instead.
hmm ok I'll investigate on how to use that in an apt-get based code..
Why do you use apt-get and not libapt? Especially if you’re working on a
C++ frontend…
Ok now I'm forking and using --status-fd, but i got this localized
pmstatus:k3b:0:Removendo k3b
which i can't parse, actually i'm a bit afraid if it's status are
some kind of standard, maybe i should look at the source.. :P
So what's the best solution anyway?
Clean the child env vars?
Or just use LC_ALL=C (or setenv(LC_ALL,C) or whatever
$ENV{LC_ALL}=C you need), which should be done before launching any
localized non-interactive program from which you expect some information.
--
Jean-Christophe Dubacq
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ignoring the CoC in regards to cc:s (Re: Can we ship sources of a PDF file in the Debian diff?
Ben Finney a écrit : Noah Slater nsla...@tumbolia.org writes: Yes, I know the L command, but thanks for pointing it out! My argument is that I have to remember to use when I am replying to the Debian lists, which as you can see, doesn't happen very often. No, the point of a ‘reply to list’ command is you *don't* have to remember when to use it. Just use it every time you reply to any list, and it will DTRT because it uses the standard fields which are in just about every mailing list anywhere. The times when it doesn't will be the rare ones. Why do these functions not do a normal Reply when not applied to a mail contained within a list? What do they do then? If they also do the right thing for a non-list mail, why are not they bound by default to be the main Reply button? That is a real question, btw, no irony implied. -- JCD -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Popular packages in Ubuntu that is missing in Debian/main
Marco d'Itri a écrit : On Dec 01, Gunnar Wolf [EMAIL PROTECTED] wrote: But anyway, and knowing this is not an Ubuntu list... Does anybody know why on Earth is Acroread popular? Why isn't a PDF regularly I need it to view some large/complex PDF files with reasonable performace. Developers of free PDF viewers feel free to contact me for a copy... I also have files that are too complex to render in short time when zooming. I also found a bug for the rendering of Axial Shadings in all free renderers. The details are here: http://jean-christophe.dubacq.fr/post/Why-do-I-prefer-Acrobat-Reader-to-other-free-PDF-readers I remember giving these details to some developers on irc at the beginning of the xpdf development, but I was too lazy to find the correct bugzilla and enter a minimal example file. I usually use xpdf for daily work. But sometimes, xpdf does not cut the mustard. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Popular packages in Ubuntu that is missing in Debian/main
Marco d'Itri a écrit : On Dec 01, Florian Weimer [EMAIL PROTECTED] wrote: Have you tried evince? For some reason, it used to be faster than the other free viewers (including xpdf itself). Yes. Nowadays it's better indeed: after freezing the UI for 30 seconds while the CPU spins at full speed and reaching a RSS of 150 MB I can scroll over the whole document without other delays, which is almost acceptable for my purpose. Too bad it does not support a zoom level over 400%. That would be because Evince (as does xpdf, and probably others) render the whole file, even though the display window shows only a small part of the file. I often zoom at 800%, sometimes 1600%, on a A0 map. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Non-related 'Recommends' dependencies - bug or not?
Lennart Sorensen a écrit : On Fri, Jun 13, 2008 at 12:15:59AM +0300, Eugene V. Lyubimkin wrote: Thanks, you hinted me to discover it: $ aptitude why banshee synaptic p banshee Recommends brasero p brasero Recommends gnome-mount p gnome-mount Dependslibeel2-2.20 p libeel2-2.20 Recommends synaptic A library recommends synaptic? That just sesems downright stupid. That is not where I would have expected to see that dependancy. I guess it provides a widget that calls synaptic, so someone thought it would make sense to have synaptic installed even though many other widgets in the package might be perfectly useful with out it. I think at most synaptic deserves a suggests in that case. I am absolutely not sure of myself, but I think this is due to the new missing plugins installation procedure that launches synaptic to install new packages if an adequate plugin is missing (but available). I can be wrong, too. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
snapshot.debian.net missing october
I did not see it mentioned elsewhere, but is it normal that october 2007 is missing from snapshot.debian.net ? http://snapshot.debian.net/archive/2007/10/ is empty for me... -- JCD -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
Phillip Susi a écrit : Christof Krüger wrote: Unfortunately, computer designers, technicians etc. are not living in an isolated world (well.. maybe some of them). No one wants to forbid the computer people to use base 2 numbers. They are just asked to write KiB instead of KB if they mean base 2 quantities, because the rest of the world already uses kilo as 1000. Changing the rest of the world makes no sense and having distinct names for distinct thing does no harm. Different disciplines often ascribe different meanings to the same words, so there is no reason why the prefix Kilo can not mean 1024 in the context of computer science, so please stop complaining about that. You should just learn that in this context, that is what it means. Always has and always will. Yup, I totally agree. But why do we call it kilo then, when we actually mean 1024? Someone found it handy dozens of years ago and Because we needed a name, and Kilo is a good one to use. There is no rule that says you can't use the word for a different meaning in a different context. everybody has adapted it. So back then, someone was redefining your pi to 3 because it was close enough and now we should leave it this way? Remember that until computers have been invented (or binary logic), kilo has always meant 1000. And before computers were invented the word mouse always referred to a small hairy rodent. I don't see you complaining that it can also refer to the computer pointing device on your desk. When someone says they caught a mouse or they clicked with their mouse, you can easily infer which one they mean. However, I don't agree that this should hold true in computer science. One possible meaning of KB is 1000 bytes. The other is 1024 bytes. Now take the sentence: Hello John. I've got a file here and want to send it to you. It's 25KB large. Now please extract from the context which meaning is significant here? The problem is that the both possible meanings depict exactly the same: a quantity of bytes. The context clearly indicates the meaning is 1024. When referring to bytes that context uses 1024. Also capitalizing the K is another indicator. There is no ambiguity in that sentence to anyone familiar with the computer science context. It was already explained that even in computer science, kilo does not always mean 1024. 56 kb/s is 56000 b/s, not 57344 b/s. Anyway, I think the request initially was to indicate what kind of units is in use, not to standardize on whether binary or decimal units should be used. What has to be spotted is the places where formatting makes inserting a i in the unit impossible. They should be very few, since localization already pushes pieces of text around. Then, somebody will stand and claim unification is required. But let's deal with it later. And anyway, we should not use byte anymore. Octet is less ambiguous ! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Wed, Jun 13, 2007 at 07:41:27PM +0100, Adam D. Barratt wrote: On Wed, 2007-06-13 at 14:08 -0400, Felipe Sateler wrote: Mike Hommey wrote: On Tue, Jun 12, 2007 at 09:25:13PM +, Evgeni Golov [EMAIL PROTECTED] wrote: On Tue, 12 Jun 2007 15:42:08 -0300 Paulo Marcondes wrote: billion = 10^6 * 10^6 (IIRC, as used in Portugal - no jokes here!) =10^12 :) and Germany, France, former UdSSR, insert your country here Anywhere where milliard is 10^9, basically... Which includes England, according to Merriam-Webster [1]. [...] [1] http://www.m-w.com/mw/table/number.htm The American usage has been becoming more common in England (and the rest of Britain :-) over the past few years, particularly in science and finance related usage. I could be wrong, but I suspect most British people have never even heard of a milliard. It's usually referred to either as a billion or an American billion. http://en.wikipedia.org/wiki/Long_and_short_scales It all depends on space and time. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Mon, Jun 11, 2007 at 05:14:18PM +0200, Bastian Venthur wrote: Magnus Holmgren wrote: I'm in favour! (But are you requesting that aptitude use SI prefixes correctly, or that it use IEC (binary) prefixes? I think we should go for the binary prefixes. Users will be confused when they read 1k and notice that the package has 'just' 1000 bytes. Plus, the 2^n presentation is much more common in the IT world than the 10^n presentation. Not for network bandwidth, and less and less for storage space (commercials do understand what a free 7.5% bonus means, i.e. selling something as 7.5% larger when it is in fact the same that it used to be). I do agree, that especially in the case of filesystem organisation, it makes much more sens to use the binary units. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: discussion with the FSF: GPLv3, GFDL, Nexenta
You're *not* giving up the right not to distribute any source, because you can always refrain from distributing the corresponding binaries and have no obligation to provide source. You're *not* giving up the right to distribute binaries without distributing the corresponding source, because, without a license, you would not have the right to distribute binaries in the first place (with or without source). By accepting the GPL, you instead gain the right to distribute binaries with source, and you simply do *not* gain the right to distribute binaries without source. Similarly, by accepting the CDDL, you are not giving up the right to choose a venue in case you get sued over the software; instead, you are simply gaining the right to use, modify, and redistribute the software under a given set of rules (which simply does not include the right to choose a court in which to settle disagreements). That is what matters, and that is what makes the software free. Even if my argument would be flawed (which I don't think it is, but just in case), that wouldn't even matter. What matters is that DFSG#1 talks about a royalty or other fee--i.e. money--not giving up rights; and any interpretation of the text that says it does talk about giving up rights is incorrect to begin with. I am not a specialist, but in France, private use of a work cannot be denied (as well as private copy, in some measure). Whether this applies only to countries following author rights doctrine instead of copyrights, I let it to someone more knowledgeable in this field. Of course, private means private (not the familial group). -- JCD -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 64-bit transition deadline (Re: Etch in the hands of the Stable Release Managers)
On Tue, Apr 10, 2007 at 12:00:08AM -0700, Sean Perry wrote: I haven't seen much Debian in the last 6 years in the commercial world. RH rules that roost. If people have chosen closed source, then they likely are also paying for an enterprise edition of their free OS too. Linux == Redhat was done in like 2000. Time to worry about other things. I work in a science lab and can tell you that even though we do have commercial software (Matlab, Maple, CPlex and other scientific computation programs, some of which are at least twenty years ahead of any free equivalent), we do use debian and from there also use it elsewhere (our homes, our students' workstations, etc.). Should we become unable to do our daily job with Debian, yes, we would have to switch distributions, which would be a pity since this is a place where computer scientists are made. Commercial software also owns some specific corners of the software world, some of which not Windows-centric (or even Redhat-centric). Do not make it more like it. That being said, these software are more like to do the 64bit transition (computing really requires mem; only last week were we speaking of buying a 128 GiB computer). -- JCD -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 64-bit transition deadline (Re: Etch in the hands of the Stable Release Managers)
On Tue, Apr 10, 2007 at 11:40:27AM +0200, Tshepang Lekhonkhobe wrote: On 4/10/07, Jean-Christophe Dubacq [EMAIL PROTECTED] wrote: On Tue, Apr 10, 2007 at 12:00:08AM -0700, Sean Perry wrote: I haven't seen much Debian in the last 6 years in the commercial world. RH rules that roost. If people have chosen closed source, then they likely are also paying for an enterprise edition of their free OS too. Linux == Redhat was done in like 2000. Time to worry about other things. I work in a science lab and can tell you that even though we do have commercial software (Matlab, Maple, CPlex and other scientific computation programs, some of which are at least twenty years ahead of any free equivalent), we do use debian and from there also use it elsewhere (our homes, our students' workstations, etc.). Should we become unable to do our daily job with Debian, yes, we would have to switch distributions, which would be a pity since this is a place where computer scientists are made. I'm pretty interested in knowing which programs are so advanced as to being 20 years ahead of libre equivalents, and why, if you don't mind. For example, CPlex (a mathematical programming optimizer) is considered much better than any free (even free as beer) program, having no equivalent for e.g. quadratic constraints problems. Maple is also considered much more advanced than Octave especially toolboxes available only in Maple. I may have exaggerated by saying 20 years, but I will not settle for less than 10. And we need those anyway to compare results obtained by one software against the other. The reason for the advance is that the most brilliant people of one small research field unite to build some software company. They recruit the most brilliant students, and can keep this for a long time (not eternally, I believe, but long enough). Maple, Cplex and Matlab all date from before 1990 where free software became (at least in france) commmon place enough so that new projects (see Scilab) would be at least partly open source. -- JCD -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 64-bit transition deadline (Re: Etch in the hands of the Stable Release Managers)
On Tue, Apr 10, 2007 at 04:36:06PM +0100, Luis Matos wrote: Ter, 2007-04-10 às 08:28 -0600, Warren Turkal escreveu: On Tuesday 10 April 2007 07:43, Tshepang Lekhonkhobe wrote: I may have exaggerated by saying 20 years, but I will not settle for less than 10. And we need those anyway to compare results obtained by one software against the other. This is interesting. I often hear people citing pros and cons of FLOSS and commercial stuff, but don't remember anyone stating such extravagant development gaps as 10 years or so. I'd like to hear opinions of others who have also used those Cplex Maple, and whatever else you may have in mind. This however brings to mind libre CAD stuff which truly lags behind. People wouldn't use those programs more than the free equivalents if there weren't some reason. Sometimes that reason is that the proprietary solution has a larger library of extras (libs, etc.) around it that makes it easier to quickly do something without reinventing the wheel. Sometimes the reason is as simple as someone doesn't want to have to learn a new software package or port all there stuff to a new software. These are hard barriers to overcome. Maybe software vendors will look at linux for more power for less hardware, using 64 bit solution. I already said (in this thread) that these software are already linux-friendly, proposing several versions compiled against varying glibc, and probably do exist for 64 bits. If we use these, it is that they work under the current Debian distribution. What I was afraid of, was to forget that even the academic world cannot always abide the pure only-free software rule. The progress of science is more important (in the context of academic research) than the pureness of freedom. I recognize that this is niche software (English is not my native language, I hope this is the right term), but this is important niche software. As said above, academics prefere using free software, but will use what is the most advanced if necessary. For example, gcc is the compiler of choice, but for some cases icc is deemed necessary. My point is: do what Debian must, but do not consider breaking commercial software lightly, and do not think that freedom is all what is required by some well-known target audience such as universities. Tolerance is as great a value (in some contexts). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debhelper and debconf: package and protocol versions
On Wed, Mar 21, 2007 at 02:09:06PM -0700, Steve Langasek wrote:
On Wed, Mar 21, 2007 at 02:13:18PM +0100, Magnus Holmgren wrote:
dh_installdebconf adds a fixed dependency on debconf (= 0.5) | debconf-2.0
to
${misc:Depends} if debconf is actually needed. But judging from the
changelog
of debconf version 1.2.0 is needed if there are any template translations,
and I think dh_installdebconf should be so smart. Not that it matters now,
over four years later, but it makes me wonder: Are there any other versions
where new functionality was added, prompting a versioned dependency on a
newer version? I've found debconf-escape from 1.4.72.
Yes, the debconf 'error' template type was added in a version later than
what shipped in sarge. But then, to use this feature you can't depend on '|
debconf-2.0' either, you have to know exactly which version of cdebconf
implemented the same template type and depend on the 'or' of these two
packages specifically. So at that point, I'm not sure the behavior of
dh_installdebconf vis à vis ${misc:Depends} is relevant.
I had an error triggered today starting from a minimal (only basic unix
machine selected in tasksel) debian etch machine upgraded to a
full-fledged unstable, by tetex-base (saying that the description
format was not understood). Installation of debconf-utils (which
probably pulled something else related to debconf) repaired the thing
(tetex-base could not be removed nor configured, due to the debconf
error). This error may come from the fact that I preseeded the debconf
tree (and I use a non-default debconf configuration).
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: edit patches in dpkg configuration file dialog
On Tue, Mar 06, 2007 at 08:53:00PM +0100, Alexander Schmehl wrote: Although this clutters up /etc they could be saved as *.dpkg-last or so. New packages' conffiles can be saved as *.dpkg-new just like dpkg currently does if one chooses not to install the new file. Before a new version is installed *.dpkg-new would be renamed to *.dpkg-last. ... and they will probably deleted my many admins thinking they are not needed. I don't think you can count on leaving them in /etc and finding them again. And why shouldn't they. If anything, this should belong to /var/lib/dpkg/ -- Jean-Christophe Dubacq -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: localisation in system wide daemons
Le 16 janv. 07 à 20:13, Don Armstrong a écrit : This peoples will ask you for help and send all the logfiles maybe in arabic, hindu or africaan. So you ask them to translate or rerun the program with an appropriate locale. Being able to speak all of the languages that Debian is in isn't a requirement to help anymore than knowing english should be[1] a requirement to administer one's own system. Unless the bug is sporadic, happens only in some other locale... I think log output should be reparsable enough, and interfaces (other than less) can translate the logs when viewing them (let's say gnome- system-log-viewer...). -- JCD
Re: bash features (Re: Question about Depends: bash)
On Wed, Nov 22, 2006 at 10:12:14AM +, Oleg Verych wrote: On 2006-11-21, Ian Jackson wrote: Oleg Verych writes (Re: Question about Depends: bash): o `arrays' bashizm - tmp=$@ ; set -- $ARRAY ; use_array $@ ; set -- $tmp This is another piece of bad advice: this approach is buggy if the arguments might contain whitespace, which is often the case (eg if they're filename arguments). Who said, that it's without bugs, bugs of my usage or bugs in BaSH, dash? NO WARRANTY message on every login (:? (BTW, spaces in filenames are problem of those dual-boots, who have non UTC BIOS time and such.) No. I use spaces in my filenames, and protect them accordingly in scripts. For example, I remember a configuration file of KDE that used to have a space in its names (something with color in it; it escapes my mind right now). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: release critical bug in apache2.2?
Le 5 nov. 06 à 14:49, sean finney a écrit : On Sun, 2006-11-05 at 14:04 +0100, Mike Hommey wrote: The file does not get executed as expected, but the browser wants to download it (which might be a security issue). Then it is likely that you don't have php installed. *or* that php is installed but not the modules isn't loaded into $apache *or* that it's installed and loaded but $apache hasn't been restarted. Or that php is installed as CGI. All the web applications (packaged by Debian) should take care of this case. -- JCD
Re: release critical bug in apache2.2?
On Thu, Nov 02, 2006 at 07:20:12PM +0100, Mike Hommey wrote: On Thu, Nov 02, 2006 at 03:32:39PM +0100, Bastian Venthur [EMAIL PROTECTED] wrote: Hi I've just upgraded #393913 from minor to important. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=393913 Somebody just mailed me that this bug is release critical since it allows to read/download php-scripts (like index.php). Can somebody confirm that this bug is RC or should I just keep it important? DirectoryIndex tells apache which file(s) it may use when the url points to a directory, instead of creating an index of the directory itself, if allowed to. The default value for DirectoryIndex is index.html, which obviously forgets index.php. But that doesn't mean index.php will be readable as source. It only means that the auto index will be displayed if no index.html is present and if allowed to. Auto-indexes are enabled only in /var/www/apache2-default and /usr/share/apache2/icons by default, so it is not likely to leak any unexpected file list. So no, that doesn't grant an RC bug for these reasons. On the other hand, it breaks configurations that used to work... (sites relying on this index.php setting will get 403 errors after upgrade from 2.0) I remember that since the change, I had to make changes to several php applications, because at the same time the default configuration did not include any configuration in the case where php is not installed as module but (e.g.) as CGI. phpmyadmin by default had a snippet in .htaccess that was basically: IfModule mod_cgi.c AddType application/x-httpd-php .php Action application/x-httpd-php /cgi-bin/php /IfModule IfModule mod_cgid.c AddType application/x-httpd-php .php Action application/x-httpd-php /cgi-bin/php /IfModule I had to put something of the same sort in phppgaccess, for example, as well as DirectoryIndex index.php. Since the change for DirectoryIndex happend at the same time, it might be this that the user has seen. So the disappearance of index.php may not be RC; however, the treatement of php as CGI is more likely to be RC. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How do I rebuild alternative symlinks?
On Thu, Oct 26, 2006 at 02:30:09PM -0700, Tyler MacDonald wrote:
I found a way to do it, but I think the solution was less than ideal:
Install Debarnacle from CPAN (isn't even in debian...)
Supposing /etc/alternatives is correct, I have a script to do that:
for i in /var/lib/dpkg/alternatives/*; do
j=$(basename $i)
STATE=0
while read a [ -n $a ]; do
case $STATE in
0) STATE=1
;;
1) STATE=2
mkdir -p $(dirname $a)
if [ -e $a -o -L $a ]; then rm -rf $a; fi
ln -s /etc/alternatives/${j} ${a}
;;
*) STATE=1
j=$a
esac
done $i
done
for i in /var/lib/dpkg/alternatives/*; do
j=$(basename $i)
STATE=0
while read a [ -n $a ]; do
case $STATE in
0) STATE=1
;;
1) STATE=2
b=$(ls -lL $a 21 /dev/null|wc -l)
if [ $b -gt 0 ]; then
rm -f $a; rm -f /etc/alternatives/${j}
fi
;;
*) STATE=1
j=$a
esac
done $i
done
The second loop just removes dangling alternatives. I don't like them.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
On Wed, Oct 25, 2006 at 01:48:02AM -0400, Kevin Mark wrote: So certain bugs can be marked $STABLE-ignore to allow transient rc issues to be ignored for a release and will become no-ops after release. Are you suggesting that each package can have a related list of non-transient bugs that should be marked (with a new tags called ) ignore-this-policy-violation where this can be attached to any package related bug for any length of time until the issues is deemed worthy/necessary to be addressed? If a rule defining a bug ended in the policy document, it certainly is worthy of being addressed. As Manoj expressed several times, if a bug can be ignored for an arbitrary length of time, it certainly should be a note in the developer reference and not a sentence in the policy document. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies, stage 6
On Wed, Oct 25, 2006 at 07:01:22AM +0200, Christian Perrier wrote:
install time are indeed buggy, but I see no indication that the jihad
against circular dependencies is making any such distinctions.
It that's the case, I'm not sure this is the best way to make the
point. I'm actually following this thread and I try to understand
whether the circular dependencies used by console-common (for which I
act as co-maintainer with Alastair McKinstry) are Good or Bad.
During my switch to aptitude instead of debfoster/apt-get, I recently
thought that:
aptitude markauto '~i(!~M)((~R(~i))|(~Rrecommends:(~i!~M)))'
or even
aptitude markauto '~i(!~M)~R(~i)'
should be an idempotent operation. And that once this is done, I could
not mark any more packages as automatic (ok, you have to refine a bit to
hold in account the fact that recommends is as good as depends for
aptitude in default mode ; I did not include the more complicated search
for the sake of simplicity).
Once I have selected console-data to be marked manual and the rest
(console-tools, console-common) to be automatic, I expect it would
see that everything holds. Instead of that, it just finds the circular
dependency loop and says that since they only depend on themselves,
those packages are probably a useless loop.
As a matter of fact, I can live with a few exceptions. But this way
(with a more complicated search in aptitude that accounts for the
Recommends dependency) is a quick way to find circular dependencies.
On my system, there is a dependency loop for
console-* packages, {sys,}klogd packages and
fortune-* packages, at least.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Update: status of inetd
On Mon, Aug 28, 2006 at 12:58:27PM +0200, Marco d'Itri wrote: On Aug 28, Roger Leigh [EMAIL PROTECTED] wrote: 1) Split out update-inetd from netbase into a new inetd package. No, because e.g. xinetd needs a totally different update-inetd program. It's simpler if each inetd package will ship its own update-inetd. If I understood correctly, all the update-inetd scripts have to provide for each and every inetd superserver, or at least fill in a list of calls to update-inetd. Why? - Install openbsd-inetd - Install inetd-using server A - replace openbsd-inetd by xinetd - server A was never registered by xinetd ! Instead, all packages should call a common update-inetd minus the last line. This common part registers the arguments for the service under a common format. Then it calls a inetd-specific script that parses those informations, and puts those in the correct form (files in /etc/xinetd.d/, big file in /etc/inetd.conf,...). In the postinst of every inetd superserver, this specific script is also called. In the prerm of the superserver, the inetd-specific files are deleted. I do not see how one can do otherwise, unless every inetd superserver is capable of migrating data from any other superserver. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Configuration file shadowed?
Le 21 juil. 06 à 18:23, Manoj Srivastava a écrit : While it is true any file can be changed to change behaviour for TeX (like things can be changed in /usr/include/foo.h to change behaviour of a -dev package), any file with a name *.cnf is meant to be a configuration file, and must, in order to meet policy requirements, live under /etc. This is no different from kernel-package having it's configuration file live in /etc/kernel-pkg.conf, even though editing _any_ file in /usr/share/kernel-package would change the behaviour of the program. By your argument, any interpreted language package is exempt from the configuration in /etc rule, since one may edit the script directly in /usr/bin anyway. I do not think it holds. The way I see it, the /usr/share/texmf/mktex.cnf is a default value file, used in the setup of the whole texmf hierarchy; the configuration is /etc/texmf/mktex.cnf, which, per web2c magic, overrides the default values, _if it does exist_. Good default values can be set by copying /usr/share/texmf/mktex.cnf, and return to default values can be done through the removal of /etc/texmf/mktex.cnf. If anything setting default values must be moved under /etc, then most shell scripts should be moved to /etc. What of, let's say, uw- imapd (a well known package), that accepts a /etc/c-client.cf file that does configuration, empty by default (and needing the sentence I accept the risk as the first line to work). Should this file exist on all debian systems for the sake of being configuration files? I think the web2c mechanism is really good, and is the way preferences should be set (source/distribution defaults in /usr, system defaults in /etc, user defaults in ~/texmf or by environment variables). -- JCD
[Meta] Encodage UTF-8 dans la liste debian-french
Les mails encodés en UTF-8 diffusés sur la liste sont incorrectement encodés. Ça se voit en particulier avec certains lecteurs. En effet, un même message est attaché à chaque message: -- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Pensez à rajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] Ce message est rajouté automatiquement par le gestionnaire de mailing- listes de Debian, si je ne m'abuse. Et si j'ai bien compris, il est rajouté automatiquement en iso-8859-1. Si le message lui-même est en UTF-8, cela génère un message où les accents sont codés sur 2 octets sur une partie du texte et où tous devraient être codés ainsi, mais sont codés sur 1 octet sur une autre partie. Dois-je soumettre un bug dans le BTS ? Est-ce que quelqu'un peut simplement enlever les accents du texte standard ? Je peux suggérer un texte: -- Faites une lecture de la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: -- JCD
