Re: Alioth Project Denied
Marcelo E. Magallon, 2004-11-05 01:50:05 +0100 : > On Thu, Nov 04, 2004 at 11:31:09AM -0700, [EMAIL PROTECTED] wrote: > > Your project registration for Alioth has been denied. [...] > > If you decide to use an alioth project to comaintain a package, > > you need to include a "pkg-" prefix in your project name. [...] > a) I couldn't find a policy in the website Used to be there. Should be restored sometime. > b) It's very rude to reply anonymously, someone care to put a name > behind this email? This message was sent automatically by the web interface when I (Roland Mas) denied your project. Gforge currently does not impersonate people, so it sends messages from a clearly invalid address. > c) Can't you just do it yourself? 1. The point of Alioth (of Gforge, really) is to provide a simple and quick way for people to register projects. It took me about two years to educate my co-workers about their own ability to register their own accounts and projects instead of coming to see me with "Can you make an account for me?" requests. I'm surprised my esteemed fellow Debian developers are not more clueful. 2. Yes, I could have done so. It would however have taken time for me to do so. When I have that sort of time, I usually prefer working on the next Gforge and/or the next Alioth. Like, you know, the one where we get rid of the infamous LDAP setup. 3. Judging by the masses of people who were confused, nay, irritated by the fact that their loginnames were not "foo" but "foo-guest", despite the "-guest" being prominently displayed in the "Create an account page", if I started messing around with people's project names, I'd probably get yelled at quite a lot. I try to do my best to live without being yelled at. > But whatever, I'll jump thru the hoops if that's what it takes. That would be so kind. > This project is making a custom out of threating developers like crap. Thank you. I'll try to remember that next time I need to spend like ten hours in a row working on fixing Alioth. It'll give me such a motivation. Maybe I should even make a poster out of that. Roland. -- Roland Mas M-x execute-extended-command
Re: Hot-Babe non-controversial images
Frederik Schueler, 2004-12-04 13:50:08 +0100 : > Hello, > > On Fri, Dec 03, 2004 at 10:52:55PM -0600, Ron Johnson wrote: >> An earlier suggestion to show a lamb in various states of shear, >> and then roasted at 100% was also good. > > As a vegeterian I have to strongly object on this. ;-) I have an eggplant and two zucchinis here, which I intend to cook in tonight or tomorrow. Want me to take pics? Of course, we'd have to rename the package hot-ratatouille, but I assume there are less people shocked by objectification of vegetables than there are for objectification of women. Roland. -- Roland Mas Why did the tachyon cross the road? Because it was on the other side.
Re: Bits (Nybbles?) from the Vancouver release team meeting
Sven Luther, 2005-03-14 10:50:13 +0100 : > I don't see how having the in-devel arches be hosted on alioth > instead on the official debian ftp server would cause a problem. The amd64 archive on Alioth has been (and still is) the major cause of many many problems. In a few words: it eats space, which disrupts all Alioth projects using CVS (for a start). Roland. -- Roland Mas C c ee lm re q j l a l l iè e . -- Signatures à collectionner, série n°1, partie 3/3. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
to me. That, and the "I din't answer *that* question, you can't hold it against me" weaseling-out (I don't like the term, but I can't find one more suited). I hope Debian is not becoming another banana republic. I'm sure you can tell I'm disgruntled by that proposal. I hope my conspiration theory fears are unfounded, but I believe the main "let's drop two-thirds of our arches" problem is a large mistake. In both cases, I'd be glad to be corrected -- with facts, please. As has been noted, this plan doesn't mention what problems it tries to solve, nor what measure solves which problem. Roland. -- Roland Mas 'And what would humans be without love?' RARE, said Death. -- in Sourcery (Terry Pratchett) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Need for launchpad
Stephan Hermann, 2006-01-08 11:30:12 +0100 : > Hehe...well, it's a matter of working behaviour. I never said, that > working from the CLI is not faster or more productive > sometimes. What I'm trying to say is, that this "arrogant elite > thinking" must go away. I don't see why the "poor oppressed non-elite" should have tools they find easy to use and the "arrogant elite" shouldn't. If my not-quite-geek sister wants to use her web browser to translate stuff, I don't see why she should be prevented from doing that, but then if I, as an arrogant bastard, want to use my ~/bin-full of ugly shell, Perl and awk scripts, why should I not be allowed to? > We have to focus on what we all want, that is bring good software to > the world. I'm not a member of this "we all" then. I mainly want to have fun and not feel bad about it afterwards. I found Free Software to be such an occupation. > For that, we have to find a simple and usable solution, that > everyone can work with. Not only the so called elite, or actually > those people who think they are. Correct. But also not only the people who can bear some kind of interfaces such as web interfaces. If such an interface is all I get, then I cease to have fun, and I'm excluded from the process just as much as my sister would be if the only interface were a set of awk scripts. > If we are not thinking about the people, who can't handle the > console, or are not able to fullfill simple tasks with the cli, for > those people we need at least another way. If Debian never followed > this example, well I think there wouldn't be a webinterface for > Debian BTS at all and all the informations of debian on the webpage, > we would find in gopher or txt files which i have to search with > archie. Choice is good, we all agree on that. So why do you want to *restrict* the tools to *just* some web interface? > To use a tool, I don't need a NDA. To use a tool, I often need to hack so it actually corresponds to my needs (or just to fix bugs). That means either a free tool or an NDA. Additionally, hacking a tool locally is easier than getting the central tool administrator to apply a patch that may or may not please everyone. Roland. -- Roland Mas Twenty thousand balls, clubs, and rings. How about yours? European Juggling Convention -- Carvin, France. http://ejc2004.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Need for launchpad
Stephan Hermann, 2006-01-08 17:10:31 +0100 : >> Yes, but nobody has proposed making those non-free services a core >> part of Debian development. Yet Frans proposes we do so with >> Launchpad. > > This doesn't work, but using it as helper tool would help the > project. Launchpad itself is not tight to one distribution. Right, there's no package for a single distribution. Worse: there's not even a non-packaged, install-by-hand tarball available. It's not only non-free, it's also non-available. I'm not sure how it could be of any help. > So, the best way of improving is to use it, and if someone finds a > bug or a glitch or an idea of making the workflow easier and faster, > the best way is to file a bug or kick the developers :) Let's assume the "non-available" problem eventually gets fixed. Debian gets and runs a copy of Launchpad. Now the best way if someone finds a bug is to fix it himself, and then send the patch. That way, the upstream developers can just review and apply, and the user can apply locally before even that. That's my idea of an easy, fast *and efficient* workflow. Unfortunately, if we're still in non-free stuff, we can't use that workflow, we're stuck waiting for someone (whose boss may or may not have the same motivations as you) actually fixes the bug and releases a new version, which you'll have to upgrade to when you find the required time. Good workflows don't have big blockers, they allow the flow to go around small blockers locally. Roland. -- Roland Mas Seems to me, the only sensible thing is for people to know if they kill a whale, they've got a dead whale. -- Adam, in Good Omens (T. Pratchett and N. Gaiman) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gnucash 1.9.1
Thomas Bushnell BSG, 2006-02-28 01:00:08 +0100 : > Users of gnucash who are willing to use this experimental software > are desired. It is not a good idea for every casual user to use it > (or I would have put it in unstable), but testing will help the > process along. Okay. Built it in a pbuilder chroot (it does take quite some time :-), then installed it into same chroot, and started using it in a VNC after copying my roland.xac into the chroot. First impressions (posted here as much to give potential new users a warning of what doesn't exactly work yet as in an attempt to prove that there *can* be some on-topic content on this list despite current rumours): - Data seems to have been correctly imported (phew). - Accounts names seem to have been mangled a bit, especially for non-ASCII characters. They were stored as é for an "é" in 1.8, which now appears as the oh-so-familiar é. I run under an fr_FR.UTF-8 locale in both cases. - Still locale-related: no, the monetary unit in use in fr_FR.UTF-8 shouldn't be USD :-) - And again: I haven't seen anything displayed in French, which makes me wonder if maybe the locale setting isn't taken into account (haha) at all. - I haven't managed to expand the graphs horizontally as much as I'd have liked, apparently I can't have a report wider than it is high. Since the captions are apparently proportional in size to the report itself, the actual graphics are very tightly compressed to the left of the report. - In the Help menu, only the Tips of the Day and the About entries have any effect. The other two seem inoperant (which is a pity, I'd have loved to learn about this new "books" thing). - I tried closing my books, and apparently one transaction wasn't categorised into a book, so it appears all by itself above the book-closing transaction. - After closing the books, I couldn't find a way to access the transactions of the previous years in their account tabs (even read-only), only through a hack (search for transactions by date). Are they really hidden, or was I bitten by the "no help" problem? - I love the new hierarchical display in the quote editor -- the previous everything-in-the-same-list was getting tedious after hundreds of quotes. Otherwise, it seems to work, but I'm not exactly a heavy user. Question though: will the SQL support be enabled at some point? I think that would open up a lot of possibilities (gateways with other apps, for instance). Thanks, visible evolution coming from Gnucash is a relief, I was starting to wonder whether I'd have to switch to something else... :-) Roland. -- Roland Mas You can tune a filesystem, but you can't tuna fish. -- in the tunefs(8) manual page. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: buildd and experimental
Wouter Verhelst, 2006-03-01 21:40:14 +0100 : >> I'm most concerned about i386; will it get built for that? > > Most likely. If not, nobody's keeping you from building manually -- > or from asking someone else to build it. In case it helps: I'm right now uploading a set of i386 packages to http://roland.mas.free.fr/debian/experimental/. Straight from Thomas's source packages, built in an up-to-date pbuilder chroot. Roland. -- Roland Mas [...] ou une dent pourrie [...] -- in Variations sur un thème imposé -- Signatures à collectionner, série n°2, partie 2/3.
Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)
Adeodato Simó, 2006-08-02 21:20:09 +0200 : >> > % bzr push sftp://costa.debian.org/bzr/pkg-xiph/vorbis-tools [...] > Ask in #alioth. Note, however, that TTBOMK still does not offer HTTP > access, so if you want that, better stick to htdocs for a while. > > I hope to be able to bribe buxy to provide HTTP access when he comes > back, though. ;-) I just enabled HTTP access for bzr: $ bzr get http://arch.debian.org/bzr/pkg-xiph/vorbis-tools Branched 22 revision(s). bzr.debian.org doesn't exist, so I chose arch.d.o instead. Roland. -- Roland Mas [...] ou une dent pourrie [...] -- in Variations sur un thème imposé -- Signatures à collectionner, série n°2, partie 2/3.
Re: Bug#381201: ITP: reniced -- renice running processes based on regular expressions
Nikolaus Schulz, 2006-08-08 11:50:08 +0200 : > ... which is something I'd expect to find in ~/bin, but not as the > single functionality of a Debian package. moreutils then? Roland. -- Roland Mas If you're ever confused as to which mode you're in, keep entering the key until vi beeps at you. -- nvi manual page. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gdm/Gnome/KDE and device permissions
Sam Morris, 2006-10-11 13:40:08 +0200 : > I think HAL/PolicyTool/pam_foreground will eventually give us a > (slow?) solution to problems like this, but it's some way off at the > moment. Being able to add/revoke permissions with traditional > security methods (i.e. group membership) requires kernel > modification AFAIK. One could envision usage of POSIX ACLs. Very hackish, but some daemon could add an ACL entry to various files in /dev when a user logs in, or logs out, or time passes, or some device is plugged in, or whatever. No need for special groups. Of course, maintenance would probably be a nightmare, unless there's a way to share ACLs between files that I'm not aware of. Roland. -- Roland Mas Ace of clubs? Let's see that. European Juggling Convention -- Carvin, France. http://ejc2004.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: First draft of review of policy must usage
Luk Claes, 2006-10-25 18:51:26 +0200 : > It was not meant that way at all. I just don't like that people > start to discuss topics that are long overdue near release time... Topics that are long overdue should, by definition, be discussed and worked on *now*, regardless of whether "now" happens to be (presented as) close to release time. Roland. -- Roland Mas LinkedIn profile: http://www.linkedin.com/in/rolandmas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Alioth upgrade -- done
Roberto C. Sanchez, 2006-10-28 16:16:31 -0400 : > Excellent. Thanks for the hard work. This is not a problem, per > se, but rather a question. I saw that the new Alioth server has 8GB > of RAM, but now swap space. I understand that 8GB is quite a bit, > but I was wondering what the rationale was for no swap. I don't think there's any explicit rationale -- at least, nothing beyond "8GB is quite a bit" :-) As a side note: yes, we know SVN isn't reachable through svn://. The SVN server is up, but the relevant port is blocked by the firewall at the hosting facility. The admins have been contacted. In the meantime, use svn+ssh:// if you can. We apologise for the inconvenience. Roland. -- Roland Mas When I eat a biscuit, it stays eaten! -- Arthur Dent, in So Long, and Thanks for All the Fish (Douglas Adams) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New dpkg-buildpackage error
David Jarvie, 2006-03-17 23:30:17 +0100 : [...] > dh_install -pkalarm-upgrade > cp: cannot stat `./debian/tmp/usr/bin/kalarm': No such file or directory > dh_install: command returned error code 256 > make: *** [binary-install/kalarm-upgrade] Error 1 > > True enough, a tmp directory doesn't exist under ./debian. Can > anybody help me as to how I can get this build to work > again. Presumably something has changed recently in > dpkg-buildpackage? It sounds more like a change in debhelper. I seem to remember something recently about a change in the default compatibility level. Roland. -- Roland Mas Such compressed poems / With seventeen syllables / Can't have much meaning... -- in Gödel, Escher, Bach: an Eternal Golden Braid (Douglas Hofstadter)
Re: unstable? nah. :-)
Sebastian Harl, 2006-06-08 21:10:11 +0200 : >> http://www.crackerjack.net/adserton3.png > > On that picture it says the box is up for 378 days. How does that go > with 875 days idle time? Old Linux kernels have their uptime roll over at about 497 days (which is like 2^32 ticks of a hundredth of a second). I've had one box kept at Debian unstable for two rollovers in a row, though it wasn't a production server at all -- its final uptime was like 10 days, after having been up for more than three years. Roland. -- Roland Mas C r ' s d a ue ell r a u i r . -- Signatures à collectionner, série n°1, partie 1/3.
Re: NMUs for Python Policy -- please hold them a little
Loïc Minier, 2006-06-23 16:40:06 +0200 : [...] > Probably the biggest reason why I feel this extra time would be > useful is because the new Python Policy and the tools supporting it > saw non-negligible changes in the last days. All of this only > settled very recently. This explains why maintainers have been > reluctant in moving packages to the new policy immediately. And here I was, thinking a policy was a collection of tried and true best practices turned into official status after they've been in use by most concerned packages for some time. I guess I'm hopelessly out of touch with reality. Roland. -- Roland Mas Just because you're dead doesn't mean they aren't still out to get you. -- Virgil, in Ye Gods! (Tom Holt) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Alioth Tracker: no correspondence to BTS?
Peter Samuelson, 2006-07-09 21:30:11 +0200 : > [Toni Mueller] >> I've just poked around a bit in Alioth for a project I'm working on >> and found a bug report with a bug number that has no resemblance to >> anything in BTS, quite contrary to my initial assumption. > > Yeah, the sourceforge software includes a primitive bug tracker > which, as far as I know, people don't really use on alioth. Some do (the Alioth admins, for a start :-). Oh, and it's Gforge, not Sourceforge (which has ceased to be free for years). >> Imho this would only make sense if integrating these two is hard, >> and if non-Debian projects are hosted on Alioth (I don't know). > > Yeah, I couldn't tell you why that feature is even enabled on > alioth. Because having it available doesn't hurt, and project admins can enable/disable trackers on their project as they see fit. > Do people actually use it? I certainly never check the tracker for > alioth projects I'm involved with; I just assume people will use the > Debian BTS instead. Some people do use it. Not many, admittedly: we have a total of about 3600 tracker items in the database. But since we have a few cases of upstream development hosted on Alioth, it makes sense to offer an alternative to the Debian BTS that not everyone likes. Roland. -- Roland Mas Bonjour, je suis un virus de signature. Propagez-moi dans la vôtre !
Re: adoption - gdict
eechi von akusyumi (2000-12-24 19:03:47 +0800) : > I would like to adopt the package gdict and maintain it. Would you > guys ther like to give me some pointers on how should i do? You might want to have a look at the gnome-utils package. It's actively maintained by James LewisMoss, and it Replaces: gdict (since it includes it). So, you could either contact the maintainer and get him to re-split what was previously merged, or adopt the whole package, or help him maintain it. Roland. -- Roland Mas Au royaume des aveugles, il y a des borgnes à ne pas dépasser. -- in Soeur Marie-Thérèse des Batignoles (Maëster)
Re: adoption - gdict
eechi von akusyumi (2000-12-26 21:01:17 +0800) : > > You might want to have a look at the gnome-utils package. It's > > actively maintained by James LewisMoss, and it Replaces: gdict (since > > it includes it). So, you could either contact the maintainer and get > > him to re-split what was previously merged, or adopt the whole > > package, or help him maintain it. > > Would you like to give his email address to me? Um, you can get this information either by "dpkg -s gnome-utils" or by <http://packages.debian.org/>. His Debian login is dres, so his email address is [EMAIL PROTECTED] > and also, i'm now applying at http://nm.debian.org > and i want to know how long (average) is the process) It varies alot. You can get an idea of the numbers on the website itself. As an example, I applied in November and I am almost completely done (I'm waiting for the Debian account manager to create my account), but it takes longer for some other people. Roland. -- Roland Mas Chaos always defeats order, because it is better organized. -- Ly Tin Wheedle, in Interesting Times (Terry Pratchett)
Re: Bug#81396: root shell fscked after upgrade to woody
Eray Ozkural (exa) (2001-01-07 00:04:14 +0200) : > How should I debug this? One thing I did once was rename /bin/bash as bash-real, and write a #!/bin/bash-real wrapper that logged everything (yeah, I did not know of the "set -x" trick at that time). It might be dirty, but it might just work. Prefer the "set -x" one, though. Oh, an idea just struck me: you wouldn't have another user with UID 0, would you? Or two users by the name of root? Like, with another nsswitch method or something... Roland. -- Roland Mas Et c'est tellement plus mignon de se faire traiter de con en chanson... -- in En chantant (Michel Sardou)
Re: kernel-{image,headers} package bloat
Herbert Xu (2001-04-22 14:15:50 +1000) : > Yes you should. But then most people would be happy to have all of > the above as modules. I used to put plenty of things in modules. I even put ext2 in a module, three or four times. Wham, kernel panic at boot. Okay, I thought I wouldn't do the same error again. I haven't, for three years. Then one day I compiled IDE as a module. Boom again! Call me stupid if you like, but I think "all goes into modules" won't work. Roland. -- Roland Mas Mou ichido ! Hayaku ! Ookii koede ! -- Atsuko Sasaki
Re: kernel-{image,headers} package bloat
Herbert Xu (2001-04-22 22:23:04 +1000) : > Craig Sanders <[EMAIL PROTECTED]> wrote: > > > that would be one package, taking maybe a few hundred kilobytes total. > > > call it kernel-helper and make it depend on kernel-package. > > > problem solved. > > But why not take this one step further, let's just distribute what's > in build-essential and let the users compile the rest. Let's rewind > the clock back to times when men were men, and they compiled > everything on their own box :) Nonono, we should automate it as much as possible. I envision a global Makefile somewhere, and a ports/ directory, and a make-world.sh, and... And then Debian GNU/BSD! Yay! Seriously though, I think Craig's idea of a kernel-helper is cool. Roland. -- Roland Mas Plus on en fout, plus y'en a du riz. -- Proverbe chinois.
Re: Help wanted for packaging postgresql application
Andreas Tille (2003-05-25 21:56:04 +0200) : > For the next problem I have no real clue for a solution. The > bootstrap method does access the database as the newly created user > this requires a change of the PostgreSQL configuration. [...] > Now I would llike to know the following two things: > 1. How to change the postgresql configuration in a way which just > adds minimum off additional rights? > 2. How to accomplish this change? You might like to have a look at how the gforge-db-postgresql package (available from http://people.debian.org/~lolando/) does it. Basically, prepare a new pg_hba.conf, and ask the user whether to replace the existing one. Default to "no", of course. Roland. -- Roland Mas Ace of clubs? Let's see that. European Juggling Convention -- Svendborg, Denmark. http://ejc2003.dk
Re: debian-exim mailing list?
Marc Haber (2003-05-25 23:53:31 +0200) : > We actually discussed on the internal exim mailing list whether to > move the existing mailing list to alioth and decided against doing > so for lack of a web archive. Point of information: lists on Alioth are managed by Mailman, which does provide a web archive. Admittedly, not the same interface as what's on http://lists.debian.org, and no search engine, but still present. I have no idea (nor desire to get one) on what you're debating, though. Just pointing out a fact. I really don't care whether you create a list on Alioth, or on lists.debian.org, or not at all. Roland. -- Roland Mas Êtes vous sûr ? (O/N) -- Derniers mots d'un ordinateur
Re: Alioth docs? Renaming a project possible?
Marc Haber (2003-06-19 17:13:10 +0200) : > Is it possible to rename a project on alioth, or should one prepare > to live with a project name for all time being, or risk losing > project history? There is currently no sure-fire automated or manual way to accomplish this. Changing the name of the project in the DB is doable, but there are other places where the name has to be changed: Unix group name, directory, CVS repository, mailing-lists, probably more (this lack of a complete list of which we're sure is what prevents the sure-fire manual thing). It's a request that we hear from time to time, though. We (upstream developers for Gforge, maintainers for the Gforge package, admin team for the Gforge instance known as Alioth) are more focused on fixing bugs in the code and in the installation scripts for now, but project renaming is something we'll try to do at some point, promise. Of course, any help is welcome to make that happen sooner :-) Roland. -- Roland Mas - Ogenki desuka, yau de poêle ? - Genki desu, ture en zinc.
Re: but I want the GNU versions of packages
Dan Jacobson (2003-06-28 07:57:55 +0800) : > Gentlemen, after I installed "Debian GNU/Linux", I found I had to > take extra steps to get the GNU version of a program installed, as > some other leading brand alternative was in its stead. > > So what is the single command to apt-get install all the GNU > versions of everything? I humbly suggest "apt-get install task-gnu-only". Of course, someone will have to make and maintain that task package, but once done, there you are. Or you could start a Debian-GNU-Only subproject. Roland. -- Roland Mas Au royaume des aveugles, les borgnes sont mal vus.
Re: Excessive wait for DAM - something needs to be done
Martin Michlmayr - Debian Project Leader (2003-07-22 09:07:27 +0100) : [...] > At the same time I observe that this thread has generated much hot > air, but I didn't see any proposal of who could act as DPL. I know some Branden guy who's repeatedly volunteered to do that over the years :-) Roland. -- Roland Mas S'agirait pas d'atteindre la sublime transcendance du supramental sans se bouger le fion un minimum... -- in Sri Raoul le petit yogi (Gaudelette)
Re: [Debconf] Re: The slides for my talk
Enrico Zini (2003-07-22 14:56:08 +0200) :
> My talks archive is at:
> http://people.debian.org/~enrico/talks/
I would like to suggest to anybody interested that we conform to this
sort of naming scheme. There are lots of Debian developers doing
talks here and there, and quite often we like to borrow from each
other's slides. I know I've done it (and will do it again :-), and
it's sometimes a hassle to find where the talks are available.
I know it's not common practice ("ls -d */public_html/talks" on
people.debian.org:/home only gives five hits), but it could become
so, and would make it tremendously easier to find material to borrow
from for future talks :-)
Cc:ed and Mail-Followup-To:ed to debian-devel.
Roland.
--
Roland Mas
You can't second-guess ineffability, I always say.
-- Aziraphale, in Good Omens (Terry Pratchett and Neil Gaiman)
Re: Future releases of Debian
Matt Zimmerman (2003-07-23 11:25:27 -0400) : > I'm not convinced that establishing release goals will and deadlines > speed the release process. For example, a prominent release goal > for sarge will be debian-installer, since we cannot release without > it. Will telling the d-i developers "you must be finished by > " bring it to completion faster? We'll know soon enough: I've seen aj telling some d-i people just that on IRC yesterday. That's got to be accounted for in the "Debian takes leading position in free software projects for its advanced and experimental management methods" column, I suppose :-) Roland. -- Roland Mas Despite rumour, Death isn't cruel - merely terribly, terribly good at his job. -- in Sourcery (Terry Pratchett)
Re: Future releases of Debian
Martin Pitt (2003-07-23 17:57:10 +0200) : [...] > Besides, what's so bad with the current boot-floppies that they > could not be used for another release? They're the single most unpopular point of Debian. The installation process is universally known to be non-user-friendly. (Note I'm not saying it doesn't work.) Roland. -- Roland Mas ar c t e l l ièu ai ia mi. -- Signatures à collectionner, série n°1, partie 2/3.
Re: Future releases of Debian
Eduard Bloch (2003-07-24 12:03:24 +0200) : [...] > And here a decission has to be made: releasing with > not-sympatic-for-so-called-new-users BFs in 2003 or with stable D-I > one year later. This sounds exactly like the decision that was taken two years ago, resulting in having to fix the boot-floppies system (and in taking one more year to release). Don't let's repeat the past mistakes. Besides, sticking with b-f means we're on our own. Switching to d-i for real means we can get help from Skolelinux and Linex and probably many other "custom Debian" projects. Roland. -- Roland Mas La tradition orale, c'est comme un vieux fromage [...] -- Le Blaire -- Signatures à collectionner, série n°2, partie 1/3.
Re: logging out a ssh-user
Matthias Urlichs (2003-07-29 10:06:54 +0200) : > OK, but IMHO it's a good idea to get bugfixes out to the users > reasonably fast so that they can check if the bug really is > fixed. To that end, if you really have dealt with the bug, why not > upload the package? In my particular case (gforge), I'll have to hack around the no-binary-in-diff limitation of dpkg-source. I work in the same repository as upstream, and some images were changed. I suppose I'll have to start working on a branch to be protected from such things, but before I do that (totally unrelated) thing I can't upload a fixed package even though the bugs are fixed in the CVS. Roland. -- Roland Mas A man walks into a bar. Bang.
Re: debconf 2005 in Vienna, Austria
Gerfried Fuchs (2003-07-29 13:32:39 +0200) : > I'd like to start organizing the debconf for the year 2005 in > Vienna, Austria. Cool :-) > P.S.: It would be more than helpful if someone can write a report > about this years debconf for the events page that we can take a look > at to see how to make it right ,) I talked to Andreas and Tollef in Oslo, and they seemed to agree on the idea of a Organizing-a-Debconf-HOWTO, written in collaboration with Joe Drew and possibly Thierry Laronde. Let's see if/when that happens. I suggest a project on Alioth, so that stuff can be maintained by a team: the HOWTO, code for a registration site, name tag templates, asking-for-sponsors letter templates, etc. And suggestion tracking via the trackers. Roland. -- Roland Mas Et c'est tellement plus mignon de se faire traiter de con en chanson... -- in En chantant (Michel Sardou)
Re: Data loss: suggestions for handling
Matthew Palmer (2003-08-01 19:51:46 +1000) :
> The latest upstream version of a package I've begun to maintain,
> IRM, has a problem in that a portion of the data in the system
> (relating to software and licence assignment) can't be upgraded
> along with the rest of the database - the schema is totally
> different.
Do you have an upgrade script? Like a set of SQL commands that will
convert from one schema to the other? More importantly, do you have a
set of criteria to check that the upgrade went smoothly and is now
complete? If so, then I've done that successfully.
> I've thought about it for a while, and I can't come up with any good
> way to make the change. The best I've come up with so far is to put
> a question in the postinst which warns the user and allows them to
> continue if they're sure, or they can CTRL-C out and backup. If
> it's running in non-interactive mode, the install aborts. I really
> want to make sure the user doesn't lose all their data.
I faced the same problems with sourceforge and gforge.
> A couple of questions:
>
> * Am I being too paranoid?
Probably not. Maybe some of your users won't mind too much if they
lose data, but most of them probably will. Then there's the personal
pride in building a crash-proof system even if nobody notices.
> * Can anyone think of another way of handling this? I can think of
> a couple of other ways:
>
> - create an irm1.4 package, but that is, shall we say, ugly
Ugly indeed.
> - dump the old software tables and store the dump somewhere,
> giving pointers to the dump in all sorts of useful places.
Could be an option.
> I appreciate any comments or suggestions anyone has as to how I
> could proceed.
The way I did it for the sourceforge and gforge packages is this: I
have a special table (called debian_metadata), in which I can store
key-value pairs. One of the keys (okay, the only one normally) is
"db-version", and the corresponding value is a version number with the
same semantics as the one provided by dpkg for the ordering). When I
need to upgrade something, I go the following steps:
,[ One upgrade chunk ]
| Begin transaction
| Do stuff
| Check that stuff went fine (and raise an exception/abort if not)
| Update the value for db-version
| Commit transaction
`
This is of course only executed if current db-version is less than
targeted version. So I have a series of upgrade chunks, arranged like
this:
,[ Upgrade script ]
| $target version = 1.0
| if (current-version < $target-version) {
|Do the upgrade chunk for target=$target-version
| }
|
| $target version = 1.1
| if (current-version < $target-version) {
|Do the upgrade chunk for target=$target-version
| }
|
| $target version = 1.4
| if (current-version < $target-version) {
|Do the upgrade chunk for target=$target-version
| }
`
The postinst script always runs this upgrade script. So all the
steps that were previously completed are not replayed, and you'll
start at the first one that hasn't been successfully run yet. If one
step fails, the transaction is aborted and the user is presented with
an error message giving out info such as the current db-version, the
SQL statement that went wrong, and so on. And he's requested to
report the bug with this info :-)
All this requires a transactional database, obviously, but they're a
dime a dozen these days.
For more details, apt-get source gforge and have a look at the
deb-specific/db-upgrade.pl script.
Roland.
--
Roland Mas
You can't second-guess ineffability, I always say.
-- Aziraphale, in Good Omens (Terry Pratchett and Neil Gaiman)
Re: Bits from the RM
Tollef Fog Heen (2003-08-23 13:26:20 +0200) : > * Joe Drew [...] > | What are the criteria for the apache package to become Apache 2? > > Seamless upgrade without loss of functionality (that includes > modules), > > or > > making pigs fly. 1. All you need for that is thrust (see Ginger, Mac and Rocky); 2. Debian prides itself on its web of thrust; 3. therefore the web servers in Debian do provide enough thrust. ...or am I missing something? :-) Roland. -- Roland Mas Lord of the rings? Show us. European Juggling Convention -- Svendborg, Denmark. http://ejc2003.dk
Re: Update: Patch needs Sponsor - List of easily NMUed RC bugs
Goswin von Brederlow (2003-08-23 23:59:31 +0200) : > Goswin von Brederlow <[EMAIL PROTECTED]> writes: > >> Hi, >> >> I went through the RC bug list and collected Bugs with trivial patches >> and sorted them a bit. They realy don't need much work so if you have >> a minute pick one. If you want to NMU any of them check the >> then currently claimed bugs (url under claimed bugs). > > Changes: pending (+1), fixed(+13). > Keep up the good work sponsoring those uploads. Keep up the good work yourself. I find this kind of message very useful. Also, Joshua's patches on some (if not most) of these bugs are a treat, too. Thanks to you both. Now for the real content: people, don't start working on a bug before you've checked http://bugs.debian.org/cgi-bin/claims.cgi for effort duplication. I've wasted enough time myself already :-) Roland. -- Roland Mas [...] Des fois, y'a des trous. -- (Ptiluc) -- Signatures à collectionner, série n°2, partie 3/3.
Re: Alioth Project Denied
Loïc Minier, 2005-08-07 17:10:06 +0200 : > Hi, > > On Sun, Aug 07, 2005, Olaf van der Spek wrote: >> > We can probably. Would you care to provide us the patch ? >> A patch to change a from email address? > > I suppose it's nice to: > - spot where the change needs to be made > - move that to a configuration file if it's not already in a config >file > - integrate the change to some sensible default ([EMAIL PROTECTED], or >[EMAIL PROTECTED], or [EMAIL PROTECTED]) in Debian and the gforge >package in general > - integrate the config option in the debconf templates Or, in order to appease the crowds quickly: - locate place to hack; - hardcode '[EMAIL PROTECTED]' in there; - rebuild packages; - install packages. Alioth.debian.org is currently undergoing the last of these steps. Roland. -- Roland Mas Luck, like a Russian car, generally only works if you push it. -- Regalian, in My Hero (Tom Holt) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: arch, svn, cvs
Roberto C. Sanchez, 2005-08-19 21:00:18 +0200 : > On Fri, Aug 19, 2005 at 02:33:31PM +0200, martin f krafft wrote: [...] >> I won't go through the trouble to compile the extensive list of >> problems and design issues with SVN. > OK. Then please just name two or three. If I may chime in... The Berkeley DB storage backend was an enormously stupid thing, but that's been fixed (phew). My main gripe with Subversion now is that if I'm not mistaken (which I could very well be, since I've switched to baz and only use SVN for $HOME/bin/) you can't really do the equivalent of "cvs update -j foo-branch-last-merge -j foo-branch" without having to read commit logs, extract revision numbers from there, and use these revision numbers in the command line. Roland. -- Roland Mas The cherry blossom / Tumbles from the highest tree / One needs more petrol -- in Good Omens (Terry Pratchett and Neil Gaiman) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#323855: ITP: opencvs -- OpenBSD CVS implementation with special emphasis in security
Peter Samuelson, 2005-08-20 13:50:10 +0200 : > And we don't have multiple implementations of it in Debian, either. > That is the *real* point. Of course, we don't have multiple implementations of a minimal shell aiming at POSIX compliance. Or an X server. Or a light, fast yet configurable window manager. Or an FTP server. Or a tool to tag collection of MP3 files. ...or do we? Roland. -- Roland Mas Plant a radish, get a radish, never any doubt! -- Bellamy & Hucklebee, in The Fantasticks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: arch, svn, cvs
Florian Weimer, 2005-08-20 20:50:12 +0200 : > * Roland Mas: > >> The Berkeley DB storage backend was an enormously stupid thing, >> but that's been fixed (phew). [...] > I'm storing hundreds of millions of rows in Berkeley DB tables and > have yet to encounter data loss because of bugs in Berkeley DB code. I wasn't implying anything related to data loss. It's just the "can't have read access without write access to the whole repository" part that bothered me. Roland. -- Roland Mas 'ALL your base? No!! One tiny base continue bravely to resist.' -- in #debian-devel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to cope with patches sanely
Andreas Tille, 2008-01-25 12:16:02 +0100 : > On Fri, 25 Jan 2008, Lucas Nussbaum wrote: > >> I made some stats (see [1]). 7.8% of our packages use quilt, while >> 14.4% use dpatch. It would be great to document in some place >> (devref?) why quilt should be used instead of dpatch, because I >> don't think it's obvious for everybody :) > > Yes, please do so! I would like to read that. Seconded. Also, please include the "how" as well as the "why" :-) Roland. -- Roland Mas [...] ou une dent pourrie [...] -- in Variations sur un thème imposé -- Signatures à collectionner, série n°2, partie 2/3. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Practical solutions to: the new style "mass tirage" of bugs
Roberto C. Sánchez, 2008-02-22 08:33:17 -0500 : [...] > Now, if I could run an 'apt-get source -t unstable foo' and create > my patch against the resulting source package, and be sure that the > maintainer won't reject it on the grounds of the patch not being > against the head (or latest, or whatever) of whichever $DVCS they > happen to be using, then things would be a little better. I believe that's exactly what debcheckout(1) is for. As for generating the patch, maybe debcommit(1) could be extended to provide a --diff-only option that would just output a patch rather than try to actually commit. And while we're at it, maybe there could be a debcheckout --update option that would update the working copy to the current state of the repository. (JoeyH, Zack -- *hint*, *hint* ;-) Roland. -- Roland Mas Sauvez les castors, imprimez en recto-verso. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to deal with #402010?
Cajus Pollmeier, 2008-04-04 09:18:37 +0200 : > Hi, > > my position to this bug is written down in the bugtracker and I > don't consider this a bug. Any opinions about what to do with it? It > would apply to virtually any kind of web application accessing some > kind of database/ldap passwords somewhere in the filesystem. Depending on the web server, there may be a way around that problem. The following works with Apache, at least, and I guess it can be adapted to other servers as well. The thing is to store the passwords or sensitive info in files that are only readable by root, and have Apache read these files and export the information selectively to some webapps and not others, by wrapping the appropriate directives in VirtualHost (or similar) blocks. Then it's a simple matter (ahem) of passing the info to the webapp, and there are two ways to do that: with SetEnv (not ideal) or with RequestHeader (probably better). Roland. -- Roland Mas Et c'est tellement plus mignon de se faire traiter de con en chanson... -- in En chantant (Michel Sardou) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#402010: How to deal with #402010?
sean finney, 2008-04-05 11:59:31 +0200 : [...] >> RequestHeader set FooPassword very-secret-credentials > > i suspect php users will still be able to find that out, in the same > way that they can read ssl private keys from the webserver's memory > (you *did* know they can do that, right? :) Erm, no, I didn't. Is that supposed to happen (by design), or is it just a bug in the PHP interpreter? It sounds like a severe security problem... Roland. -- Roland Mas Au royaume des aveugles, il y a des borgnes à ne pas dépasser. -- in Soeur Marie-Thérèse des Batignoles (Maëster) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Sorting out mail-transport-agent mess
Eugeniy Meshcheryakov, 2008-05-16 02:10:39 +0200 : > This can happen if user has 'default-mta' package installed, and it > changes (if it is done like with 'gcc' package now). Unless default-mta Depends: exim4 | mail-transport-agent. But that's a bit ugly. Roland. -- Roland Mas Fate always wins... At least, when people stick to the rules. -- in Interesting Times (Terry Pratchett) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: piuparts-MBF: not using invoke-rc.d
Holger Levsen, 2009-08-06 11:27:34 +0200 : > Hi, > > as announced at DebConf9 I'll now (slowly) start threads about > different bug categories detected by piuparts, with the aim to agree > on mass filing bugs with the correct severity. Thank you for this effort. I must admit piuparts has been too frightening for me to try, so far. So, in order to comfort me in my laziness, would you consider doing continuous (or regular) runs of piuparts on the whole archive, and sending the results to the PTS (probably with a new keyword)? Roland. -- Roland Mas Just a little bit of you every day will surely keep the doctors away. -- Just a little bit of you (The Jackson Five) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: piuparts-MBF: not using invoke-rc.d
Holger Levsen, 2009-08-06 14:44:53 +0200 : > Hi Roland, > > On Donnerstag, 6. August 2009, Roland Mas wrote: >> Thank you for this effort. I must admit piuparts has been too >> frightening for me to try, so far. So, in order to comfort me in my >> laziness, would you consider doing continuous (or regular) runs of >> piuparts on the whole archive, and sending the results to the PTS > > Uhm, there was this mail to d-d-a which I planned to send, but haven't, > yet ;-) > > Go to http://piuparts.debian.org where you can find the results for > piuparts runs on the whole archive for sid and squeeze (for those > packages which have been tested, which are those which depends have > been successfully tested by piuparts). Excellent. > These results are already integrated in the PTS, see for example > http://packages.qa.debian.org/l/lpr.html - piuparts links are only > shown in the PTS if there are problems. Ah-ha, that's what confused me. I only looked at the page for one of my packages, and it didn't display anything. My fault for being lazy. Thanks again, Roland. -- Roland Mas Such compressed poems / With seventeen syllables / Can't have much meaning... -- in Gödel, Escher, Bach: an Eternal Golden Braid (Douglas Hofstadter) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
New SCMs on Alioth, and a call for (one-off) help
Hi all, As you all know and hate, the various source control management systems that are set up on Alioth were mostly managed by hand. The reason was that FusionForge (and SourceForge and GForge before that) didn't have any integration for anything but CVS and Subversion. This recently changed (see [1] for a few details), and I have a FusionForge branch (based on 4.8) with plugins for Arch, Bazaar, Darcs, Git and Mercurial, in various states of completeness. That branch has now been merged into what's installed on Alioth. People registering a new project now have a choice for all these SCMs (or none at all, if they so choose). (As an aside, existing projects can now define tags and be displayed in a tag cloud visible on the front page.) As I said, the plugins are in various states of completeness. CVS is complete, but Arch is barely started, since I only recently realised that there were actually people using it (hello, pkg-gnustep ;-). The good news is that the missing parts shouldn't be hard to do, especially for regular users. I factored what could be factored, and now only some of the specifics have to be implemented. And that probably just means cut-n-pasting from another plugin and replacing what needs to be replaced. I am therefore looking for, yes, volunteers to complete that effort. If you're familiar with your tool, it shouldn't take long, and it'll help other users of Alioth (as well as your friendly Alioth admins). I'd be grateful for any help. The Bazaar branches are currently at [1] and [2], the former having only the SCM changes compared to upstream, the latter having the rest of the Alioth patches too. If you think you can help, please "bzr checkout $url" and poke in gforge/plugins/scm* :-) Thanks, Roland. [1] http://bzr.debian.org/anonscm/bzr/users/lolando/fusionforge/patches/scmrefactor-4.8 [2] http://bzr.debian.org/anonscm/bzr/users/lolando/fusionforge/alioth-4.8 -- Roland Mas Time is a drug. Too much of it kills you. -- in Small Gods (Terry Pratchett) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: New SCMs on Alioth, and a call for (one-off) help
Hi again, It has been brought to my attention that the URLs for the FusionForge branches I mentioned in my previous email were broken. Here are the correct ones: http://alioth.debian.org/anonscm/bzr/users/lolando/fusionforge/patches/scmrefactor-4.8 http://alioth.debian.org/anonscm/bzr/users/lolando/fusionforge/alioth-4.8 Also, a brief explanation about how the new plugins work (or should work) should be useful. An SCM plugin for FusionForge basically does a few things: - creates a repository when a new project is created; - gathers rough statistics on commits over time; - displays instructions on how to access the repository (for anonymous read-only access and for read/write access for project members); - displays a link to (or an iframe containing) a repository browser; - configures the repository browser with the list of known repos; - configures Apache so that browser is accessible at the chosen URL; - generates tarballs of the complete repositories, as well as snapshots of the current HEAD/trunk/master/main branch. Most of these actions (not the Apache configuration) are implemented as class methods in the plugin (gforge/plugins/scmfoo/common/FooPlugin.class). Since all the plugins are derived from the same class, they have the same API, and completing one plugin can be a simple matter of copying the missing bits from another plugin and rewriting the specifics. For reference, the Darcs plugin is complete (thanks to Sylvain Le Gall), so it should be usable as a base. The Git plugin is mostly complete, and should only be missing the parts about the repository browser and the code to map email address to login names (thanks to Mehdi Dogguy). I think CVS is complete. SVN lacks the repository browser. Not sure about Mercurial, but Arch is currently empty (I didn't even remember how to create a repository). Roland. -- Roland Mas Neko-no me-to, onna-gokoro-to, aki-no-sora. -- Proverbe japonais (« Souvent femme varie, bien fol est qui s'y fie. ») -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: New SCMs on Alioth, and a call for (one-off) help
Roland Mas, 2009-08-24 14:15:18 +0200 : > For reference, the Darcs plugin is complete (thanks to Sylvain Le > Gall), so it should be usable as a base. The Git plugin is mostly > complete, and should only be missing the parts about the repository > browser and the code to map email address to login names (thanks to > Mehdi Dogguy). I think CVS is complete. SVN lacks the repository > browser. Not sure about Mercurial, but Arch is currently empty (I > didn't even remember how to create a repository). Blargh, forgot to mention Bazaar: the missing parts are the gathering of statistics and the browser. Roland. -- Roland Mas - Ogenki desuka, yau de poële ? - Genki desu, ture en zinc. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Package formats and software distribution on Linux
Eugene Gorodinsky, 2009-11-20 02:01:19 +0200 : > There is a sort of oligopoly in linux because of package management. > There are several main distros which have a lot of package maintainers > and a lot of packages as a result of this. Smaller distros need to > choose between compatibility with existing packages and innovation > (whatever that may be) [...] > A universal package format would benefit these distributions, since a > lot less resources would have to be spent in order to create a new > distribution. I've read that several times, but I still must be missing something. My impression is that your poins is essentially the following: 1. it's too much work for "small distros" to use any new format instead of one of the big established ones; 2. let's reduce the number of big established formats to one. If that's approximately correct, then aren't these points in contradiction? I think the choice of established formats actually benefits the "smaller distros" since they can pick the one more adapted to their needs. Interesting questions nevertheless :-) Roland. -- Roland Mas [...] ou une dent pourrie [...] -- in Variations sur un thème imposé -- Signatures à collectionner, série n°2, partie 2/3. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Has Debian abandoned Python?
Steve Langasek, 2009-12-03 06:17:05 -0800 : [...] > Conflict of interest? Oh, disregard the previous comments, then; > apparently this /is/ just a thinly-veiled slander. Not necessarily. I'm not sure about the state of law worldwide, but French law has at least two criteria for slander (which we call « diffamation » here): falsehood and malicious intent. The reality of the conflict of interest is the very point being scrutinised here, and I think you'll agree there isn't a wide consensus on the lack of such a conflict. And since we are putting aside Ubuntu and mainly concerned about Debian, I claim one can, in good faith, consider the facts as a plausible indication of the existence of this conflict. Call me a slanderer if you like, but I'd rather you provided the salient facts needed to dissipate the misunderstanding (or make the bad faith more evident). > The question of whether someone is doing an adequate job of > maintaining a package is a legitimate one. The identity of their > employer is immaterial to an objective examination of this question. Let me disagree on that. It wouldn't mean much if the employer were unrelated, but in this case the identity of said employer *has* some bearing. Because it tells us that: Matthias has the technical abilities to do the job he's volunteered to do; he's presumably doing a good job in Ubuntu, unless Canonical is very lenient with its employees; and his employer has stated that Canonical employees are encouraged to do the right thing in relation to Debian. These points cannot be swept under the carpet with handwaving or accusations of slander alone. The timing of #559206 is probably just an unfortunate coincidence, but I find it telling nevertheless. Roland. -- Roland Mas Time is a drug. Too much of it kills you. -- in Small Gods (Terry Pratchett) -- 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
David Paleino, 2009-12-21 09:13:17 +0100 : [...] > I mean, meta-packages should *always* have their Recommends installed, > otherwise they have no point in existing. If it's *always*, then… isn't your proposal pointless? If it's merely a *should*, then Recommends is a fine solution. [...] > What's the use of a metapackage if you only choose 2-3 from, say, 20-30 > "dependencies"? > You'd better go with selecting those 2-3 directly. At least IMHO :) And that's what we have tasks for. > Try to change your POV from the uber-user, who knows how to install "base" > packages and let others be pulled in, to the low-level users, which want > "gnome" installed, but don't want "rhythmbox" nor "banshee" installed. This > is what they do (writing the CLI version, but they're likely to use > something like Synaptic): > > # aptitude install gnome > # aptitude remove rhythmbox > > OOPS! Since aptitude does "autoremove" by default, the users suddenly get > asked to remove all their desktop environments. How many requests of this > type have you seen on IRC, mailing lists, Usenet? I've seen *TOO MANY*, and > that's why I drafted this DEP in the first place. > > Definitely no, I don't think this is a marginal situation not worth > doing some implementation work. (and I could help making patches, > where I can) Then I suggest you just help converting the gnome metapackage to a task, since this'll work with no intrusive changes in our tools. Roland. -- Roland Mas Neko-no me-to, onna-gokoro-to, aki-no-sora. -- Proverbe japonais (« Souvent femme varie, bien fol est qui s'y fie. ») -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: On maintainers not responding to bugs
Matthias Julius, 2007-03-07 11:32:32 -0500 : > It's a matter of how someone arrives at the point where he wants to > help. If he wakes up one morning and thinks "I want to help the KDE > team" he will probably contact the KDE maintainers. If he thinks > "Since 3 years I am using Debian it's time for me to contribute." he > might look in more generic places to find out who requests help. In that case, I suppose http://www.debian.org/intro/help should be made a bit more helpful. More visible, more readable, and so on. I understand one of the DPL candidates intends to work (or get people to work) on the Debian website; I suggest this page could be considered during that endeavour. Roland. -- Roland Mas With the arrest of Dimitry Sklyarov it has become apparent that it is not safe for non US software engineers to visit the United States. - Alan Cox -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bug closed by spam for the second times
Theppitak Karoonboonyanan, 2008-09-08 21:53:47 +0700 : > I think this case is difficult for spam filter. The text is > deliberately shuffled with HTML tables so that the final rendered > page becomes readable to human readers, but the source is completely > meaningless to the filter. It's then ended with a meaningful > paragraph to pass it. > > Any trick to capture the final rendered page before passing it to > the filter for analysis? I don't know. Maybe by extracting the thumbnail-generating code from Chrome (unless it depends on X11) and piping that to OCR software... Roland, tired of the arms-race too. -- Roland Mas Qu'est-ce qui est jaune, qui pèse deux cents kilos et qui chante ? Un sumotori dans sa salle de bains. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#498396: ITP: argyll -- ICC compatible color management system
Package: wnpp Owner: Roland Mas <[EMAIL PROTECTED]> Severity: wishlist * Package name: argyll Version : 1.0.3 Upstream Author : Graeme Gill <[EMAIL PROTECTED]> * URL or Web page : http://www.argyllcms.com/ * License : GPLv3 Description : ICC compatible color management system For reasons lost in the mists of time, ArgyllCMS is only in Christian Marillat's Debian-Multimedia repository. A quick glance through the sources don't show any licensing problems, so I think it would be a good addition to Debian main. I'll most probably use the current packaging as a base for the first upload to Debian, although it may evolve as time passes. Roland. -- Roland Mas In every life you got some trouble, when you worry you make it double. -- in Don't worry, be happy (Bobby McFerrin) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#504758: gforge-plugins-extra ships security issues-prone code copies
tag 504758 + help thanks Raphael Geissert, 2008-11-06 15:42:52 -0600 : > Package: gforge-plugins-extra > Severity: serious > Version: 4.7~rc2-5 > Tags: security > > Hi, > > By taking a look at the list of files shipped by > gforge-plugins-extra I can easily see several scripts which are > already in the Debian archive. I'm using 'serious' as the severity > given the fact that in many of the already packaged scripts security > issues have been found in the past. I'm sort of aware of that, but I'm undecided as to how to react. This package contains plugins that are not exactly supported (by me at least), and these plugins are not installed or made operational when the package is installed. They require manual intervention to set up, and are only shipped as part of a deb as a convenience. The way I see it, there are three ways out: - prepare a new upload that doesn't contain this binary package, and leave users with the task of getting the code from the source package and installing it by hand; - ignore this bug for lenny, since one could argue that the code isn't actually made operational by the mere installation of the package; - actually patch the code to use system-provided packages, and update dependencies accordingly. This has already been done for some libraries (Snoopy and FCKeditor), and it's not a huge task, but I probably won't have time to tackle it before the lenny release (real-life time constraints abound). I'm therefore soliciting advice and/or help on that problem. Roland. -- Roland Mas A lesson for you all: never fall in love during a total eclipse. -- Senex, in A Funny Thing Happened on the Way to the Forum -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#504758: gforge-plugins-extra ships security issues-prone code copies
Roland Mas, 2008-11-09 14:57:52 +0100 : > The way I see it, there are three ways out: > > - prepare a new upload that doesn't contain this binary package, and > leave users with the task of getting the code from the source > package and installing it by hand; Just for reference: I ended up doing just that. Roland. -- Roland Mas ()Campagne du ruban ASCII : /\Contre les mails en HTML et les vcard ! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: proposed release goal: DEBIAN/md5sums for all packages
Stefano Zacchiroli, 2007-08-17 12:43:55 +0200 : > On Fri, Aug 17, 2007 at 12:35:30PM +0200, Romain Francoise wrote: >> For the record, the list of binary packages without md5sums > > Can you please upload this to people.debian.org or somewhere, and > maybe keep it periodically updated? I guess it would be useful for > the sake of deciding what to do. Maybe add a lintian/linda test? Maybe add that to Lina (http://asdfasdf.debian.net/~tar/lina/)? Roland. -- Roland Mas Fate always wins... At least, when people stick to the rules. -- in Interesting Times (Terry Pratchett) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Git on Alioth
Peter Karlsson, 2007-08-23 09:50:53 +0200 : > Hi! [...] > Any pointers to the obvious documentation links I've managed to > overlook are very welcome. http://wiki.debian.org/AliothGit may be a starting point. Roland. -- Roland Mas LinkedIn profile: http://www.linkedin.com/in/rolandmas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian's Linux kernel continues to regress on freedom
John Kelly, 2007-09-12 18:33:12 + : > Again, if Debian's highly esteemed social contract is for the > benefit of users, then why not let users vote? We do, actually. Those users who do show interest in influencing the course of Debian by concrete actions rather than by mailing-list trolling are entitled to vote. Others aren't. How do we know the difference? The criterion is known as the NM process. It's open to all. Roland. -- Roland Mas Death *was* hereditary. You got it from your ancestors. -- in Hogfather (Terry Pratchett) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the Testing Security team
Ian Jackson, 2007-10-17 15:00:55 +0100 : [...] > And if there is no good reason to have the decompressors bound in > then having that facility wired into the code is just extra > complexity to no useful purpose. I thought the ability to just copy one binary (/usr/bin/dpkg) from one box to another and be able to use it right away was precisely the goal of static linking in that case. Roland. -- Roland Mas Au royaume des aveugles, les borgnes n'ont qu'un oeil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#447592: RFP: fckeditor -- text/file editor for PHP
Package: wnpp Severity: wishlist * Package name: fckeditor Version : "recent enough" Upstream Author : Frederico Caldeira Knabben <[EMAIL PROTECTED]> * URL or Web page : http://www.fckeditor.net/ * License : GPL/LGPL/MPL Description : text/file editor for PHP Nico Golde just contacted me about a problem found in the FCKeditor code that's shipped in the Gforge package. Apparently, there's at least one other package that ships this code (knowledgeroot), so the code is effectively duplicated. It would be better for everyone if that software was packaged independently, and others could just depend on it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Consistent handling of the DEB_BUILD_OPTIONS
Neil Williams, 2007-11-06 16:08:11 + : > Actually, Guillem has already filed the bug: 416450 [PROPOSAL] New > option in DEB_BUILD_OPTIONS to avoid running test-suites > > What needs to happen for that to be mandatory in Lenny? Get the option widely used, then documented (as a MUST) in policy, then agreed on as a release goal (or fix the bugs even if they're not RC :-) Roland. -- Roland Mas Indépendant en informatique libre -- Free software freelance http://www.gnurandal.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#566884: ITP: gnome-color-manager -- Color management integration for the Gnome desktop environment
Package: wnpp Owner: Roland Mas Severity: wishlist * Package name: gnome-color-manager Version : 2.29.2 Upstream Author : Richard Hughes * URL or Web page : http://projects.gnome.org/gnome-color-manager/ * License : GPL-2, GFDL for the docs Description : Color management integration for the Gnome desktop environment GNOME Color Manager is a set of graphical utilities for color management to be used in the GNOME desktop. With the help of ArgyllCMS, it can create and apply display ICC color profiles. This has at least two selling points: first, it replaces handmade scripts to load ICC profiles at login time; second, it wraps ArgyllCMS and hides the complexity of its command-line under one button (it restricts the available options by doing so, but hopefully that's temporary rather than permanent, since the app is rather new). #debian-gnome (well, one person in there :-) tells me they're interested in maintaining the package. I'll probably upload a first version to experimental and see how it goes from there. Roland. -- Roland Mas One... two... one, two, many, lots! -- Lias, in Soul music (Terry Pratchett) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: md5sums files
Wouter Verhelst, 2010-03-03 03:06:20 +0100 : [...] > In this day and age of completely and utterly broken MD5[0], I think > we should stop providing these files, and maybe provide something else > instead. Like, I dunno, shasums? Or perhaps gpgsigs? But stop > providing md5sums. > > Or is it useful to be able to say "if it doesn't check out, it's > certainly corrupt, and if it does check out, it may be corrupt"? > Didn't think so. It is useful. Not too efficient against attacks, I'll grant you, but there are other use cases. One of those I run into from time to time, as maintainer of servers with webapps, is that I want to know from time to time if there have been local changes in installed files when compared to the (already custom) packages, so I can have a look and integrate the changes into the next version of the custom packages. The suggestion of having dpkg warn me on upgrade is interesting, but to be proactive I'm happy to run debsums on my own before the deployment stage. Because when you're in a deployment rush and one of the files lacks a semicolon and breaks the whole app, you just $EDITOR /usr/share/.../foo.php; some other times, your client messes with their CSS files locally, and you don't want to be grumbled at if you lose that change, even if you (and the client) know that the change *should* have been done in the packages in the first place. I'm quite okay with replacing or complementing the md5sums with something stronger if it helps with security, but removing them altogether… please no. Roland. -- Roland Mas La menace de la baffe pèse plus lourd que la baffe elle-même. -- in Sri Raoul le petit yogi (Gaudelette) -- 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/87iq9du42q@mirexpress.internal.placard.fr.eu.org
Re: How to make Debian more attractive for users, was: Re: The number of popcon.debian.org-submissions is falling
Josselin Mouette, 2010-07-27 08:58:01 +0200 : [...] >> Now with some additional prompts to the user to get subject and body, >> I don't see how a web app that can get this same information as >> reportbug can not be developed. > > Yeah sure. With an ActiveX maybe? Probably easier: add a CGI-like interface to reportbug, and open a browser on it? Since it *is* reportbug, it can continue grabbing whatever information is relevant using its scripts. And then it's a matter of a menu entry (or a big fat icon) running "reportbug --http & sensible-browser http://localhost:$some-port/";. AJAX to taste, then submit via local or remote SMTP. Roland. -- Roland Mas Plus on en fout, plus y'en a du riz. -- Proverbe chinois. -- 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/87wrsgyl4t@mirexpress.internal.placard.fr.eu.org
Re: Debian ppa
William Grant, 2010-09-23 16:31:57 +1000 : [...] > While Launchpad.net does not provide Debian PPAs, what prevents you from > taking the Launchpad code, rebranding it, and running your own instance? Based on a presentation given by Jonathan Lange (product strategist for Launchpad) at LSM this summer, the Launchpad code was never *really* intended to be run in other instances than launchpad.net. It was initially a “that would be nice” feature, but nobody really took some time to do it, and it wasn't a constraint taken into account when designing the evolutions. The code was eventually made publicly available after much nagging, but a friend of mine who tried installing it ran away screaming, much like I initially ran away screaming when I started fiddling with Sourceforge. It took several years (and two forks/renamings) to have *Forge packages that can actually be installed with a reasonably low effort. Also, still according to Jonathan, there are several people working full-time on Launchpad sysadmin at Canonical. We at Debian don't have that kind of resources. > It does require some changes to work with Debian's suites, but that > would be far easier than reimplementing all the functionality yourself. Given the above, I strongly doubt that. Adding PPA-like functionality to FusionForge *might* be easier, since we already have Alioth, but even that would be a significant amount of work, if only to setup the build-daemons for that new service. Roland, Source^WGForge^WFusionForge maintainer since summer of 2000 and *still* not quite mad (or am I?). -- Roland Mas Bada, bada, ba-da-da-daaa, doudou, doudou, dou-dou-dou-dou-baaa. -- in Song without words #1 (Paul Leavitt) -- 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/8739t0g8g3@mirexpress.internal.placard.fr.eu.org
Re: recovering from compromised keys
Mike Hommey, 2010-09-23 17:14:01 +0200 : > On Thu, Sep 23, 2010 at 11:50:26PM +0900, Osamu Aoki wrote: >> On Thu, Sep 23, 2010 at 03:13:06PM +0100, Simon McVittie wrote: >> ... >> > By policy, we use full-disk encryption at my workplace (where full-disk >> > really means "except the bootloader and /boot"). For a 2-year-old recipe >> > for >> > it, which I believe still mostly works with grub2, see >> > http://smcv.pseudorandom.co.uk/2008/09/cryptroot/ >> >> Can we maintain suspend/resume type-features with such configuration? >> >> Unless we use unencrypted swap, it seems we have to give up >> suspend/resume. Then we a bit of loose security >> >> How people cope with this on laptop ... I am curious. > > You only need to give up *randomized* swap encryption. You can still > have an encrypted swap, you just can't use a random key. Indeed. My current setup is that sda1 is small, unencrypted and holds /boot only. sda2 is the whole rest of the hard disk, and it's mapped to a LUKS device used as a physical volume for LVM, and there are several LVs on there, including those mounted as filesystems and one for swap. Roland. -- Roland Mas Au royaume des aveugles, il y a des borgnes à ne pas dépasser. -- in Soeur Marie-Thérèse des Batignoles (Maëster) -- 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/87lj6seask@mirexpress.internal.placard.fr.eu.org
Re: recovering from compromised keys
Paul Wise, 2010-09-24 10:49:21 +0800 : > On 9/24/10, Simon McVittie wrote: > >> Suspend-to-RAM also works, but is obviously not secure against attackers >> waking up the laptop and exploiting some bug in a locked screensaver, or >> remote access, or whatever. > > Don't forget about folks using cold boot attacks to grab your key from > RAM. I also saw a paper somewhere about returning the system to a > running state after such attacks. Could that be mitigated by the kernel maybe? Like, it could wipe the part(s) of the RAM where the key is stored before actually shutting down the host. Roland. -- Roland Mas Fate always wins... At least, when people stick to the rules. -- in Interesting Times (Terry Pratchett) -- 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/877hibehui@mirexpress.internal.placard.fr.eu.org
Re: Summary of CUT discussions
Raphael Hertzog, 2010-09-27 10:16:50 +0200 : [...] >> > Again it's unrelated to the existence of rolling, the problem is >> > inactive maintainer not taking care of their packages and those are >> > not the same that would actively push their packages to rolling. >> >> What do you base this on? It does not at all seem clear to me that >> rolling would not introduce maintainers who only care about rolling. > > Nobody can predict the future... but my take is that the people who > only care about rolling would be the people who do not care of testing > right now already. Those who care about testing would continue to do > it. Without any hint as to how you came to that conclusion, this assertion can't be considered more than a gut feeling. [...] > A big part of CUT is also changing our communication, both internal and > external: > - internal to say to all contributors that testing/rolling is meant to be > always usable so you must be careful in everything you upload to sid, no > matter whether we're far from release or not and RC bugs are always > important to fix, and you must care about migration to testing/rolling > because many users will want the latest version in that distribution This is not a change in communication, it's a change in policy, and a huge one too. Right after a release has always been a time for experimenting and introducing intrusive changes to unstable. Telling maintainers they now need to refrain from these changes is not something that can be decided lightly. Especially since imposing extra restrictions on the work one does on Debian is going to be one more reason for people not to care about Debian. We're supposed to make working on Debian *easier*, not add extra barriers. > - external to say to users that testing/rolling can be safely used and > is supported by the Debian project at large Based on the previous remark, that would be a lie. I for one wouldn't like to be seen to support a move that prevents me from introducing large changes from time to time. > I don't know when rolling would be introduced, and I don't know when > squeeze will be released. If we start rolling during this freeze, we > will probably only do testing + hand-picked updates to make it more > usable (i.e. no automatic britney run from unstable to rolling). Who's this “we”? That's an honest question: so far I haven't seen much support from the release managers, so I wonder who's going to do the work of creating the new suite, defining its package migration policy and implementing that into the appropriate code, or doing the actual migration by hand in the initial phase. That's important because from it will come the necessary buy-in from developers — or not. If you, Raphaël, start providing new Release/Packages/Sources that you compute from the ones in sid or testing, that's all fine and dandy, and we get a rolling thing. But it's not official, and it's not supported, and it's not “safely used”. If the release team does it (possibly with you as part of it), with sufficient buy-in from the developers, then we have something worth something. Roland. -- Roland Mas When you have a hammer in your hand, most things look like a nail. -- 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/8762xr5xp2@mirexpress.internal.placard.fr.eu.org
Re: Summary of CUT discussions
Raphael Hertzog, 2010-09-27 14:21:12 +0200 : > Hi, > > On Mon, 27 Sep 2010, Roland Mas wrote: >> >> What do you base this on? It does not at all seem clear to me that >> >> rolling would not introduce maintainers who only care about rolling. >> > >> > Nobody can predict the future... but my take is that the people who >> > only care about rolling would be the people who do not care of testing >> > right now already. Those who care about testing would continue to do >> > it. >> >> Without any hint as to how you came to that conclusion, this assertion >> can't be considered more than a gut feeling. > > I agree, but the same holds for Luk's assertion that the introduction of > rolling will hurt the process of creating a stable release. Yep. However, he's not the one asking us to change our ways, so I'd say the burden of proof (or at least of providing a reasoned position) is on your side. >> > - internal to say to all contributors that testing/rolling is meant to be >> > always usable so you must be careful in everything you upload to sid, no >> > matter whether we're far from release or not and RC bugs are always >> > important to fix, and you must care about migration to testing/rolling >> > because many users will want the latest version in that distribution >> >> This is not a change in communication, it's a change in policy, and a >> huge one too. Right after a release has always been a time for >> experimenting and introducing intrusive changes to unstable. Telling >> maintainers they now need to refrain from these changes is not something >> that can be decided lightly. Especially since imposing extra >> restrictions on the work one does on Debian is going to be one more >> reason for people not to care about Debian. We're supposed to make >> working on Debian *easier*, not add extra barriers. > > On a package-per-package basis, I don't think that anything changes. You > can do intrusive changes and have the package migrate only once you're > happy with your changes. > > On a large scale, there's no change either, all migrations have to be > coordinated already and breaking sid at your will has not been an option > for quite some time. So there's no change on any scale. What's the point again? > Really, I think the shift is in the communication, not on the practice. > It's just that we tell us officially that we have users of testing/rolling > and we wish to give them a pleasant experience. If we don't change the practice, then we can't suddenly tell users of testing that we officially support them. Because we currently don't. At least for some packages, it's hard enough ensuring a more-or-less pleasant experience in a stable release; trying to provide it on a moving target is *much* more work, especially if one must support upgrades from any version younger than X months (as has been suggested). This is not something that I can currently support, and it shouldn't be something that “we” can claim to support because that would be a lie. And if, as a maintainer, I'm told by whatever powers-that-be that I need to care for this use case from now on, I'm not likely to take that with a smile. >> Who's this “we”? That's an honest question: so far I haven't seen >> much support from the release managers, so I wonder who's going to do >> the work of creating the new suite, defining its package migration >> policy and implementing that into the appropriate code, or doing the >> actual migration by hand in the initial phase. > > Right now as far as rolling goes, there's me and Lucas > Nussbaum. Others have expressed interest in it too, including Stefano > Zacchiroli and Asheesh Laroia. For the snapshot side, so far Anthony > Towns and Joey Hess have been the most active in drafting the > implementation plan. Thanks. [...] > As far as buy-in from developers goes, yes it's needed in general. But > we do already have testing that is supposed to be in relatively good > state at any time and nobody has complained about this principle as > far as I know. So I'm not convinced we need anything else to be able > to advertise rolling as a testing-like distribution for end-users. Testing is in a relatively good shape because there's a set of people coordinating migrations and a known set of guidelines that people can agree with, mostly with the rationale that we're all working on preparing the next stable release and testing is the current tool for that goal. > What are your suggestions to ensure we have enough buy-in? The first o
Re: Summary of CUT discussions
Joey Hess, 2010-09-27 15:26:10 -0400 : > Roland Mas wrote: >> At least for some packages, it's hard enough ensuring a more-or-less >> pleasant experience in a stable release; trying to provide it on a >> moving target is *much* more work, especially if one must support >> upgrades from any version younger than X months (as has been >> suggested). This is not something that I can currently support, and >> it shouldn't be something that “we” can claim to support because that >> would be a lie. And if, as a maintainer, I'm told by whatever >> powers-that-be that I need to care for this use case from now on, I'm >> not likely to take that with a smile. > > Well, we know that fully 27% of popcon-reporting users already use > unstable or testing. So in general, developers already have an incentive > to keep unstable and testing usable for those users, not just stable. I'm fine with an incentive. An official promise by the project that unstable and testing (or rolling) *will* be usable, on the other hand, makes me really nervous. > There are always going to be special cases, like gforge/fusionforge, > which I assume is what you're specifically talking about. Good guess :-) > http://qa.debian.org/popcon-graph.php?packages=gforge-common+fusionforge-standard+fusionforge-minimal+fusionforge-full&show_vote=on&want_legend=on&want_ticks=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1 > If I'm reading this graph right, there are roughly no users of > fusionforge yet. Obviously it doesn't make sense for you to spend time > on unstable-to-unstable upgrades. > > I wouldn't be at all surprised if CUT ended up being mostly used for > desktop systems, and not for servers, since the desktop is exactly the > area where rolling releases with constant shiny stuff and new hardware > support is most needed. Certainly. And CUT is very probably going to be useful for them, just as testing can also be useful. However, from what I understand, CUT/rolling is going to be basically testing plus chromium (oversimplified). I'm completely fine with that, as it's just another suite that flows from unstable. The problem arises from what we, as a project, tell the world CUT is. If we want to call it “safe for many users” or “supported”, which is as far as I know its most important selling point, then we need to take out some packages. I don't know how many, but at least some; fusionforge is admittedly pathological, but I wouldn't be surprised about other applications that use a database and need to care about data migration. Wikis, webapps, ERPs, collection management stuff, that sort of thing. Do we need those in CUT? I don't know. But CUT suddenly becomes testing plus chromium minus a number of packages. If that still fits the goals of CUT, then by all means go ahead; I was just reacting to the stance that it's only a communication issue, because it clearly isn't. Roland. -- Roland Mas Neko-no me-to, onna-gokoro-to, aki-no-sora. -- Proverbe japonais (« Souvent femme varie, bien fol est qui s'y fie. ») -- 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/878w2n2bbq@mirexpress.internal.placard.fr.eu.org
Re: Summary of CUT discussions
Fernando Lemos, 2010-09-27 17:26:16 -0300 : [...] >> I'm fine with an incentive. An official promise by the project that >> unstable and testing (or rolling) *will* be usable, on the other hand, >> makes me really nervous. > > I recommend that you watch the BoF video, if you haven't already. Joey > explicitly states there that CUT will not be as stable as stable. You > can't obviously get the same stability as stable without all the > quality assurance and the freezes, not now at least. I just watched it. It seems to focus on the cuts/snapshots rather than on rolling, but I agree with the general goals, as long as we keep in mind and advertise the difference in expected quality — or in the set of available packages. And if I may join the bikeshedding, let me suggest we rename “testing” to “staging”, and stick with “rolling” for the new thing :-) Roland. -- Roland Mas Sauvez les castors, imprimez en recto-verso. -- 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/87d3ry1cyj@mirexpress.internal.placard.fr.eu.org
Re: Forwarding bugs upstream
Drake Wilson, 2011-01-11 20:19:34 -0700 : [...] > This doesn't leave much in the way of good options: > > - Having the user report bugs twice [...] > - Having the maintainer be the reporter of record for upstream [...] > - Having the maintainer forward the bug report but make the user the > reporter In a mid-term future, there's another possibility. Forges and bug trackers have started thinking about, and implementing, infrastructure to allow distributed bug tracking. There are at least two efforts in that direction: - the “SD” approach, where people have one local interface that talks to possibly several remote trackers and syncs stuff around; SD already has bridges to several engines. - the “OSLC-CM” approach, where trackers implement a common API allowing creation and manipulation of reports with a machine-to-machine interface; this allows a single interface (think dashboard) to display and interact with bugs independently of their physical location. If one or the other approach ends up generally usable, then a new scenario emerges: - end-user reports bug on the Debian BTS (or the Fedora Bugzilla, or the Ubuntu Launchpad, or whatever it is Suse has); - distro maintainer does some tagging if they consider the bug to be upstream; - upstream has a handful of accounts on the distros' BTS, and they see the appropriately tagged bugs on their dashboard; they can interact with the user from there, and possibly clone the bug into their own local BTS. We still face a scalability problem, in that upstreams may need an account on each of the (major) distributions' BTS that require logins, but in the end both upstream and the end user can work on the same report. Whether that report is only on the distro's BTS or synced with upstream's BTS is something that time will tell. For reference, the OSLC-CM API is currently being implemented for FusionForge, and I'm told Mantis already has it. I seem to recall work was in progress for Bugzilla too, but I don't remember the details. On the GUI client side, work is happening in Eclipse and probably others. Roland. -- Roland Mas Indépendant en informatique libre -- Free software freelance http://www.gnurandal.com/ -- 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/8739oywkdx@mirexpress.internal.placard.fr.eu.org
Re: HOWTO: Source a common shell script between DEBIAN/config and DEBIAN/preinst
harish badrinath, 2011-01-18 13:00:03 +0530 : > I want to source a common file between these two scripts You can't be sure that the common file is present on the system when config runs (since that may be before the package is unpacked). You can, however, maintain the common part as a separate file in your source package and inline it in both files of the generated binary. A very ugly implementation of this is in the fusionforge source package, using an ad-hoc tool I called DSF-Helper (short for "Debian SourceForge helper" -- that's how old it is). Roland. -- Roland Mas One... two... one, two, many, lots! -- Lias, in Soul music (Terry Pratchett) -- 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/87y66i1uln@mirexpress.internal.placard.fr.eu.org
Re: Quote: Debian and Democracy at Advocato.org
Thomas Hood, 2003-10-08 22:00:17 +0200 : > On Wed, 2003-10-08 at 21:25, Daniel Ruoso wrote: >> I think this should be clearly discussed. > > Just to prevent any confusion I'll just point out that > the rant you quoted was authored by Eray Ozkural. I'll add that since I posted [1], [2] and [3], I got exactly one email from Eray, [4] (the very day I posted [1]). I am not aware that anybody else in Debian has heard any news about fixed packages coming from him. I'll probably continue my monthly reports for a few months, unless people yell at me for wasting a few kilobytes of their bandwidth a month. I don't feel like creating an account and getting familiar with advogato just to post a reply (there's still nothing personal between Eray and myself), but if anyone with some status there wants to cut-and-paste my prose, feel free to. I'd appreciate if you sent me the link if you do :-) [1] http://lists.debian.org/debian-mentors/2003/debian-mentors-200307/msg00252.html [2] http://lists.debian.org/debian-mentors/2003/debian-mentors-200308/msg00263.html [3] http://lists.debian.org/debian-mentors/2003/debian-mentors-200309/msg00317.html [4] http://lists.debian.org/debian-mentors/2003/debian-mentors-200307/msg00264.html Roland. -- Roland Mas Death *was* hereditary. You got it from your ancestors. -- in Hogfather (Terry Pratchett)
Bug#220468: RFA: sourceforge -- Integrated development project framework
Package: wnpp Severity: normal I would like to deprecate sourceforge in favour of gforge. I believe gforge is ready to enter sarge (and it should have done so long ago were it not for problems in quite a lot of software depended upon). Gforge is an evolution of the free code that is sourceforge, it's much better maintained (both upstream and Debian-wise), it has far fewer bugs, lots of new features (including a plug-in system), and there's a smooth upgrade path from sourceforge. And it has diverged quite a lot from sourceforge, which makes backporting fixes harder and harder as time passes. If anyone is interested in adopting sourceforge, please step forward (and be warned that it's not necessarily an easy package to maintain). Otherwise, I'll probably orphan it and/or request its removal in some near future. Roland.
Re: perl 5.8.2-2 & mips buildd
Domenico Andreoli, 2003-11-19 11:30:17 +0100 : > i see that perl 5.8.2-2 is marked "Not-For-Us" on mips buildd. > > why it is in this state? it blocks the build of a lot of software. I'm currently building it by hand. Roland. -- Roland Mas Qu'est-ce qui est petit, jaune et vachement dangereux ? Un canari avec le mot de passe de root.
Re: Changes in formal naming for NetBSD porting effort(s)
On Sat, Dec 13, 2003 at 04:27:27PM -0500, Branden Robinson wrote: >> > Debian FreeBSD -> Debian Forneus (BSD) >> > Debian NetBSD -> Debian Naberius (BSD) >> > Debian OpenBSD -> Debian Orobos (BSD) On Sun, Dec 14, 2003 at 12:02:44PM -0500, Nathan Hawkins wrote: >> I'm not opposed to anything else you've said. I do believe these >> particular names are a bad idea, however. One of the reasons the BSD >> mascot is considered "cute" is that it has no real connection with >> demons, in name, or otherwise. Which to people of several religions are >> _not_ cute. Joel Baker, 2003-12-14 19:20:08 +0100 : > Feel free to propose alternatives from, say, the origional mythology which > spawned the concept of daemons as beings which were not inherently good or > evil, then. I'll suggest Offler (or Om), Foorgol (I don't like Fate) and, um, some other god coming out of Terry Pratchett's Discworld novels, preferably whose name starts with an N. Or something like that. Roland. -- Roland Mas Why did the elephant cross the road? Because it was the chicken's day off.
Re: Changes in formal naming for NetBSD porting effort(s)
Roland Mas, 2003-12-14 21:30:17 +0100 : [...] > I'll suggest Offler (or Om), Foorgol (I don't like Fate) and, um, > some other god coming out of Terry Pratchett's Discworld novels, > preferably whose name starts with an N. ...and then I found http://en.wikipedia.org/wiki/Nuggan (only appearing in books I haven't read yet, so I have an excuse). Roland. -- Roland Mas Plus on en fout, plus y'en a du riz. -- Proverbe chinois.
Pick a name, any name...
Hi all, As some of you probably know, some people are in the process of installing a Sourceforge site on a Debian machine. It will consist of a slightly patched version of the 2.6 branch of the Debian package "sourceforge", with a few scripts to help integration with existing infrastructure (existing accounts and groups should be preserved, for instance). The code is almost ready, the server itself should be OK soon (if not already), and Wichert and I even managed to find a time where both of us can be on the same IRC network at the same time. Now for the *real* important debate: how to call it? Current candidates include: - Loana: Stays in the line of the female names for Debian software, but it reminds French people of a very archetypic blonde in a French TV show of the like of Big Brother. It's a bit controversial on #Debian-devel-fr. - Actarus: Actarus is the pilot of Goldorak/Grendizer/what's it called in your language. No particular reason except that it was a very famous cartoon here in France some ten-fifteen years ago. Alcor is another name in that series. - Alioth: This one I really like. It's the capital system of the Alliance of Independent Systems in the Elite/Frontier/First Encounters video games. I initially thought about Achenar or Vequess, but they were not particularly adequate (they're respectively the capital system and the slave pit of the evil Empire). - Another idea I had was something along the lines of Debsmith or Iansmith, to keep both the idea of Debian and the idea of the forge. Unfortunately, plenty of people are called that way. Any idea to improve that line is welcome. Maybe just smith.debian.org would be enough (and I'll bet we can find a music composer named Smith if we look hard enough). - Various other ideas: ker (means "house" in Breton), gargamel (the sorcerer in the forest in the Smurfs comics), canard (Guillaume Morin really wants his nickname to be in that list, someone please kick him in the nuts or roast him -- means "duck" in French). - Your idea here. Now is the time to debate and argue. There's no guarantee we'll pick what the crowd wants, but good names will be considered :-) Roland. -- Roland Mas A lesson for you all: never fall in love during a total eclipse. -- Senex, in A Funny Thing Happened on the Way to the Forum
Re: Pick a name, any name...
Ben Armstrong (2002-11-28 11:14:50 -0400) : > On Thu, Nov 28, 2002 at 04:11:26PM +0100, Martin Michlmayr wrote: >> The machine itself has a name already (quantz). > > Oh, I retract my objection then. If the machine has a name already, > why bother naming the service something obscure? Service names > should be easy to remember. Think "non-us" or "security" vs. "satie", "people" vs. "gluck", etc. Roland. -- Roland Mas Two elephants fell off a cliff. Boom, boom.
Re: Accepted gtk2-engines-magicchicken 1.0.2-1 (i386 source)
Sebastian Henschel (2002-11-28 10:08:11 -0500) : >* Added an empty postinst to prevent dh_installdocs from deprecated > linking from /usr/doc to /usr/share/doc. That's an ugly hack. Please use DH_COMPAT=4 instead. Roland. -- Roland Mas Food, shelter, source code. -- Cyclic Software
Re: Pick a name, any name...
Ben Armstrong (2002-11-28 11:37:44 -0400) : > On Thu, Nov 28, 2002 at 04:34:45PM +0100, Roland Mas wrote: >> Ben Armstrong (2002-11-28 11:14:50 -0400) : >> > Oh, I retract my objection then. If the machine has a name already, >> > why bother naming the service something obscure? Service names >> > should be easy to remember. >> >> Think "non-us" or "security" vs. "satie", "people" vs. "gluck", etc. > > "non-us", "security" and "people" are obscure? :) No. But they document a function rather than a box. Oh, and by the way, it can't be quantz, since it won't have the same IP address. Unless someone comes up with a patch to make the sourceforge-web-apache package work with apache2 in the next three hours, of course :-) Roland. -- Roland Mas Bee There Orr Bee A Rectangular Thyng! -- in Soul Music (Terry Pratchett)
Re: Accepted gtk2-engines-magicchicken 1.0.2-1 (i386 source)
Colin Watson (2002-11-28 18:40:28 +) :
[...]
> You need Build-Depends{,-Indep}: debhelper (>= 4.1.0) for this, not
> a particular setting of DH_COMPAT.
Well, to be frank, I think you need both :-)
Roland.
--
Roland Mas
Why did the elephant cross the road?
Because it was the chicken's day off.
Re: private debian pools
Brian May (2002-12-07 16:36:58 +1100) : > I have a set of scripts for creating private debian package pools, > available at: Wonderful. We now have two tools providing almost the same functionality, except only one does package pools (bin2) and only one is mature (mini-dinstall, by Colin Walters). Could we possibly hope for a merger of those two? I'd very much like to have a pool-aware mini-dinstall... Roland. -- Roland Mas Sauvez une souris, mangez votre chat.
Re: stop abusing debconf already
Matt Ryan (2003-04-21 11:03:49 +0100) : > Again, if anyone knows of another client that supports both > requirements I'll give it a go. A good mail client that works on Windows, provides IMAP and obeys standard headers? I suggest Gnus. It does all that, and more. Roland. -- Roland Mas Sauvez les castors, plantez des arbres.
Re: experimental conffile merge for dpkg
Jarno Elonen (2003-04-27 14:16:02 +0300) : > If we can agree wether or not, how and where the original conffiles > should be saved, I'll be happy to implement 3-way merging to dpkg > and write imediff3 as a user friendly UI for it. Opinions? Unrelated to this diff thing, it's going to be a big help for people who inadvertantly remove conffiles and can't restore them (or even defaults) even with apt-get --reinstall install . There might be things to think about though: some packages have lots of conffiles, and that could mean some extra disk space, which not everyone will want to spend. Maybe make it optional. Roland. -- Roland Mas 'ALL your base? No!! One tiny base continue bravely to resist.' -- in #debian-devel
Re: pilot-link in Sid and Sarge: Much bigger question
Björn Stenberg (2003-04-27 21:17:04 +0200) : [...] > Actually, Debian has chosen Portability over Quality. Quality means > a lot more than just fixing bugs, you know. A program that does not > work with current data or devices has low quality even if it doesn't > crash. The mere age of most packages in stable is a very serious > quality flaw. [...] > How about improving Debian? Or is that heresy? To me, you seem to express the view that improving Debian means throwing away our release process, including the way testing works. This process has been thought about for a long time by lots of people, and carefully crafted to match some goals. I happen to believe the goals are worthy, and the process is adapted to these goals. I was only a prospective or recent developer when testing was brought to life, but I do not remember much opposition to it when it was designed, presented, discussed, then implemented. And it seems to me that the goals are correctly fulfilled by the process. From that, I infer that either 1. you disagree with the goals that the release process aims at fulfilling, 2. you disagree that the process is good at its job for structural reasons, or 3. you believe the process does not work as expected for other reasons. In case 1, I suggest you bring up a discussion on debian-project, so that the goals for the next release and the more general goals of releases (in terms of what it means to release a new stable distribution) can be discussed to death, and we eventually come up with maybe a different set of targets for the release process. In case 2, I suggest you express your concerns about how the release process is not adapted to what we want to achieve, and supply helpful ideas to make it better. In case 3, please help us identify the reasons why the process does not give the expected results. Also, please provide help to fix those problems. *Supposing* I were agreeing with you on the existence of a problem, I would probably be of the opinion classified as case 3 above. The reason I could identify for the problem would be that people prefer bitching and complaining about testing being late and stable being old, rather than helping fixing bugs. I agree with the goals. I believe the testing process is appropriate. The problem is not that this process requires software to be tested and declared relatively bug-free before they are admitted into testing. The problem is that the software is not even remotely bug-free. And it is so at least partly because people try to put new versions of software into Debian, which means the system integration and the synchronisation of programs and libraries are an uphill battle. And it is so at least partly because people complain as soon as there's a new upstream release, thus delaying the testing of the whole system. There's no such thing as a "known-good program". You have to have a known-good *system*. Taking the last known-good version of each part of the system, putting all that together and hoping the whole system will work is, to say the least, idealistic. Roland. -- Roland Mas Just a little bit of you every day will surely keep the doctors away. -- Just a little bit of you (The Jackson Five)
Re: Debian conference in the US?
Aaron M. Ucko (2003-05-20 13:25:47 -0400) : > Joe Drew <[EMAIL PROTECTED]> writes: > >> While convenient for american developers, there are rather a number >> of non-american developers who will not set foot on American soil, >> due in part to the DMCA and (I imagine) the apparent dangers to >> non-americans coming into the country. > > Two of the people I originally contacted said this too, but always > in the third person. I ask again, who on this list actually still > feels this way? I do. A combination of DMCA, a certain affinity towards cryptography, a certain dislike for some of the USA's behaviours (notably on the international scene), a particular dislike against dissimulating my opinions especially regarding the previous point, and a large "République Française" written on my passport, makes me feel I would not be very welcome in the USA. That's only my personal opinion though, and I'm in no way trying to turn anyone from organising a Debconf in the USA or attending it. Roland. -- Roland Mas Fate always wins... At least, when people stick to the rules. -- in Interesting Times (Terry Pratchett)
Re: alioth.debian.org down
Josip Rodin (2003-05-20 23:21:02 +0200) : > On Tue, May 20, 2003 at 08:06:17PM +0200, Raphael Hertzog wrote: [...] >> No because alioth has its own DNS delegation (in order to manage >> .alioth.debian.org). > > But why doesn't it have any slaves? That's a good question. The Sourceforge and Gforge packages include code to maintain a Bind zone file that includes the appropriate entries. There are two modes ow functioning: simplified mode (one wildcard entry), and realistic (one entry for each needed host, no more). Simplified mode allows the wildcard to be set up in the parent zone, realistic mode requires a zone delegation. In any case, nothing prevents the use of secondary servers, slaves, replication, call them what you like. In other words: no really good answer for your question. I'm afraid the best I can offer is "It doesn't have any slave yet.", but since I can't take the appropriate actions to make these slaves happen, that won't be of much help to you. Roland. -- Roland Mas Luck, like a Russian car, generally only works if you push it. -- Regalian, in My Hero (Tom Holt)
[Roland Mas ] ITP: elite-el -- A port of the Elite game to Emacs
Call me stupid, I forgot to Cc: the list. Here we go. Head for the stars... pgpEDjQ7TeBfr.pgp Description: PGP signature --- Begin Message --- Package: wnpp Version: N/A; reported 2001-04-25 Severity: wishlist I intend to package Elite for Emacs. The website is located at <http://members.fortunecity.com/salkosuo/elite-for-emacs/>, and has this to say: , | This is EMACS version of classic game Elite. As some may have guessed | I am a fan of Elite and also a follower of EMACS. So why not combine | these two... ` Oy yeah, license. Well, no license was included, so I contacted the upstream author about that and he agreed to add a COPYING file in the next release. Should be GPL. I'll package and upload when that new version is released. -- System Information Debian Release: testing/unstable Architecture: i386 Kernel: Linux cachemir 2.4.3 #1 Fri Apr 20 13:59:26 CEST 2001 i686 --- End Message --- -- Roland Mas C c ee lm re q j l a l l iè e . -- Signatures à collectionner, série n°1, partie 3/3.
Re: How to block spam (Re: SPAM:come on dream world..)
Michael Piefel (2001-05-02 15:58:27 +0200) : > Am 2.05.01 um 22:46:46 schrieb Tomohiro KUBOTA: > > Do you think inhibiting all non-ASCII (including ISO-8859-1 > > aka Latin-1) is too strict? > > Oops. That would block my mail because of my signature. I'd say let all > of Latin-* through, it will just cause a few `?' on the readers side. If we start filtering according to charsets (which I'm not really sure will provide any effectiveness against spam), I will oppose any scheme that filters out Unicode messages. It's hard enough getting people to switch to UTF-8, there's no need to provide them with an excuse to stay with their own charsets. Roland. -- Roland Mas Time is a drug. Too much of it kills you. -- in Small Gods (Terry Pratchett)
Re: Student Looking for A Final Year Project
Vince Mulhollon (2001-09-07 12:21:30 -0500) : > On 09/07/2001 11:20:42 AM Andrew Suffield wrote: > >>> But futile and misguided. CVS has whole swathes of fundamental flaws, >>> largely historical. Better to integrate with something similar to CVS > > References? Just curious what the huge problems are. It fundamentally > seems to work, or at least I've not yet run into any road blocks. On http://subversion.tigris.org/> you can read a list of features that make Subversion better than CVS, which points to weaknesses in CVS: - Directories, renames and meta-data are not really supported in CVS; - Symlinks are not either; - Repeated merges (when you work on branches) are a PITA. These are real-life problems of CVS, not just theoretical weaknesses. One lives with it (I've been doing so for years), but one dreams of a day when they are no more problems. Roland. -- Roland Mas Je suis un anti-virus de signature. Copiez-moi dans la vôtre pour éliminer les virus de signature !
Re: [RFC] Developer documentation packages.
David N. Welton (2001-09-13 14:30:54 +0200) : > Books are big. Something that pulls in a lot of them is likely to > be quite heavy. I think a package called 'books index' would make > more sense. This would provide an index to all the book packages > that are available in Debian, instructing the user on how to go > about downloading it. Does something like this make sense? So we'd have some sort of book-get package, like the controversial porn-get (which shares the characteristics you've described)? Roland. -- Roland Mas A lesson for you all: never fall in love during a total eclipse. -- Senex, in A Funny Thing Happened on the Way to the Forum
Re: EURO and CENT signs in the console keymaps
Bas Zoetekouw (2002-01-04 14:17:07 +0100) : > Hi Andreas! > > You wrote: [...] >> Also an emacs started with that env setting doesn't do anything on >> AltGr-e (without that setting, everything's OK: Â, see ;-)). > > Well, I get a little square here, but that's probably my own settings. Nope. I get it too, as I should: the message was declaring itself as encoded in ISO-8859-1, and that means the  is a  and not a â. Or, for you non-UTF-8-enabled people: that means the "international currency sign" is a "international currency sign" and not a "euro symbol". Roland. -- Roland Mas Plant a radish, get a radish, never any doubt! -- Bellamy & Hucklebee, in The Fantasticks
Re: Installed postgresql 7.1.3-6 (i386 all source)
Oliver Elphick (2002-01-05 20:53:08 +0100) : [...] > Closes: 12166 121666 121699 121712 121944 122167 122871 123349 123950 124317 > 125772 126193 126440 127004 127275 > Changes: > postgresql (7.1.3-6) unstable; urgency=low > . >* postgresql: fix postgresql-dump so that it doesn't crash out > unnecessarily if an unneeded file is missing. (Thanks to Thien-Thi > Nguyen <[EMAIL PROTECTED]>.) >* Build dependencies: changed python-dev to python2.1-dev; added > zlibg1-dev. > Closes: #12166, #126193 ^ I'm not quite sure this is what you meant there. Bug #12166 is related to fdutils, not postgresql. Just my tuppence, of course. Roland. -- Roland Mas Plus on en fout, plus y'en a du riz. -- Proverbe chinois.
Re: Refactoring the Debtags web interface
Enrico Zini, 2009-02-22 23:15:36 + : > But did I recall reading that Alioth, or debian.org, can be OpenID > providers? Not currently. Every once in a while somebody pops up and talks about implementing an OpenID provider plugin, but it hasn't appeared yet. If someone feels like going further, I (with my FusionForge upstream+maintainer and Alioth hats) would be happy to provide support, guidance and testing. Roland. -- Roland Mas Food, shelter, source code. -- Cyclic Software -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Debian has switched to FusionForge (was: "Debian is switching to EGLIBC")
Jon Dowland, 2009-05-07 11:51:43 +0100 : > I disagree, this would still warrant a post. Even if the impact is > insignificant, that is worth saying - "we're doing this, and there's > no reason to worry." I'll bite. The "gforge" package in Debian has been switched from GForge to FusionForge, which is the new name for the free (GPL) codebase. It's not exactly a fork since all the people who worked on that free codebase are now working on FusionForge, and there hasn't been *any* activity on the gforge.org SVN since we went away. There's no reason to worry, it's going to be a normal upgrade, and we've done these upgrades for years (including the database schema upgrading). We'll transition to packages named "fusionforge" in the near future, much as we transitioned from "sourceforge" to "gforge" way back then (for pretty much the same reason, even -- to go away from a name that becomes associated to proprietary software). Okay, so this is not glibc (which is about a thousand times more popular according to popcon), but it had to be said, I guess :-) Roland. -- Roland Mas If you spit in the air, it lands in your face. -- Tevye, in Fiddler on the roof -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
