Bug#208405: ITP: ldap-account-manager -- LDAP Account Manager (LAM) manages Unix and Samba accounts in a LDAP directory.
Package: wnpp Version: N/A; reported 2003-09-02 Severity: wishlist * Package name: ldap-account-manager Version : 0.3 Upstream Author : Roland Gruber <[EMAIL PROTECTED]> * URL : http://lam.sourceforge.net * License : GPL Description : LDAP Account Manager (LAM) manages Unix and Samba accounts in a LDAP directory. It runs on a webserver and is controlled via your browser. It supports the Samba 2.x and Samba 3 schema. There is also a script included which manages quota and homedirectories, you have to setup sudo if you want to use it. LAM can be accessed at http(s)://localhost/lam. -- System Information Debian Release: testing/unstable Architecture: i386 Kernel: Linux Roland 2.4.21 #2 SMP Die Jun 24 19:23:40 CEST 2003 i686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED]
Archive signature for sid broken?
Hello developers, is the signature for sid broken? When I do 'apt-get update', it complains about an invalid key, but that key mentions bullseye, not sid. A similar error shows for 'debootstrap sid sid' With kind regards, Roland Clobus --- Get:4 http://deb.debian.org/debian unstable InRelease [198 kB] Err:4 http://deb.debian.org/debian unstable InRelease The following signatures were invalid: BADSIG 0E98404D386FA1D9 Debian Archive Automatic Signing Key (11/bullseye) Reading package lists... Done W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://deb.debian.org/debian unstable InRelease: The following signatures were invalid: BADSIG 0E98404D386FA1D9 Debian Archive Automatic Signing Key (11/bullseye) W: Failed to fetch http://deb.debian.org/debian/dists/unstable/InRelease The following signatures were invalid: BADSIG 0E98404D386FA1D9 Debian Archive Automatic Signing Key (11/bullseye) W: Some index files failed to download. They have been ignored, or old ones used instead. --- OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Archive signature for sid broken?
Hello Jérémy, On 25/06/2024 13:00, Jérémy Lal wrote: Le mar. 25 juin 2024 à 10:11, Roland Clobus <mailto:rclo...@rclobus.nl>> a écrit : Hello developers, is the signature for sid broken? When I do 'apt-get update', it complains about an invalid key, but that key mentions bullseye, not sid. A similar error shows for 'debootstrap sid sid' If you use a apt-cacher-ng, it's https://bugs.debian.org/1003865 <https://bugs.debian.org/1003865> Thanks. I'm indeed using apt-cacher-ng, but I think I tried to run it without the proxy as well, but anyway... it works now. With kind regards, Roland -- For the record: I've done many things: * systemctl restart apt-cacher-ng.service * rm -fr /var/lib/apt/lists;mkdir -p var/lib/apt/lists/partial * I've removed from ../debrep/dists/sid the InRelease* and Release* files
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: svn.debian.org: Automatically putting log message into debian/changelog?
Hello Torsten, Torsten Landschoff wrote: > I wonder if it would be possible to write a script that automatically > updates debian/changelog each time somebody updates any files belonging > to the package. I can't stand writing stuff in debian/changelog and then > pasting it into the svn log message. I have thought about that before. However, I meant to implement it this way: Parse debian/changelog locally, and use new entries as default for Subversion's changelog. It would prevent debian/changelog to be cluttered with entries such as "forgot to add file foo last time; really add it now". (Yes, you could also clean debian/changelog up before uploading.) Roland -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Statically linked binaries from fpc
Hi, maintaining m-tx, I would like to move from the p2c generated C sources to the original upstream Pascal sources (better suited for patches, development, design, etc.). m-tx is written in a Turbo Pascal dialect that can only be compiled with fpc (not gpc). Unfortunately, fpc in Debian produces statically linked binaries, due to the Pascal unit style library files. We currently don't have other packages in the archive that Build-Depend on fp-compiler (except fpc itself which indeed carries statically linked binaries) as examples. Any suggestions? Should I just upload it that way? Thanks in advance! bye, Roland -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Re: Statically linked binaries from fpc
Hi Bill, > Hello Roland, I know nothing about fpc, but does it really need to > produce binaries statically linked with glibc ? I would expect to just > link statically with the units and dynamically with glibc. This would > be much less a problem. (In particular, if security bugs are found in > glibc). Exactly. Unfortunately, there doesn't seem to be a possibility to force fpc to link dynamically. Even "-XD" doesn't help. :( I will possibly just upload the new version of m-tx. Please CC my if there are any new ideas about this issue. Thanks. bye, Roland -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [marcov@stack.nl: (debian-devel related) FPC static/dynamic]
Hi Bill, On Fri, 2005-03-11 at 16:22 +0100, Bill Allombert wrote: > >Hello Roland, I know nothing about fpc, but does it really need to > >produce binaries statically linked with glibc ? > > It doesn't. Not all statically linked binaries are statically linked with > glibc. > > FPC is no GCC derivate, and uses syscalls directly, unless compiled with > FPC_USE_LIBC. All the standard pkg'ed static bins contain no libgcc/glibc > code. > > Keep in mind that non-gcc compilers (and non-C even) can't parse glibc > headers, so don't automatically adapt to minor changes. > > >I would expect to just > >link statically with the units and dynamically with glibc. This would > >be much less a problem. (In particular, if security bugs are found in > >glibc). > > Recompiling FPC with FPC_USE_LIBC defined will force the RTL to use libc, > however this is not advised. OK, then I will upload m-tx just statically linked (against syscalls). If someone has got a better idea, please contact me directly. Thanks! bye, Roland -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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: debian developer
On 3/10/06, Mark Walter <[EMAIL PROTECTED]> wrote: > Here is my question: > > Can anybody help to me to satisfy the demand for the two point's as I'am > interested to be a debian developer ? Ahh the the cool factor of having a Debian email address (not that i have one). > > What can I do to arrive the point's mentioned above ? > You could subscribe to debian-mentors and start crafting a package. Even though Debian has a impressiv amount of packages there are still some major ones left (mpich2, pvfs2, trac...). Also check this article: http://programming.newsforge.com/article.pl?sid=05/01/28/1618201 it has some extended info
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]
Bug#394460: ITP: xenman -- A graphical Xen management tool
Package: wnpp Severity: wishlist Owner: Roland Stigge <[EMAIL PROTECTED]> * Package name: xenman Version : 0.5 Upstream Author : Haphazard <[EMAIL PROTECTED]>, Jd <[EMAIL PROTECTED]>, Yves Perrenoud <[EMAIL PROTECTED]> * URL : http://xenman.sourceforge.net/ * License : GPL, LGPL Programming Lang: Python Description : A graphical Xen management tool XenMan is a Xen management tool with a GTK based graphical interface that allows for performing the standard set of domain operations (start, stop, pause, kill, shutdown, reboot, snapshot, etc...). It also attempts to simplify certain aspects such as the creation of domains, as well as making the consoles available directly within the tool's user interface. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-1-686 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8) -- 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: ITP: xenman -- A graphical Xen management tool
Hi, Roland Stigge wrote: > Package: wnpp > Severity: wishlist > Owner: Roland Stigge <[EMAIL PROTECTED]> > > * Package name: xenman > Version : 0.5 > Upstream Author : Haphazard <[EMAIL PROTECTED]>, Jd <[EMAIL PROTECTED]>, > Yves Perrenoud <[EMAIL PROTECTED]> > * URL : http://xenman.sourceforge.net/ > * License : GPL, LGPL > Programming Lang: Python > Description : A graphical Xen management tool > > XenMan is a Xen management tool with a GTK based graphical interface > that allows for performing the standard set of domain operations > (start, stop, pause, kill, shutdown, reboot, snapshot, etc...). It > also attempts to simplify certain aspects such as the creation of > domains, as well as making the consoles available directly within the > tool's user interface. > > -- System Information: > Debian Release: testing/unstable > APT prefers unstable > APT policy: (500, 'unstable'), (1, 'experimental') > Architecture: i386 (i686) > Shell: /bin/sh linked to /bin/bash > Kernel: Linux 2.6.18-1-686 > Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: > LC_ALL set to en_GB.UTF-8) Since this one turned out to be very popular at Debian's trade fair booth at SYSTEMS 2006, Munich, Germany, I decided to put it at http://people.debian.org/~stigge/packages/ for you, since NEW queue processing needs some time nowadays. bye, Roland -- 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]
FAQ (was: Bug#399153: xen-tools: Ubuntu Edgy - ttys not disabled by hooks)
Neil Wilson wrote: > What's an upstream issue? Consideration for next version or something? | | | | <-- xen-tools (Steve Kemp) | | | | ^ |T| | upstream |h| | |e| | | | |R| | flow |i| v |v| |e| | |r| | downstream | | v | | | | <-- Debian | | -- 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)
Dia 0.95-pre in experimental
Hi, I just uploaded dia 0.95-pre7 to experimental. This will go to unstable when the actual release happens (soon?). Feel free to test. Enjoy! bye, Roland -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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: strange behavior of dh_dhelp
Marco Budde <[EMAIL PROTECTED]> wrote: > Why? What is the advantage of using doc-base? You may want to read the documentation of doc-base... It is always a good idea to use a generic format which can automatically converted to all useful formats instead of using one special format. doc-base gives us the chance to add some other documentation system next to dwww and dhelp (both are horribly broken at the moment, so another one may be a good idea) without changing all the packages. If you think, that install-docs is too slow and dhelp-parse in combination with dhelp2dwww.pl is so much faster, why don't you simply rewrite install-docs in C? Then we have a generic and fast solution. > P.S.: The latest dhelp 0.3.14 supports FHS *and* FSSTND :). I just installed it, but as far as I can see this doesn't integrate FHS and FSSTND in any way but creates two completely incompatible trees one next to the other. Now I can read parts of the documentation as http://localhost/doc/ (which points to /usr/doc/) and others as http://localhost/fhs/ (which points to /usr/share/doc/). But I would prefer these two trees to be merged. This should be possible for most packages, because the tech-ctte decided that every package that uses /usr/share/doc/ has to create a symlink /usr/doc/ pointing to /usr/share/doc/. So all documentation should be available as /usr/doc/. The only problem is, that dhelp doesn't support those links at the moment. My packages which follow the tech-ctte decision (using debhelper and dh_installdocs) are only visible in http://localhost/fhs/HTML/ but not in http://localhost/doc/HTML/. In the past we had two places where the user had to look for documentation on programs: http://localhost/doc/HTML/ and http://localhost/dwww/menu.html You new version of dhelp splits this to three places: http://localhost/doc/HTML/, http://localhost/fhs/HTML/ and http://localhost/dwww/menu.html and all three include different doc, see for example section graphics: - Sketch User's Guide dhelp/FHS dwww - Sketch Developer's Guide dwww - Imlib Programmer's Guide dhelp/FHS dwww - XFIG User Manual dhelp/FHS dwww - TIFF Software dhelp/FSSTND - pstoedit dhelp/FSSTND Tscho Roland -- * [EMAIL PROTECTED] * http://www.spinnaker.de/ * PGP: 1024/DD08DD6D 2D E7 CC DE D5 8D 78 BE 3C A0 A4 F1 4B 09 CE AF
ITP: xcut
Source: xcut
Section: x11
Priority: optional
Maintainer: Roland Rosenfeld <[EMAIL PROTECTED]>
Standards-Version: 3.0.1
Package: xcut
Architecture: any
Depends: ${shlibs:Depends}
Description: Manipulate X cut buffers from command line
xcut is a small but useful program which can take standard input and
store it in the X cut buffer, and also work in reverse by writing the
X cut buffer onto standard output.
There is a homepage of this program at
http://acsys.anu.edu.au/~tpot/xcut/, it is under GPL.
Ciao
Roland
--
* [EMAIL PROTECTED] * http://www.spinnaker.de/ *
PGP: 1024/DD08DD6D 2D E7 CC DE D5 8D 78 BE 3C A0 A4 F1 4B 09 CE AF
Re: strange behavior of dh_dhelp
On Mon, 27 Sep 1999, Peter S Galbraith wrote: > > > P.S.: The latest dhelp 0.3.14 supports FHS *and* FSSTND :). > > I just installed it, but as far as I can see this doesn't > > integrate FHS and FSSTND in any way but creates two completely > > incompatible trees one next to the other. Now I can read parts of > > the documentation as http://localhost/doc/ (which points to > > /usr/doc/) and others as http://localhost/fhs/ (which points to > > /usr/share/doc/). > I have a recent potato install and dhelp 0.3.14 and _don't_ have > http://localhost/fhs/ support. Simply add Alias /fhs/ /usr/share/doc/ to /etc/apache/srm.conf and you will have it. I added this line by hand, too. Yes, I know that this isn't an elegant solution, but it seems to be the only way to access both directories. There were some rumors, that Apache would be able to handle both directories as http://localhost/doc/ (use /usr/share/doc/ and if the file/directory isn't available fall back to /usr/doc/), but I don't know enough about Apache to realize this myself and I didn't see an example how to do this, so it seems to be only a rumor but not reality :-( > Am I doing anything wrong? That's what I also am asking myself when I see dhelp, but I fear, that dhelp is simply broken and that's the secret behind all these problems. > [I also agree that it would be annoying to have two distint > directories to point a browser at (if it worked at all for me).] That's why we should simply follow the tech-ctte and make all documentation available as /usr/doc/ where /usr/doc/ may be a symlink to /usr/share/doc/. But dhelp doesn't support these symlinks at the moment, as far as I can see. Ciao Roland -- * [EMAIL PROTECTED] * http://www.spinnaker.de/ * PGP: 1024/DD08DD6D 2D E7 CC DE D5 8D 78 BE 3C A0 A4 F1 4B 09 CE AF
Re: strange behavior of dh_dhelp
On Mon, 27 Sep 1999, Peter S Galbraith wrote:
> > There were some rumors, that Apache would be able to handle both
> > directories as http://localhost/doc/ (use /usr/share/doc/ and
> > if the file/directory isn't available fall back to
> > /usr/doc/), but I don't know enough about Apache to realize
> > this myself and I didn't see an example how to do this, so it
> > seems to be only a rumor but not reality :-(
> Have you tried the mod_rewrite solution posted late in July?
It seems that I missed this. But I found it in the archive and it
works really great now. Maybe others have the same problem, so here's
the solution again (with /usr/doc as the primary directory and
/usr/share/doc the secondary, which I prefer):
In httpd.conf:
LoadModule rewrite_module /usr/lib/apache/1.3/mod_rewrite.so
In srm.conf:
RewriteEngine on
# For requested files beginning with /doc/, try looking for the
# document in /usr/doc.
RewriteCond %{REQUEST_FILENAME} ^/doc/
RewriteCond /usr%{REQUEST_FILENAME} -f [OR]
RewriteCond /usr%{REQUEST_FILENAME} -d [OR]
RewriteCond /usr%{REQUEST_FILENAME} -l
RewriteRule ^(.+) /usr$1 [L]
# Next, try looking for the document in /usr/share/doc.
RewriteCond %{REQUEST_FILENAME} ^/doc/
RewriteCond /usr/share%{REQUEST_FILENAME} -f [OR]
RewriteCond /usr/share%{REQUEST_FILENAME} -d [OR]
RewriteCond /usr/share%{REQUEST_FILENAME} -l
RewriteRule ^(.+) /usr/share$1 [L]
# Attempt to deal with directory listings.
RewriteCond %{REQUEST_FILENAME} ^/doc/?$
# Just list /usr/doc for now.
RewriteRule ^(.+) /usr/doc/ [L]
# Neither worked. Just pass through to do whatever we would have
# done before.
RewriteRule ^(.+) - [PT]
# mod_rewrite isn't available, so fallback to a simple Alias.
Alias /doc/ /usr/doc/
Maybe this should be added to the defaults of apacheconfig
(/usr/share/doc/apache/examples/*)?
Ciao
Roland
--
* [EMAIL PROTECTED] * http://www.spinnaker.de/ *
PGP: 1024/DD08DD6D 2D E7 CC DE D5 8D 78 BE 3C A0 A4 F1 4B 09 CE AF
Re: strange behavior of dh_dhelp
nd deleted by postinst and prerm, because otherwise dpkg will have problems with this. We are all waiting for the new policy, which will realize this decision. Maybe you noticed, that newer versions of debhelper and lintian already support this way to handle this. > RR> package that uses /usr/share/doc/ has to create a symlink > RR> /usr/doc/ pointing to /usr/share/doc/. So all > RR> documentation should be available as /usr/doc/. > No. A http daemon will never follow this symlinks. They#re 100% useless > when using the http protocol. That's not true. At least apache supports following symlinks when you activate this with "Options FollowSymLinks" in access.conf for the /usr/doc directory. Other web servers will support this in a similar way. > RR> In the past we had two places where the user had to look for > RR> documentation on programs: http://localhost/doc/HTML/ and > RR> http://localhost/dwww/menu.html > ??? You only need one of this systems. Both systems have advantages and disadvantages and many packages support only one of these systems. For me (personally) this means, that both systems are quite unusable, so I directly access the documentation files without using dhelp/dwww. But if you want to access all package documentation, you will have to use both systems. Tscho Roland -- * [EMAIL PROTECTED] * http://www.spinnaker.de/ * PGP: 1024/DD08DD6D 2D E7 CC DE D5 8D 78 BE 3C A0 A4 F1 4B 09 CE AF
Re: strange behavior of dh_dhelp
n the far > RR> future, but now we are working on potato). > Great and the next Debian release will have the same or even more > problems. No. See the complete proposal in http://www.debian.org/Lists-Archives/debian-ctte-9908/msg00038.html: 1. Policy 3.X mandates that packages that move the docs to /usr/share/doc must provide a compatibility symlink in /usr/doc. This shall allow packages to incrementally move to policy 3.X, while providing compatibility with older systems. (/usr/doc/package symlink is handled by package) Thus, potato ships with a full /usr/doc/ (some of which is symlinks), and a partial /usr/share/doc. 2. Post potato, we continue the transition, with the symlinks in place. Before freeze, we file important bugs against any package that has not been moved over (in one and a half release periods, we may be actually able to accomplish this), with NMU-fests to bring over the others. Thus, potato+1 (woody) ships with a full /usr/share/doc, and a /usr/doc full of symlinks. 3. At a later date, another policy (say, 4.X) shall ask for packages to no longer provide the link (and possibly remove links from /usr/doc). We can also provide a script (possibly in base-files postinst) that rm's symlinks from within /usr/doc. woody+1 may ship with such a script. (there was a proposal as well that potato+2 (woody+1) ships with just the prerms, and not the base file script, and potato+3 ships with the base-file script, but I am not sure this long a reversion period is required). No dependency on this base-files shall be required, since they shall work with or without a symlink in /usr/doc (and /usr/share/doc shall be fully populated by then). > I don#t like such hacks. Nobody really likes them, but they are the only way to realize a smooth transition. One of Debians primary goodies is, that you can upgrade every single package without problems as long as you follow the dependencies. So many people only upgrade some packages but not all at the same time (and don't forget, that it is nearly impossible to rebuild all packages with /usr/share/doc before potato is released) and this shouldn't break the systems. So a hack like the above is the smallest evil. > In fact I don#t understand why we should not simply move our > documentation to the new directory. Because this breaks consistency of the systems, which have documentation distributed over two directories. As you can see at the actual situation with dhelp, this is really annoying. But please stop this discussion, we had it for many weeks in debian-policy other mailing lists without a compromise. So the technical committee was asked to find a decision and they did so. It doesn't help Debian if you start this discussion again or if you try to change it by simply ignoring it. > RR> That's not true. At least apache supports following symlinks > RR> when you activate this with "Options FollowSymLinks" in > RR> access.conf for the /usr/doc directory. Other web servers will > RR> support this in a similar way. > Will apache follow symlinks in /usr/doc or symlinks to all possible > files? As far as I see, the latter. > Using this feature could course real security problems. But it is the default configuration of apache in slink and also in poato. BTW: The real problem is, that the documentation is automatically accessible world-wide and not only to local users. It isn't optimal that everybody can see what packages are installed here and in which version. > And of course there#re other http daemons than apache. There are also http daemons which don't support CGI. But you still provide /usr/lib/cgi-bin/dsearch in the dhelp package. This isn't a real argument. If someone uses a http server which doesn't support symlinks, he's free to switch over to apache, if he wants to read the documentation via HTTP. Tscho Roland -- * [EMAIL PROTECTED] * http://www.spinnaker.de/ * PGP: 1024/DD08DD6D 2D E7 CC DE D5 8D 78 BE 3C A0 A4 F1 4B 09 CE AF
Re: strange behavior of dh_dhelp
On Wed, 29 Sep 1999, Daniel Burrows wrote: > > > This may work sometimes but not always -> hack. > > ctte decided, that this has always to work. If it doesn't, this > > is a bug in the package. > I assume that I can't start filing bugs against the ~116 packages > on my system (eg, libc6) that moved to /usr/share/doc without > leaving a symlink behind until this becomes part of policy. Any > idea how long that'll be? No idea. But have a look at http://www.debian.org/Bugs/db/45/45561.html, there is consensus about the change, it seems that it only has to be formulated and uploaded. I just filed a proposal for the text. Ciao Roland -- * [EMAIL PROTECTED] * http://www.spinnaker.de/ * PGP: 1024/DD08DD6D 2D E7 CC DE D5 8D 78 BE 3C A0 A4 F1 4B 09 CE AF
Re: strange behavior of dh_dhelp
On Wed, 29 Sep 1999, Peter S Galbraith wrote: > Your example implies that doc-base's install-docs is at fault for > creating files under either /usr/doc/HTML or /usr/share/doc/HTML > instead of files in a single place, with a /usr/doc/HTML -> > /usr/share/doc/HTML symlink. Am I correct? Or did I miss something? As far as I see, you are talking about the dhelp support in doc-base. This is done in two steps: 1. convert the doc-base file to a .dhelp file. While the doc-base file uses a full path, the .dhelp file doesn't include a path. 2. add the documentation defined in the .dhelp file to the indexes in HTML using dhelp_parse. It shouldn't be a big problem, to add such a .dhelp file to the /usr/doc/HTML index, but dhelp doesn't support this at the moment, when called with /usr/share/doc//.dhelp. Another problem in combination with this is, that dhelp_parse scans all directories under /usr/share/doc (dhelp_parse_fsstnd does the same for /usr/doc), but both programs don't follow symlinks, which is a problem, because symlinks from /usr/doc/ to /usr/share/doc/ should be followed... > In that case, shouldn't the bug go against doc-base? The problem is somewhere between doc-base and dhelp, but both authors doesn't seem to have much interest in solving it... Ciao Roland -- * [EMAIL PROTECTED] * http://www.spinnaker.de/ * PGP: 1024/DD08DD6D 2D E7 CC DE D5 8D 78 BE 3C A0 A4 F1 4B 09 CE AF
Re: strange behavior of dh_dhelp
Marco Budde <[EMAIL PROTECTED]> wrote: > Ok, then Debian 2.2 will be broken. No. There are not many packages which quickly switched to /usr/share/doc without the symlinks. The maintainers of these packages quickly changed, so they are alive and the should be able to add the symlink to their next versions of the packages as quickly as they uploaded before. So why should 2.2 be broken? Potato _is_ broken at the moment, but this can be fixed. > And the next releases will have the same problems, because we still > allow policy 2.4 packages without any symlinks. The next (potato+1) requires all documentation in /usr/share/doc _and_ Symlinks in /usr/doc. > So it won#t be possible to install Debian 2.2 and 2.3 packages on > one system with a working documentation. So there is no problem with 2.2+2.3. Then 2.4 will remove the symlinks but now all packages from 2.3 placed their docs in /usr/share/doc, so you can use packages from 2.3+2.4 together with all docs in /usr/share/docs. > Wrong. Symlinks don#t work with http. What does the HTTP protocol have to do with the Unix file system? It depends on the HTTP server, whether it follows symlinks or not. Apache handles this without problems for ages and FollowSymlinks is activated in the default configuration for /usr/doc. I think that other HTTP servers will do the same, and if one doesn't do so, it's more likely that they support to follow symlinks instead of _not_ to follow symlinks. BTW: I think that it is a bug, if an HTTP server isn't configurable in this case. And don't forget that we already have many symlinks in /usr/doc for ages, which are explicitly allowed by policy: /usr/share/doc/ may be a symbolic link to a directory in /usr/share/doc only if two packages both come from the same source and the first package has a "Depends" relationship on the second. These rules are important because copyrights must be extractable by mechanical means. > If you ask me: > (1) All packages of Debian 2.2 must use /usr/share/doc. Then the release date of 2.2 will be at the end of 2000 or later. That's simply unrealistic. If you personally want to upload 2000 NMUs (for each architecture!), this may be able sooner, but > Otherwise we will have the same problems in Debian 2.3, when > the user reads the documentation via /usr/share/doc. No. Read the time table above or in one of my last mails. > (2) All packages provides /usr/doc links. That's right for 2.2 and 2.3. > (3) http://localhost/doc/ points to /usr/share/doc, the user > use /usr/share/doc instead of /usr/doc. That's wrong. http://localhost/doc/ points to /usr/doc in 2.2 and 2.3. This will change in 2.4. > This is a clean solution It is clean if all Debian maintainers update all their packages in all architectures and if every user upgrades the complete system from 2.1 to 2.2 and not only parts. If you cannot be sure that these requirements are resolved, it is not clean. > and not such a hack like the descripted decision. Yes, the decision is a hack. But it works and offers a smooth transition. We have to release potato soon (slink is very old and our users want a new release, otherwise the may use a different distribution) and potato should be as consistent as possible. The hack gives us a consistent potato (all doc available via /usr/doc), your proposal does not. Anyway, the decision was made, like it or hate it but stop discussing it again and again. This doesn't help and won't change anything. Tscho Roland -- * [EMAIL PROTECTED] * http://www.spinnaker.de/ * PGP: 1024/DD08DD6D 2D E7 CC DE D5 8D 78 BE 3C A0 A4 F1 4B 09 CE AF
Re: New LILO for >1024 cylinders in potato, PLEASE!
On Fri, Mar 10, 2000 at 02:31:56PM -0800, Erik wrote: > I think this should go in, but should have extensive testing first, in a short > time if possible. Yes, I think so, too. I just install lilo 21.3 here (that's the version number) and it works fine. Roland -- Roland Bauerschmidt -- Freiberger Str. 17, 28215 Bremen, Germany e-mail: [EMAIL PROTECTED], phone: +49 421 3763482, fax: +49 421 3763483 Debian GNU / Linux -- the choice of a GNU generation
Re: Becoming a developer
On Tue, Mar 14, 2000 at 10:31:58AM -0800, Kenneth Scharf wrote: > (does KDE yet use Qt2, which is the new QT license?), No, it doesn't in 1.x. KDE 2.x will be linked against QT2. > Is there a way to search the archives on debian-legal > for QT? Maybe some of my questions will have answers I think there is a search function for the mailling list archive on va.debian.org, isn't there? > there (If one can wade through the flames). Is there > a way (via license modification disclaimers) that a > program written using QT can be GPL'ed at all? Yes, there is. Look at apt. It's GPL, but other programs using QT (like the Corel(R) Package Manager) may be linked against it. You've to include a paragraph that says that this is allowed. > Finally I note that debian DOES have the QTLib in the > distro, will this remain (allowing users to at least > use such programs via source)? Why not? If I understood it right, KDE isn't included because of an invalid license (GPL-programs linked against QT). QT has a valid license. There are a lot of other non-free packages in Debian, too. For which reason should qt not be included? Greetings, Roland -- Roland Bauerschmidt -- Freiberger Str. 17, 28215 Bremen, Germany e-mail: [EMAIL PROTECTED], phone: +49 421 3763482, fax: +49 421 3763483 Debian GNU / Linux -- the choice of a GNU generation
Re: aptitude
On Mon, Mar 13, 2000 at 02:23:12PM +0900, Julian Stoev wrote: > I personally don't like the Stormpkg thing. Maybe I am broken by > dselect ;) I included slink ftp in apt and got many nice programs, > which are not part of Stormix using dselect. No problem at all. But > Stormpkg may be better for somebody who starts now with Linux? I didn't work much with the Storm Package Frontend, but it seemed to me as if it was very very close to dselect, only graphically. I think it's nice for new users. > I think Stormix distribution should be applaused very much! This is very > good way to promote Debian to the public. I think so, too. The people are really friendly and want their distribution to be as much compatible to official Debian as possible. At CeBIT fair in Germany, they gave half of their booth to us. > the main Debian page. Maybe for first time Linux users this *is* a better > way to install Debian?... And why not help them to get working install CD Definitely. The installation program is not that powerful, but it's very comfortable and easy to use for beginners. The current boot disks are good for experienced users, but most Linux beginners will go away and install another distribution because all of the main other distributions have nice easy-to-use graphical installation now. Greetings, Roland -- Roland Bauerschmidt -- Freiberger Str. 17, 28215 Bremen, Germany e-mail: [EMAIL PROTECTED], phone: +49 421 3763482, fax: +49 421 3763483 Debian GNU / Linux -- the choice of a GNU generation
Re: RFP: galeon
On Tue, Aug 29, 2000 at 08:30:39PM -0500, Roland Bauerschmidt wrote: > Package: wnpp > Severity: wishlist Sorry, /me is a fool. I should have looked in the bug database before reporting this. :-/ Nevertheless I've made a galeon package which should work ok. You can find them under http://www.debian.org/~rb/galeon/ . Unfortunately I don't think I have enough time to maintain it at the moment. So I would be pleased if somebody else would volunteer to maintain it. As I said before I'd be happy to sponsor uploads for it. Regards, Roland -- Roland Bauerschmidt <[EMAIL PROTECTED]>
Re: Rfp: galeon
On Wed, Aug 30, 2000 at 06:59:25PM +0200, Daniele Cruciani wrote: > I've read on this list about ITP of galeon (web browser), but > i don't remenber who announce ITP and I can't find that package on > experimental. I have made a package which can be found uder http://www.debian.org/~rb/galeon/, but unfortunately I think that I don't have the time to maintain it at the moment. I would be glad if somebody would do this. Roland -- Roland Bauerschmidt <[EMAIL PROTECTED]>
Re: RFP: galeon
On Wed, Aug 30, 2000 at 09:26:06PM +0200, Hilko Bengen wrote: > I would like to take it, however, I am not a developer, yet, so you'd > have to sponsor it. Sure. If nobody else object it's yours. Just send me the package if you are done with first packaging. Roland -- Roland Bauerschmidt <[EMAIL PROTECTED]>
Re: Rfp: galeon
On Wed, Aug 30, 2000 at 10:43:01PM +0300, Eray Ozkural wrote: > orion:exa$ galeon > /usr/bin/galeon-bin: error in loading shared libraries: libgtkembedmoz.so: > cannot open > shared object file: No such file or directory > > What's happening? Where's this library? How could I install the package > if this is a dependency? Opps. Mozilla was forgotton in the dependencies... ;-) Roland -- Roland Bauerschmidt <[EMAIL PROTECTED]>
Re: multiple dependancies on the same package?
On Fri, Sep 01, 2000 at 01:59:00PM -0400, Richard A Nelson wrote: > Would the following work as expected: > Depends: sendmail (>= 8.9.3), sendmail (<< 8.9.4) libapache-mod-ssl does it: Package: libapache-mod-ssl Version: 2.6.4-1.3.12-1 Priority: optional Section: non-US Maintainer: Miquel van Smoorenburg <[EMAIL PROTECTED]> Depends: libc6 (>= 2.1.2), libdb2 (>= 1:2.4.14-7), libssl09, openssl, apache (>= 1.3.12-1) | apache-perl (>= 1.3.12-1), apache (<= 1.3.12-99) | apache-perl (<= 1.3.12-99), make Suggests: libapache-mod-ssl-doc Architecture: i386 Filename: dists/unstable/non-US/main/binary-i386/libapache-mod-ssl_2.6.4-1.3.12-1.deb Size: 228730 MD5sum: bb7b536e6fde97253a6a5a5c0df33bed Description: Strong cryptography for Apache This Apache module provides strong cryptography for the Apache 1.3 webserver via the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols. . [...] Roland -- Roland Bauerschmidt <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Security of Debian SuX0r?
On Wed, Aug 30, 2000 at 02:57:20PM +0300, Juhapekka Tolvanen wrote: > Kurt Seifried While we are at it. Kurt critizes that adduser creates home directories readable for all users by default. The woody version has an option in /etc/adduser.conf to change it to any value you want. Shall we make something like 700 default? It would break some things like "UserDir public_html" in Apache, etc. In my school server I put all public stuff on some other location and create symlinks in the home-directories and use "UserDir /foo/bar/*/public_html" which works absolutely perfect. Any comments? Roland -- Roland Bauerschmidt <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Security of Debian SuX0r?
On Fri, Sep 01, 2000 at 06:21:51PM -0500, Joseph Carter wrote: > 751 seems more reasonable IMO. This sounds also reasonable for me. And because of the x-bit UserDirs, etc. should work. Does anyone objects if I change this with the next upload of adduser? Consider that this is only the default behaviour, if you still want 755 home-directories you just have to change the value in /etc/adduser.conf. Roland -- Roland Bauerschmidt <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: My recent bug's and continuing effort to debconf-ize Debian
On Fri, Sep 01, 2000 at 12:45:07PM -0700, Joey Hess wrote: > Debconf is already in standard. Three packages of > standard priority > use debconf (console-tools, console-data, setserial). All are priority > required. What is with lynx? Lynx is standard and _depends_ on debconf. I would also appreciate to increase debconf's importance. Package: lynx Version: 2.8.3-1 Priority: standard Section: web Maintainer: Christian Hudon <[EMAIL PROTECTED]> Depends: libc6 (>= 2.1.2), libz1, slang1 (>> 1.3.0-0), debconf Recommends: mime-support Provides: www-browser, news-reader Architecture: i386 Filename: dists/unstable/main/binary-i386/web/lynx_2.8.3-1.deb Size: 972618 MD5sum: e2916eee86441c85adc8bea3db74a8cc Description: Text-mode WWW Browser Lynx is a fully-featured World Wide Web (WWW) client for users running cursor-addressable, character-cell display devices (e.g., vt100 terminals, vt100 emulators running on PCs or Macs, or any other "curses-oriented" display). It will display hypertext markup language (HTML) documents containing links to files residing on the local system, as well as files residing on remote systems running Gopher, HTTP, FTP, WAIS, and NNTP servers. -- Roland Bauerschmidt <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: My recent bug's and continuing effort to debconf-ize Debian
On Fri, Sep 01, 2000 at 07:10:30PM -0700, Joey Hess wrote: > As I said above, debconf is in standard. Sorry. I didn't know that. Dpkg and apt-cache still claim that it is in optional: [EMAIL PROTECTED]:~% apt-cache show debconf | grep \^Priority: Priority: optional [EMAIL PROTECTED]:~% dpkg -p debconf | grep \^Priority: Priority: optional [EMAIL PROTECTED]:~% dpkg-deb -I /var/cache/apt/archives/debconf_0.3.66_i386.deb | grep Priority: Priority: standard Never mind, Roland -- Roland Bauerschmidt <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: No german umlauts in console and xterm
Florian Hinzmann <[EMAIL PROTECTED]> wrote: > I tried to fix an old problem with my Debian system (woody) > today, but failed. An old problem with a quite old answer: German-HOWTO You'll find this in doc-linux-text and doc-linux-html packages. Tschoeeee Roland -- * [EMAIL PROTECTED] * http://www.spinnaker.de/ * -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: build question
On Mon, Sep 04, 2000 at 07:19:11PM +, michael d. ivey wrote: > my main server is potato. is it "bad" for me to be building packages > there if they are destined for woody? should i start building on a > woody box? You could do source only uploads. Roland -- Roland Bauerschmidt <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Best way to depend on an xserver but conflict with XF86 v4 ?
On Tue, Sep 12, 2000 at 01:41:19PM +0200, Wichert Akkerman wrote: > > Depends: xserver(<<4.0) [...] > What should work with dpkg 1.7.0 once that is ready if someone makes > xserver a versioned provide. I don't think that this would be a good idea, because there may be other xservers than XFree. Roland -- Roland Bauerschmidt <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: finishing up the /usr/share/doc transition
Joey Hess wrote: > There are a total of 645 packages that have not been converted[2]. There > are 16 weeks between December 31st and Aj's projected freeze date for woody. > If 40 people could do one package a week, we would be done. Or 20 people > doing two a week, or just 6 people doing one a day. In other words, it > seems acheivable, especially if we file bugs now on the undone packages, > which would probably wake a fair number of maintainers up.. I'd be glad to help. How should we proceed? Should we send patches to the appropiate maintainers or directly upload the NMUs? Honestly, they had enough time to tranist to /usr/share/doc. Roland -- Roland Bauerschmidt <[EMAIL PROTECTED]>
Re: finishing up the /usr/share/doc transition
On Fri, Dec 22, 2000 at 01:04:26PM -0800, Joey Hess wrote: > base/update I uploaded a NMU for this already. Roland -- Roland Bauerschmidt <[EMAIL PROTECTED]>
Bug#79950: updating to potato from Linux2.0.34( i believe it was hamm)
On Wed, Dec 20, 2000 at 06:21:39AM -0500, basic wrote: > subprocess dpkg-deb --fsys-tarfile returned error exit status 2 Is your RAM ok? How much RAM do you have? Do you have a swap partition? Roland -- Roland Bauerschmidt <[EMAIL PROTECTED]>
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: test -d /usr/man && mail submit@bugs
On Thu, Dec 28, 2000 at 09:13:32AM -0500, Chad Miller wrote:
> $ find /usr/man -exec dpkg -S {} \; |cut -d: -f1 |grep -v , |sort |uniq
Just parse a Contents-ARCH.gz file to find all packages that still have
/usr/man.
Roland
--
Roland Bauerschmidt <[EMAIL PROTECTED]>
Re: dpkg-statoverride vs. suidmanager
Wichert Akkerman wrote: > > dh_suidregister to have a versioned conflicts, but I guess that's my > > problem, not your problem. :-) > > Automatic adding of a versioned conflict.. I'm suddenly extra glad none > of my packages use debhelper. I think debhelper should just check for the versioned conflicts and warm, maybe refuse to build, but not edit that file automatically. I don't know debhelper very well, but couldn't it go in dh_suidregister? Roland -- Roland Bauerschmidt <[EMAIL PROTECTED]>
Re: tar -I incompatibility
Goswin Brederlow wrote: > the Author of tar changed the --bzip option again. This time its even > worse than the last time, since -I is still a valid option but with a > totally different meaning. > > This totally changes the behaviour of tar and I would consider that a > critical bug, since backup software does break horribly with the new > semantic. Yes, I think that this should definetely be changed back. The first time I encountered this problem, I thought that the tar.bz2 archive was broken from the error message tar reported. (Not a valid tar archive or so.) This change is confusing and unreasonable IMHO. Roland -- Roland Bauerschmidt <[EMAIL PROTECTED]>
Re: Need server
Bart Schuller wrote: > download.sourceforge.net Funny: [EMAIL PROTECTED]:~% host ftp.debian.org ftp.debian.org A 64.28.67.101 [EMAIL PROTECTED]:~% host download.sourceforge.net download.sourceforge.netA 64.28.67.101 Roland -- Roland Bauerschmidt <[EMAIL PROTECTED]>
Re: tar -I incompatibility
Scott Ellis wrote: > Of course the -I option to tar was completely non-standard. The changelog > explains why it changed, to be consistant with Solaris tar. I'd prefer > portability and consistancy any day, it shouldn't take that long to change > any custom scripts you have. I always use long options for nonstandard > commands when building scripts anyway :) Well, ok, I didn't know about Solaris tar. Probably, they are right then, but nevertheless, it is a pain. Maybe there should be a debconf text message, priority low, that informs the user about it if Debconf is installed? Roland -- Roland Bauerschmidt <[EMAIL PROTECTED]>
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: Bug#81396: root shell fscked after upgrade to woody
Eray Ozkural wrote: > About having telnet enabled: everybody on the campus knows how to use telnet > but would be very surprised I didn't let them connect easily from windows > clients. For me, using telnet is of course a bit insecure but when I'm > not able to use an ssh client... it's easier. Well, what I did in school before I could convice them that we needed some Debian boxes, was using one of those free Java-SSH clients with one of the proprietary Java-capable browsers that were installed on the machines... Roland -- Roland Bauerschmidt <[EMAIL PROTECTED]>
Re: News about Debian Conference... and have an happy new year !
Bruce Perens wrote: > For the Debian part of the meeting, I could say something about use of > Debian inside of HP, especially how it was used for the PA-RISC and ia64 > ports. Speaking of IA-64: Do we have a machine yet? AFAIK not. Do you think HP would be willing to make one availible to Debian? Btw, you tried to reply directly to -devel-announce. See your message header: > X-Debian-Message: Cannot post to debian-devel-announce, bounced to > debian-devel Roland -- Roland Bauerschmidt <[EMAIL PROTECTED]>
Re: IA-64?
Jason Gunthorpe wrote: > HP, via Matt Taggart, is planning to put a IA64 box and a HPPA box for us > at their Fort Collins, Colorado facility. That sounds good. I wasn't aware of it. Roland -- Roland Bauerschmidt <[EMAIL PROTECTED]>
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: Bug in cron postinst
Steve Greenland wrote:
> for ct in * ; do
> chown $ct:crontab $ct
> done
This will also fail with usernames that include spaces. I'm sure you
already have a solution, but I'd go with something like this:
find /var/spool/crontab -maxdepth 1 -type f -print | while read ct; do
...
done
Roland
Re: can't update pbuilder to unstable
Hi, Brian May wrote: > Is there anything I can do to update this pbuilder chroot? That was #208602, solved in pbuilder 0.86, for the case that something like /etc/pam.d/other appears again. bye, Roland signature.asc Description: This is a digitally signed message part
Looking for a co-maintainer for adduser
The number of bugs on the adduser package has constantly increased for the last few months, though none of them is release critical. Since I was busy with other stuff (mostly OpenLDAP and related stuff) I didn't keep up with all the feature requests and non-critical bugs. This is also partly due to the fact that I don't like the way adduser is currently written (and also perl) a lot, and was planning to do a complete overhaul (http://www.hbg-bremen.de/~roland/code/adduser.xhtml). Matthew Palmer has done some nice work in abstracting the passwd storage backend, and adding methods for LDAP storage. The latter, though, still needs some more work to be useful in different directory structures. I am thus seeking for one or two co-maintainers, and appreciate it a lot if Matthew would chose to be one of them. The package is managed in a Subversion repository on Alioth. The main package is in trunk, Matthew's LDAP extended version in brances/adduser-ldap (which should eventually be merged into trunk); all in the svn+ssh://svn.debian.org/svn/adduser repository. It'd be particularly useful, if you have NIS experience (and maybe even a running setup), but not required. There is an adduser-devel also on Alioth. If you are interested, drop me a note off-list. -- Roland
Re: RFC: allow new upstream into stable when it's the only way to fix security issues.
W. Borgert <[EMAIL PROTECTED]> wrote: >> (1) keep vulnerable packages in stable, >> (2) remove affected packages from distribution, >> (3) allow new upstream into stable. > I'ld "vote" for (2), maybe with the goal of creating pressure > towards upstream to take security more serious. But how do you push the users to remove the package from their systems? In reality they will keep the broken version installed and so you have (1) again :-( Tscho Roland -- * [EMAIL PROTECTED] * http://www.spinnaker.de/ * -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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]
[Mass bug filing] Native vs. non-native packages consistency
Hi,
I knew you would read this mail considering the subject. ;-)
Below is a list of 311 packages that currently have a version in
unstable that is not properly reflected by the existence of an
orig.tar.gz file (that's 3.3% of the whole sid archive).
Feel free to point me to false positives, as I haven't checked every
single one of them. I know that some of them already have respective
bugs filed against them.
Interestingly, 3 of them have orig.tar.gz files but no Debian revision
(with one of those containing an empty diff).
If there are no serious concerns, I will start filing bugs against the
packages that are not already handled or bugged otherwise, together with
a verbose explanation and suggestions in a week or so.
To prevent this phenomenon in the future (people sometimes just forget
checking for an orig.tar.gz and ignore lin{da,tian} warnings), what
about making the archive maintenance software reject such uploads? This
should be easy to implement. However, care must be taken for corner
cases like NMUs for already existing packages etc.
Thanks.
bye,
Roland
acl_2.2.32-1.tar.gz (Nathan Scott <[EMAIL PROTECTED]>)
adduser-ng_0.1.2-1.2.tar.gz (Robert Olejnik <[EMAIL PROTECTED]>)
aggregate_1.0.2-2.tar.gz (Simon Horman <[EMAIL PROTECTED]>)
alltraxclock_2.0.2-0.tar.gz (Romain Lerallut <[EMAIL PROTECTED]>)
alml_2005.01.01-2.1.tar.gz (Gaetano Paolone (bigpaul) <[EMAIL PROTECTED]>)
apcd_0.6b.nr-2.tar.gz (Tibor Koleszar <[EMAIL PROTECTED]>)
apoo_1.3-3.tar.gz (Rogerio Reis <[EMAIL PROTECTED]>)
arpwatch_2.1a13-2.tar.gz (KELEMEN Péter <[EMAIL PROTECTED]>)
asmon_0.70-1.tar.gz (Eric Evans <[EMAIL PROTECTED]>)
atari-fdisk_0.7.1-5.1.tar.gz (Roman Hodek <[EMAIL PROTECTED]>)
attr_2.4.25-1.tar.gz (Nathan Scott <[EMAIL PROTECTED]>)
avce00_1.3.0-1.tar.gz (Debian GIS Project
)
avifile_0.7.44.20051021-1.tar.gz (Zdenek Kabelac <[EMAIL PROTECTED]>)
barrendero_1.1-1.tar.gz (Eduardo Diaz Comellas <[EMAIL PROTECTED]>)
boa_0.94.14rc20-1.2.tar.gz (Teófilo Ruiz Suárez <[EMAIL PROTECTED]>)
bogl_0.1.18-1.4.tar.gz (Daniel Jacobowitz <[EMAIL PROTECTED]>)
bonobo-activation_2.4.0-4.tar.gz (Takuo KITAME <[EMAIL PROTECTED]>)
burn_0.4.3-2.tar.gz (Gaetano Paolone (bigpaul) <[EMAIL PROTECTED]>)
camlidl-doc_1.04-1.tar.gz (Stefano Zacchiroli <[EMAIL PROTECTED]>)
cdfs-src_2.4.20.a+2.6.12-2.tar.gz (Eduard Bloch <[EMAIL PROTECTED]>)
chemeq_1.2-1.tar.gz (Georges Khaznadar <[EMAIL PROTECTED]>)
classpath-tools_0.0.20020812-1.tar.gz (Grzegorz Prokopski (Debian
Developer) <[EMAIL PROTECTED]>)
coco-cs_20050926-1.tar.gz (Loeberbauer Markus <[EMAIL PROTECTED]>)
coco-doc_20050504-1.tar.gz (Loeberbauer Markus <[EMAIL PROTECTED]>)
coco-java_20050926-1.tar.gz (Loeberbauer Markus <[EMAIL PROTECTED]>)
console-data_2002.12.04dbs-49.tar.gz (Alastair McKinstry
<[EMAIL PROTECTED]>)
console-tools_0.2.3dbs-57.tar.gz (Alastair McKinstry <[EMAIL PROTECTED]>)
crystalspace_0.98-20040623-2.1.tar.gz (Christian Bayle <[EMAIL PROTECTED]>)
crystalspace-data_0.98-20040623-1.tar.gz (Christian Bayle
<[EMAIL PROTECTED]>)
dbbalancer_0.4.4-9.tar.gz (Andrew McMillan <[EMAIL PROTECTED]>)
dbf2mysql_1.14a-3.tar.gz (Francesco Paolo Lovergine <[EMAIL PROTECTED]>)
delo_0.8-2.tar.gz (Karsten Merker <[EMAIL PROTECTED]>)
dep.pl_1.36.0-5.tar.gz (Angel Ramos <[EMAIL PROTECTED]>)
deroff_1.1-5.tar.gz (David Frey <[EMAIL PROTECTED]>)
diffmon_20020222-2.tar.gz (Jeff Bailey <[EMAIL PROTECTED]>)
discus_0.2.9-1.1.tar.gz (Ron Farrer <[EMAIL PROTECTED]>)
dmapi_2.2.1-1.tar.gz (Nathan Scott <[EMAIL PROTECTED]>)
doc-linux-de_2003.10-3.tar.gz (Noèl Köthe <[EMAIL PROTECTED]>)
doc-linux-fr_2005.08-1.tar.gz (Pierre Machard <[EMAIL PROTECTED]>)
doc-linux-html-pt_1999-12-4.tar.gz (Gleydson Mazioli da Silva
<[EMAIL PROTECTED]>)
doc-linux-nl_20050324-2.tar.gz (Wouter Verhelst <[EMAIL PROTECTED]>)
doc-linux-sv_2001.12-2.tar.gz (Debian QA Group <[EMAIL PROTECTED]>)
doc-linux-text-pt_1999-12-5.tar.gz (Gleydson Mazioli da Silva
<[EMAIL PROTECTED]>)
docbook-xsl-stylesheets-ko_0.2-2.tar.gz (Yooseong Yang
<[EMAIL PROTECTED]>)
domesday_0.2cvs20030101-3.tar.gz (Mark Howard <[EMAIL PROTECTED]>)
duali_0.2.0-1.1.tar.gz (Mohammed Elzubeir <[EMAIL PROTECTED]>)
e2fsprogs_1.38-2.tar.gz (Theodore Y. Ts'o <[EMAIL PROTECTED]>)
ean13_0.4-8.1.tar.gz (Jim Westveer <[EMAIL PROTECTED]>)
falselogin_0.2-4.tar.gz (Tibor Koleszar <[EMAIL PROTECTED]>)
fireflier_1.1.6-2.tar.gz (Martin Maurer <[EMAIL PROTECTED]>)
flip_1.19-2.tar.gz (James R. Van Zandt <[EMAIL PROTECTED]>)
floppybackup_1.3-3.tar.gz (Matthew Vernon <[EMAIL PROTECTED]>)
fortunes-br_20011121-2.tar.gz (Eduardo Marcel Macan <[EMAIL PROTECTED]>)
fortunes-eo_20020729-4.tar.gz (Radovan Garabík
<[EMAIL PROTECTED]>)
fragroute_1.2-7.tar.gz (Simon La
Re: Re: [Mass bug filing] Native vs. non-native packages consistency
Hi Steve, >> Feel free to point me to false positives, as I haven't checked every >> single one of them. I know that some of them already have respective >> bugs filed against them. > > Indeed, at least some of these *are* false positives; there is nothing > that prohibits the use of dashes in native version numbers [...] Right, thanks for pointing that out. The Debian native package state and Debian revisions are currently not directly connected. However, there were discussions[1] in the past about enforcing that. Some DDs backed it while one (major;) other described his personal packaging style as not suitable for that. However, his argument that katie already detects when packages are alternately uploaded "native" and "non-native" is not valid, since it doesn't/didn't work, see rscheme and queue (just 2 random packages from "the list"). > [...] so I don't really think it's appropriate to mass-file bugs > against packages which appear to be missing .diff.gz's until they've > been verified individually. Of course, I wouldn't just script 300+ bug openings automatically but work on them individually. A general criterion for opening a bug would be that there is a suitable upstream package/tarball available that would be suitable as for the general orig.tar.gz case, and/or that the package was non-native before and one of the last uploads turned it to native by missing the orig.tar.gz. Right? > However, noting that you've managed to tag large > numbers of core kernel packages as false-positives I was well aware that the list includes some holy cows. ;-) Therefore, I asked first. (Well, would have done that anyway.) However, I consider most kernel packages you listed as legacy Debian kernel packaging style. bye, Roland [1] http://lists.debian.org/debian-policy/2001/02/msg00140.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
UTF-8 for debian/control
Hi, when feeding the data from the Sources file into a script that implicitly checks for UTF-8 consistency (a Python lib), the following packages happen to include byte sequences that are no valid UTF-8: cadubi fcmp glade-perl myspell-sv rat all of them have another encoding in the Maintainer field. I'm thinking about "bugging" the Maintainers to change it to UTF-8. Any opposition? Time for reviewing http://lists.debian.org/debian-devel/2004/12/msg00521.html and a statement in Policy about that (for consistency with changelogs that are already handled that way)? Thanks, bye, Roland -- 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]
"libtool" performance... / was: Re: Announcing Dolt, a drop-in Libtool replacement which cuts build timesin half
Josh Triplett wrote: > > Many packages use GNU autotools (automake and autoconf) to build, to > the point that "./configure && make" represents one of the most common > build procedures for Free Software packages. Libraries using > autotools typically use GNU Libtool, partly because it works on almost > any system and partly because autotools makes it difficult to do > otherwise. Packages which use these libraries sometimes use libtool > as well. > > Yet for many of these libraries and other packages, more than half of > the build time goes into running the libtool shell script. > > Libtool knows how to handle libraries for umpteen different systems, > including many ancient systems that have terrible shared library > support. It has some extensive shell script logic to figure out how > to build libraries for your system, and how to compile objects that go > in those libraries. This logic does an amazingly impressive job of > coping with adverse conditions. However, this logic all lives in an > ~8500 line, ~250kB shell script, which runs *every single time you > compile a source file*. > > This does not do wonders for performance. [snip] Uhm... a while ago we hit the same problem and did some research on the issue and a diffent route by switching the shell used by libtool from "bash" to "ksh93" and did some minor modifications (e.g. enable more ksh93 builtin commands, replace some of the "sed" usage by builtin-string operators (which are common between "bash" and "ksh93" but libtool didn't use them) etc. (the resulting script no longer does unneccesary |fork()|+|exec()| calls (since ksh93 doesn't |fork()| for subshells&co.))) ... and as a result we hit a similar performance improvement as seen with the "dolt" tool... Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) -- 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]
