Re: Should gnome-libs die for Lenny?
Barry deFreese schreef: > Hi folks, > > There are only 5 packages left that have reverse depends on gnome-libs > packages. They are as follows: > > digitaldj: Removal request was filed but maintainer claims someone has > done a Gtk2 port and saved it for now. I thought this was a post-lenny thing anyway, but if there's only so few packages left, I'm tempted to not obstruct the removal of gnome-libs for digitaldj. Lets say I try to get an upload with the GTK2 patch within a week or so, would the new digitaldj sitll be allowed in to lenny? [Johannes is the patch in such a state that we could do that?] grts Tim -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
> > - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- > 41b0a520-c6c1-4e7b-8c49-74ee85faf242 > [ 3 ] Choice 1: Reaffirm the Social Contract > [ 1 ] Choice 2: Allow Lenny to release with proprietary firmware [3:1] > [ ] Choice 3: Allow Lenny to release with DFSG violations [3:1] > [ ] Choice 4: Empower the release team to decide about allowing DFSG > violations [3:1] > [ 2 ] Choice 5: Assume blobs comply with GPL unless proven otherwise > [ 4 ] Choice 6: Exclude source requirements for firmware (defined) [3:1] > [ ] Choice 7: Further Discussion > - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- > signature.asc Description: PGP signature
Re: Packages still depending on GTK+ 1.2
On Thu, 11 Dec 2008 14:42:08 +0100 (CET) Andreas Tille <[EMAIL PROTECTED]> wrote: > On Thu, 11 Dec 2008, Josselin Mouette wrote: > > > As this reaction is quite common, maybe I should make things more clear. > > > >* Yes, GTK+ 1.2 is going away before the squeeze release. * > > > > If everyone says “I’m going to remove my pet package when it is the last > > one”, it is obvious that we are never going to remove it. > > I don't read Tim's message like this. I read: Just remove GTK+ 1.2 and once > this is done my pet package becomes RC buggy. The fix for the bug is removing > the package. That's quite simple and Tim in this message agrees to this > procedure (as well as I did). Indeed, that is what Tim meant to write;) grts Tim signature.asc Description: PGP signature
Re: Packages still depending on GTK+ 1.2
On Fri, 05 Dec 2008 19:06:26 +0100 Josselin Mouette <[EMAIL PROTECTED]> wrote: > Tim Dijkstra <[EMAIL PROTECTED]> >digitaldj > => prokyon3 It still works, some people still use it... so I do not see any need to remove it now. If the time comes to remove gtk+1.2, digitaldj can go too IYAM. I'm not using it anymore, and certainly do not have the time to port it. grts Tim signature.asc Description: PGP signature
Re: issues with aptitude dist-upgrade from etch to lenny
Henning Glawe schreef: > Moin, > seems like in the dist-upgrade from etch to lenny is one very annoying > (and old, AFAIR I hit it already in woody->sarge and sarge->etch) > problem: perl is in an unusable state during the upgrade and causes > maintainer scripts to fail. > > I was following way: > - update from etch and etch-security > - change sources.list (lenny instead of etch) > - update-procedure: > apt-get update > aptitude install aptitude > aptitude dist-upgrade > > after the system working for a while, maintainer scripts started to fail > and aptitude exited. > the maintainer-script errors were perl-related: the interpreter could not > find modules (all from perl-base) in @INC. > further investigation showed that perl-base was still installed in the > etch-version, while perl itself was from lenny (and of course, the lenny > version was not finding its own versioned modules from perl-base). > > i worked around this by installing perl-base from lenny using dpkg. > which also failed due to the dependency loop between perl and perl-base. > > dpkg --configure perl perl-base perl-modules FWIW, I've seen something similar, although I think I had the whole new perl (perl, perl-base and perl-modules) unpacked at least. The proplem seemed to be that the @INC line still had entries only from 5.8 while 5.10 was unpacked. I hadn't any time to research the problem in more detail, so this message will not transcend the level of a ``me too!''-message ;) grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#438665: Orphaned packages with quite some users
On Thu, 1 Nov 2007 09:11:33 +0100 Raphael Hertzog <[EMAIL PROTECTED]> wrote: > On Thu, 01 Nov 2007, Michael Biebl wrote: > > Given that acpi-support is going to be deprecated in favor of > > pm-utils/hal [1] I'd rather see acpi-support removed from the > > laptop-task completely. > > [1] https://wiki.ubuntu.com/PMUtilsSpec > > I'm all for this if this is possible. acpi-support has always meant to be > a temporary set of hacks to make things work. > > Given that it's planned for next LTS release of Ubuntu it should be > compatible with the Lenny schedule. Tim, what do you think of the > principle ? Would you be ready to prepare such replacements package > in experimental (either working directly with Ubuntu or reintegrating their > work > once they did it) ? I never really looked at acpi-support because for the laptops I have, I had no use for it. pm-utils now, is mostly some glue between HAL and s2disk/s2ram, all be it with possibility to hook in all kind of hacks. Reading the wiki page above, there is some functionality not present in pm-utils (yet). When this is added to pm-utils, of course I'll integrate it. I'm kind of busy right now to pick-up porting acpi-support functionality to pm-utils. And if the Ubuntu people want to do that, I'm all for it;) grts Tim signature.asc Description: PGP signature
Re: Bug#445998: ITP: eaccelerator -- PHP accelerator, optimizer, and dynamic content cache
On Tue, 09 Oct 2007 21:29:38 +0400 Alexander Gerasiov <[EMAIL PROTECTED]> wrote: > Package: wnpp > Severity: wishlist > Owner: Alexander Gerasiov <[EMAIL PROTECTED]> > > * Package name: eaccelerator > Version : 0.9.5.2 > Upstream Author : eaccelerator team http://eaccelerator.net/wiki/Team > * URL : http://eaccelerator.net > * License : GPL > Programming Lang: C > Description : PHP accelerator, optimizer, and dynamic content cache > Some dummy packages available for now in my repository at > http://gq.net.ru/debian > > I'm going to upload it after fixing some packaging issues. Feel free to > kick me by mail, if I'm too slow. Are the license issues finally solved then? Last time I checked binaries were not distributable, see for example: http://www.mailarchives.org/list/debian-devel/msg/2005/08164 grts Tim signature.asc Description: PGP signature
Re: Bug#425050: initramfs-tools: Ask if we should update all initramfses
Please cc: the bug report On Sun, 20 May 2007 16:35:27 +0200 David Härdeman <[EMAIL PROTECTED]> wrote: > On Sun, May 20, 2007 at 11:08:02AM +0200, martin f krafft wrote: > >They can set their debconf priority. It's not something to avoid, > >adding debconf questions > > > >Anyway, I propose that update-initramfs just loses the -k switch or > >provides a new wrapper that packages like cryptsetup and mdadm just > >call without worrying whether it will update all initrds or just the > >current one. > > I agree...use a debconf or config file option, then let packages call > update-initramfs with a new option (let's call it "-p") and the option > will be automatically honoured so that one or all initramfs images are > rebuilt. That seems sensible to me. Maximilian, what do you think? Is this acceptable to you? grts Tim signature.asc Description: PGP signature
Re: update-initramfs -k all -u
On Sat, 19 May 2007 00:23:08 +0200 David Härdeman <[EMAIL PROTECTED]> wrote: > On Fri, May 18, 2007 at 04:41:41PM +0200, Gabor Gombas wrote: > >On Fri, May 18, 2007 at 09:12:15AM +0200, martin f krafft wrote: > > > >> Good point. Thus it looks like there is no right way [...] > > > >How about making the use of "-k all" configurable? > > The point I was trying to make before is that the decision whether "-k > all" is sane or not can only be decided per package (and perhaps even > per revision). That sounds reasonable, but unfortunately you can't. If I (as the uswsusp maitainer) decide to use '-k all' your package gets installed to the initramfs anyway. So this is really something we should agree on for all packages at same time. As it seems we can't agree that's why I think using the users preference is the best we can do. BTW, I was reading about `triggers' on the dpkg-list a while back. Update-initramfs seems like a perfect use case. Updating all initramfses three times in one dpkg run, just because initrfamfs-tools, uswsusp and cryptsetup get updated at the same time is not funny... grts Tim signature.asc Description: PGP signature
Re: Bug#425050: initramfs-tools: Ask if we should update all initramfses
On Fri, 18 May 2007 19:48:54 +0200 maximilian attems <[EMAIL PROTECTED]> wrote: > tags 425050 wontfix > stop > > On Fri, May 18, 2007 at 07:32:45PM +0200, Tim Dijkstra (tdykstra) wrote: > > > > I created a patch to ask a debconf question (medium priority) if > > update-initramfs should update all initramfs or not. The idea is that > > other packages (like my uswsusp package) should check this question too. > > > > This way we can make both the people that want to keep old initramfses > > around and the people that want an up-to-date initramfs for several > > versions happy at the same time. > > > > grts Tim > > big no: > useless debconf proliferation is bad. Come on. `useless debconf proliferation'? The question has medium priority. I can also make it an configration option somewhere and use that, but it was just a convenient why to get info from a user. > second if you want to update all initramfs it is easy to do so. No, it is not. Well not in an automated way consistent over all packages that use it. Maybe you haven't noticed, but this has come up several times in several bug reports already. Now we have a situation where from several packages, some only update the initramfs only for the current one, others for all. This is IMHO bad. I presume (reading other bug reports against u-i) that there was a good reason not to update them for all. Well know you don't get that behavior. > third this does not belong to initramfs-tools at all. Of course it is if we want it to be consistent over several packages. grts Tim signature.asc Description: PGP signature
Re: update-initramfs -k all -u
On Fri, 18 May 2007 19:25:09 +0200 Gabor Gombas <[EMAIL PROTECTED]> wrote: > On Fri, May 18, 2007 at 04:51:46PM +0200, Tim Dijkstra wrote: > > > That seems like a good idea... but what would be the default? > > Doesn't matter as there are already examples of both behavior so picking > a random value and flamdebating it later is fine. The important > thing is to make the behavior consistent between packages and allow > people who are unhappy with the default to override it. OK, Just implemented the debconf question, see 425050. If it gets applied I'll file some patches for packages using initramfs-tools to use the same question. grts Tim signature.asc Description: PGP signature
Re: update-initramfs -k all -u
On Fri, 18 May 2007 16:41:41 +0200 Gabor Gombas <[EMAIL PROTECTED]> wrote: > On Fri, May 18, 2007 at 09:12:15AM +0200, martin f krafft wrote: > > > Good point. Thus it looks like there is no right way [...] > > How about making the use of "-k all" configurable? That seems like a good idea... but what would be the default? grts Tim signature.asc Description: PGP signature
Re: update-initramfs -k all -u
On Fri, 18 May 2007 01:18:01 +0200 David Härdeman <[EMAIL PROTECTED]> wrote: > On Wed, May 16, 2007 at 12:23:55AM +0200, martin f krafft wrote: > >also sprach Tim Dijkstra <[EMAIL PROTECTED]> [2007.05.15.2201 +0200]: > >> Now what do people think is the best option? (And why?) > > > >I use -k all in mdadm already. I could not find any reasons why that > >would not be a good idea. > > The reason I didn't use it in cryptsetup's initramfs script was that > many people who have > 1 kernel use the second one as a fallback. In > case the updated version of the package which calls update-initramfs in > its postinst contains some grave bug which renders the initramfs image > useless, the old one will still be there... Yes, but when initramfs and the root partition need to be in sync to be functional, the backup won't help you either... grts Tim signature.asc Description: PGP signature
Re: RFC: initramfs-tools postinst causes system inconsistency?
On Tue, 15 May 2007 23:54:02 +0200 maximilian attems <[EMAIL PROTECTED]> wrote: > i'd appreciate if you post such questions to the corresponding > development mailing list which is debian-kernel for initramfs > questions. > thanks > > > Current pratice is to only call `update-initramfs -u', that is, to only > > update the most recent initramfs. This however will break older > > initramfses (I have had bugreports). Now I plan to switch to running > > with '-k all' (all initramfses), but this of course will also > > influence=20 the packages that ran with '-u' only. > > afaik uswsusp does not support full > 2.6.15 range, > so better stay on the safe side. Uswsusp will refuse to suspend or resume with kernels it won't support, so that's OK. grts Tim signature.asc Description: PGP signature
update-initramfs -k all -u
Hi, I maintain uswsusp. It is a package that relies on a binary on the initramfs that will start the resume process. This binary (and some other stuff) get installed via an update-initramfs call in the postinst. On some updates, the new binary that suspends the system is incompatible with the old resume binary on the initramfs, hence a update-initramfs call is required. So far so good. Current pratice is to only call `update-initramfs -u', that is, to only update the most recent initramfs. This however will break older initramfses (I have had bugreports). Now I plan to switch to running with '-k all' (all initramfses), but this of course will also influence the packages that ran with '-u' only. Now what do people think is the best option? (And why?) grts Tim signature.asc Description: PGP signature
Re: Announce: DebianArt.org
On Sun, 13 May 2007 00:50:02 +0100 Luis Matos <[EMAIL PROTECTED]> wrote: > Dom, 2007-05-13 às 00:43 +0200, Tim Dijkstra escreveu: > > On Wed, 9 May 2007 17:49:18 -0300 > > "André Luiz Rodrigues Ferreira" <[EMAIL PROTECTED]> wrote: > > > > > Hi all, > > > > > > > > > The user can put the follows categories: > > > - Wallpaper > > > - Splash screen > > > - Icon > > > - System sound > > > - Logo > > > - Usplash > > > - T-shirt > > > - Screenshot > > > - Generic > > > > > > What do you think? > > > We think this is one of the available ways for a best desktop > > > > It would be nice if someone could make some nice splash themes for > > splashy;) It supports different splash screens during boot, shutdown, > > hibernate and resume. > > > > wasn't these made before etch? based on the more-blue theme? > > in releated note, andre are you available to update debian more-blue's > splsh screen into something more round, like the login screen (and > whitier)? I don't think we have a consistent screen for suspend/resume. grts Tim signature.asc Description: PGP signature
Re: Announce: DebianArt.org
On Wed, 9 May 2007 17:49:18 -0300 "André Luiz Rodrigues Ferreira" <[EMAIL PROTECTED]> wrote: > Hi all, > > > The user can put the follows categories: > - Wallpaper > - Splash screen > - Icon > - System sound > - Logo > - Usplash > - T-shirt > - Screenshot > - Generic > > What do you think? > We think this is one of the available ways for a best desktop It would be nice if someone could make some nice splash themes for splashy;) It supports different splash screens during boot, shutdown, hibernate and resume. grts Tim signature.asc Description: PGP signature
Re: LSB init scripts
On Thu, 03 May 2007 18:13:25 -0700 Russ Allbery <[EMAIL PROTECTED]> wrote: > Lars Wirzenius <[EMAIL PROTECTED]> writes: > > On to, 2007-05-03 at 13:39 -0700, Russ Allbery wrote: > > >> My ideal output format would just list "subsystem OK" > > > While we're daydreaming, I'd like an empty screen with a timer counting > > down how long (in seconds) I have until I can actually use the machine. > > Unless there's a problem, of course, in which case I want all the info I > > need to debug things. > > One of the great parts of using a library to handle the output formatting > is that people who want this sort of boot presentation (or anything else, > really) can then develop themes that do exactly what they want. > Splashy is indeed already using that functionality. It installs a file /etc/lsb-base-logging.sh, which is their to override functions from the LSB library. It increments a progress bar triggered by calls to log_end_msg made from init-scripts. That way we don't need change the initscripts or install extra scripts, we get out info from all scripts that use the LSB library. grts Tim signature.asc Description: PGP signature
Re: The number of etch installations is rocketing...
On Thu, 12 Apr 2007 14:53:42 +0200 Johannes Wiedersich <[EMAIL PROTECTED]> wrote: > For laptops brand/model would be nice, although it probably will be > difficult or impossible to include that in an automated fashion. No it wouldn't. Most laptops have usable information in their smbios which. See dmidecode(8). grts Tim signature.asc Description: PGP signature
Re: Bug#417261: dch: please use dates in UTC
On Mon, 2 Apr 2007 15:49:54 +0200 Stefano Zacchiroli <[EMAIL PROTECTED]> wrote: > On Mon, Apr 02, 2007 at 03:31:37PM +0200, Frans Pop wrote: > > That is not really a valid reason either because converting a timestamp > > from a changelog entry to any other timezone or format is trivial: > > > > $ D="$(zgrep "^ -- " /usr/share/doc/apt/changelog.Debian.gz | \ > > > head -1 | sed "s/^.*> //")" > > $ date -uRd "$D" > > "Trivial" is something I can do without having the need of thinking > about an implementation of it. I guess you spent a couple of minutes > writing the above shell script snippet. I think every person that reads a changelog can do the math for each entry by hand in a fraction of a second... > But of course you're right in stating that it's possible and it's not a > big deal to do the conversion. My question is: what's the benefit of > localized timestamps? I want to know if the only reason we have is: > "just because it's nice". It is added information. For example it is useful to know that somebody uploaded at 03:12 in _his timezone_, if he/she made it so late, it probably worth double checking it before you install;) grts Tim signature.asc Description: PGP signature
Re: Slow package database
On Mon, 2 Apr 2007 11:10:55 +0200 Christoph Haas <[EMAIL PROTECTED]> wrote: > Is there anything that I can do about it? Tuning the ext3 partition? Or is > somebody capable of turning the info directory into - say - an sqlite > database or in future Debian releases? There is a thread on debian-dpkg about this, even with a proof of concept: http://people.debian.org/~seanius/dpkg-sqlite/ grts Tim signature.asc Description: PGP signature
Re: Bugs in default GNOME etch?
On Wed, 17 Jan 2007 09:28:06 +0100 Josselin Mouette <[EMAIL PROTECTED]> wrote: > Having eog and evince in the menu serves the "I want to look at a file I > know I have on my disk" case. But you can open the file in the same > number of clicks but with a better interface, by launching a nautilus > window. You can get it even faster if it's still in the "recently used" > menu. I would say lots of people are used to think in the following way: I want to open file `foo'. Start program that handles file `foo'. Open file `foo' This works with files that you can edit (abiword files) and those you can't (pdf). A distinction between the two is IMHO artificial. Why not facilitate people that work like this and have one more entry in the menu? I would say there is even a better case for having evince in the menu then for eog. eog opens files you can edit with programs like gimp, while for evince there is no alternative `editor'. grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bugs in default GNOME etch?
On Tue, 16 Jan 2007 17:55:53 +0100 Michael Banck <[EMAIL PROTECTED]> wrote: > On Tue, Jan 16, 2007 at 05:22:51PM +0100, Tim Dijkstra wrote: > > On Tue, 16 Jan 2007 17:03:15 +0100 > > Loïc Minier <[EMAIL PROTECTED]> wrote: > > > Just FYI, I *personally* would prefer an evince entry in the menu as > > > well, but I prefer keeping close to the usability policy defined by > > > upstream. > > > > Well we shouldn't keep ourselves hostage of stupid upstream behaviour, > > should we? > > Contrary to us, GNOME (in this case RedHat) actually employs usability > experts. Who are we to think we know better? You'll see that these so-called experts will be arguing next that you're not supposed to launch it from a terminal and will move it from the standard $PATH to /usr/lib/gnome or something grrr Tim
/var like dir accessible early in boot sequence
Hi, We need a directory, which is accessible very very early during boot. It has some files in it which are regenerated at regular intervals, but not (necessarily) during boot. Actually we know generate it during runlevels 0 and 6. For know we put this in /lib/$package. I'm not sure this OK, because it means we will write to / also when we're not installing packages. /var/lib seems better, but that is not available that early. If it is really necessary we could generate the information during boot, so maybe /lib/init/rw? Comments? grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bugs in default GNOME etch?
On Tue, 16 Jan 2007 15:51:29 +0100 Luca Capello <[EMAIL PROTECTED]> wrote: > > The presence in the menu has to be weighted against the cluttering. > > If I search for a program, I go to the menu list, not on Nautilus > (obviously this is my personal behavior, which can surely be different > From a new user's one). I don't know. I think 'traditionally' one always had to launch the correct program from the menu, also on other OSs. grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bugs in default GNOME etch?
On Tue, 16 Jan 2007 17:03:15 +0100 Loïc Minier <[EMAIL PROTECTED]> wrote: > Just FYI, I *personally* would prefer an evince entry in the menu as > well, but I prefer keeping close to the usability policy defined by > upstream. Well we shouldn't keep ourselves hostage of stupid upstream behaviour, should we? grts Tim
Re: Bugs in default GNOME etch?
On Tue, 16 Jan 2007 10:46:45 +0100 Marc 'HE' Brockschmidt <[EMAIL PROTECTED]> wrote: > Luca Capello <[EMAIL PROTECTED]> writes: > > 2) the Debian menu requires xpm icons [2] and in fact only 4 packages > >have icons in the png format (ekiga, evince, gimp, gnomemeeting), > > To be fair, the .png icon referenced by the evince menu file doesn't > exist... > > > 4) evince doesn't appear by default on the GNOME Applications list (it > >happened on three different installations). Maybe it's not the > >only one, but I cannot find any others. > > That is intentional, as evince is not intended to be invoked > directly. Other applications (such as browsers, nautilus) can and will > open files in evince when the user is trying to see a > PDF/PS/DjVu/DVI/... file. That is a bogus argument. Why shouldn't I want to fire up evince when I know I have a pdf/ps/etc file on disk I wan't to read? It has a normal 'open'-button... grts -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bash /dev/tcp and /dev/udp
On Thu, 23 Nov 2006 09:42:50 -0600 Ron Johnson <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 11/23/06 07:09, Jan C. Nordholz wrote: > > Hi Klaus, > > > >> >from the bash manpage: > >> /dev/tcp/host/port > >> /dev/udp/host/port > > > > This has been discussed several times [1][2], and the outcome was every time > > that this should not be a feature of the shell, but of more specialized > > tools like nc. Use those or recompile your bash. > [snip] > > > > [1] http://lists.debian.org/debian-user/2003/04/msg01591.html > > [2] http://lists.debian.org/debian-user/2006/07/msg00121.html > > http://lists.debian.org/debian-user/2006/07/msg00204.html > > It can produce completely unexpected results. > > C & Perl also can produce completely unexpected results, and C is a > security nightmare, but we don't ban/disable them in Debian. FWIW, awk has similar functionality. From awk(1): The following special filenames may be used with the |& co-process operator for creating TCP/IP network connections. /inet/tcp/lport/rhost/rport File for TCP/IP connection on local port lport to remote host rhost on remote port rport. Use a port of 0 to have the system pick a port. /inet/udp/lport/rhost/rport Similar, but use UDP/IP instead of TCP/IP. /inet/raw/lport/rhost/rport Reserved for future use. grts Tim signature.asc Description: PGP signature
Re: gdm/Gnome/KDE and device permissions
On Wed, 11 Oct 2006 16:31:37 +0200 Gernot Salzer <[EMAIL PROTECTED]> wrote: > > > First, there is no safe way to revoke privileges from a user. If a user > > gets access to a certain group he/she can arrange ways to keep it, > > even after being logged out (make a suid binary for example). > > I admit that I don't know much about the internals of Unix/Linux. > > So, if upon login of user "foo" ownership/permissions of /dev/audio are set to > crw--- 1 foo audio 14, 4 2006-09-22 13:25 /dev/audio > and after logout of "foo" and login of "bar" to > crw--- 1 bar audio 14, 4 2006-09-22 13:25 /dev/audio > "foo" might still be able to access /dev/audio ? One problem is that a user can launch a daemon that keeps the device file open before she logs out Also I was referring to how pam_group works, but I find this way of handling permissions even more broken than pam_group. For example, what happens if somebody logs in on another VT? > > Second, several people can login at once on different VTs. > > True, the general case is much more involved. > > However, considering that the majority of desktops is single-headed, Ever tried ctrl-alt-fn or fast-user-switching? > This includes to be able to access devices easily, > but without being pried upon by curious (but otherwise friendly and > non-hacker) remote users. You maybe right that there are lots of people that are the only user on their systems and for them the objections I have are maybe not important. But going with pam_group or libpam-permdev is broken by design and is not the solution that is going be the standard in the debian. For these people the current setup probably works quite well anyway, because (IIRC) pmount mounts read-only for the user. (If it doesn't you can most probably set it up that way). And because everybody is friendly anyway they won't 'cat garbage > /dev/dsp' ;) > > Why would you want to bring udev in the picture? If you think the scheme > > used by pam_group (and similar) is secure enough for you, you can also > > grant > > access to the plugdev, netdev and powerdev groups. > > I don't want to grant access to groups but rather want to mimic > the behaviour of libpam-permdev that changes ownership/permissions > of the device to grant only access to the console user. > > Maybe "udev" is the wrong term; with udev I mean the part of the > system that creates devices dynamically and thus knows when and > at which device e.g. a usb stick was plugged in, and can initiate > the action of changing the ownership/permissions. > I found a partial solution somewhere on the web working like that. You could probably make a udev rule that does that. But it seems a bit fragile, and again has the same problems as the other methods. grts Tim signature.asc Description: PGP signature
Re: gdm/Gnome/KDE and device permissions
On Wed, 11 Oct 2006 14:12:20 +0200
Gernot Salzer <[EMAIL PROTECTED]> wrote:
> Don't mechanisms like libpam_devperm grant exclusive access?
> On login the ownership of the devices is set to the console user,
> and only the owner is granted rwx-rights. On logout
> ownership/permissions of the device revert to the old setting.
First, there is no safe way to revoke privileges from a user. If a user
gets access to a certain group he/she can arrange ways to keep it,
even after being logged out (make a suid binary for example).
Second, several people can login at once on different VTs.
> > Since groups are only set when a user logs in it's not possible to e.g.,
> > add the user to the plugdev group when they plug in a USB stick. You'd
> > have to add them to plugdev when they log in.
>
> Couldn't a script triggered by udev set ownership/permissions to
> the current console user, like libpam_devperm does?
Why would you want to bring udev in the picture? If you think the scheme
used by pam_group (and similar) is secure enough for you, you can also grant
access to the plugdev, netdev and powerdev groups. Note that access control
is not hard coded to plugdev in dbus, you can edit the files in /etc/udev
to have more relaxed access control. Oh, on debian you also need to change
the permissions of p{u,}mount
> How do end-user Linux distributions that are supposed to work out of the box
> (like ubuntu, fedora, suse) solve this problem? World-rwx for all
> user devices? All users added to groups like "audio", "video", ...?
Afaik, fedora has pam_console or something like that does something like
you suggest; give privileges to all users that log in at the console.
Also dbus has some support for this, but this isn't compiled in the
debian version, because of the caveats I outlined above.
> Would it be possible to let all user devices (static or dynamic) be
> owned by group "console" with rwx rights, and add/remove the console
> user dynamically to/from this group on login/logout? This way
> it wouldn't matter whether e.g. the usb stick is plugged in before
> or after login.
> Wouldn't this solve the problem?
As I said, no, it would not solve the problem safely for true multi-user
environments. FWIW, there has been some discussion and ideas floating
around on the HAL and DBus lists. The current consensus is that we need
a secure way for dbus/hal to know what is the current active virtual
terminal and how owns it. For mulit-head systems we need a way to
specify that certain devices (think usb ports) belong to a certain
display.
Nobody has had time to implement it yet however.
grts Tim
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gids assigned non-deterministically
On Tue, 10 Oct 2006 18:10:42 +0200
Gabor Gombas <[EMAIL PROTECTED]> wrote:
> On Tue, Oct 10, 2006 at 03:36:20PM +0200, Tim Dijkstra wrote:
>
> > That's not an argument someone can just 'chown :plugdev' something.
>
> Crap. I knew I'd overlook something. I think you could still prevent
> that with SELinux though :-)
Have to read up on SELinux some day, but not now;)
> On the other hand I was thinking about if in your case basically all
> user needs to be a member of all these groups anyway, then there is no
> point in having these groups at all. Just make pmount executable by
> anyone, and edit /etc/dbus-1/system.d/{avahi-dbus.conf,hal.conf} and
> replace '' etc. with ' context="default">' or with ''.
> Similarly, if all users have read(/write) access to a device because all
> users are part of the group owning the device node, then you can just
> make that device node a+r(/a+w) and forget about the group.
>
> Of course there may be services running under other uids that you do not
> want to give all access humans has; it has to be decided.
Yes, that doesn't seem like the right solution.
In any case, I'm kind of happy with my current setup. I was just trying
to point out that pam_group has it draw backs.
grts Tim
signature.asc
Description: PGP signature
Re: gids assigned non-deterministically
On Tue, 10 Oct 2006 15:08:29 +0200 Gabor Gombas <[EMAIL PROTECTED]> wrote: > On Tue, Oct 10, 2006 at 11:33:43AM +0200, Tim Dijkstra wrote: > > > Hmm, pam_group doesn't sound to secure to me... what if on one machine > > gid 110 is www-data and on another plugdev. Then if a user logs in on the > > second > > machine it will get access to gid 110, make some suid executable, which on > > another machine ... > > This can't happen. Groups are _not_ transferred over remote login. Of course not, that's the whole point. If you dynamically allocate system groups and dynamically make users members of groups. You can get a mess if they both write to a nfs mounted volume. A file that is owned by group 110 can be groups www-data on one and plugdev on the other. > New > files are owned by the user's primary group, and _not_ by the > supplemental groups (and I really hope you do not want to use 'plugdev' > etc. as the primary group for any real user...) That's not an argument someone can just 'chown :plugdev' something. grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gids assigned non-deterministically
On Tue, 10 Oct 2006 11:20:26 +0200 Gabor Gombas <[EMAIL PROTECTED]> wrote: > On Tue, Oct 10, 2006 at 09:36:56AM +0200, Tim Dijkstra wrote: > > > That is no longer a reality with groups like plugdev, powerdev and > > netdev, which users need to be a member of to be able to get the wonders > > of automatically mounted usb-sticks, tweakable power management and > > whatever comes with the utopia stack. > > Then use pam_group to temporarily assign those groups to users. That way > the gids can be different on every system, and you can even gain > performance by having less groups in LDAP. Hmm, pam_group doesn't sound to secure to me... what if on one machine gid 110 is www-data and on another plugdev. Then if a user logs in on the second machine it will get access to gid 110, make some suid executable, which on another machine ... Well the nfs mount is nosuid, but still, I find this a bit scary. > Especially if you have more than a handful of users (and if you are > considering LDAP, I assume you have), groups with hudreds or thousands of > members can cause headaches. But this is of course true... grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gids assigned non-deterministically
On Mon, 9 Oct 2006 14:39:07 -0500 Peter Samuelson <[EMAIL PROTECTED]> wrote: > > [Roberto C. Sanchez] > > That is a problem if I want to server everything up out of LDAP. > > There really should be a "reserved" range, maybe 100-499 of Debian > > gids, where they are assigned in a predertmined way. > > I don't think it's a good idea to put system users and groups into LDAP > anyway. They are specific to a system. That is no longer a reality with groups like plugdev, powerdev and netdev, which users need to be a member of to be able to get the wonders of automatically mounted usb-sticks, tweakable power management and whatever comes with the utopia stack. grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#389817: ITP: pm-utils -- utilities and scripts usefull for power management
Op Thu, 28 Sep 2006 01:29:14 +0100 schreef Stephen Gran <[EMAIL PROTECTED]>: > This one time, at band camp, Tim Dijkstra said: > > Op Thu, 28 Sep 2006 00:00:28 +0100 > > schreef Stephen Gran <[EMAIL PROTECTED]>: > > > > The advantage HAL has over acpid, is > > that it is very well integrated in to the users (kde or gnome) > > session. That way it is able to notify the user (he, your battery > > is low!) get user feedback (should I suspend to ram, to disk?) and > > act on user configuration (suspend to ram when closing the lid, but > > only when on AC, else suspend to disk). > > > > Only a little. Perhaps I am just of the old skool 'do one job and do > it well' mind set, but all of those events appear to be acpi events > which acpid handles rather well, even in the brave new world of single > user linux on laptops that Ubuntu and others have brought us. You do > know that acpid can run arbitrary scripts on acpi events, like say, > lid close, right? Yes of course. But acpid does next to nothing by default. HAL is more of a 'should-just-work' approach. Also what I wanted to stress; HAL is trying to fit in the brave new world of systems (lots of desktops have acpi, can suspend, etc) where the user at the active X-session should be able to influence what happens at these events -on the fly-. I'm also more of an old skool guy, but I also have several people using the machines I administer who are not. Also, I must confess, it's nice to click on some icon to temporally disable suspend (because of idle time) because I'm watching a movie. > I understand that this package is no different than > a dozen others, in that it tries to provide policy layers and cute > gui things on top of acpid, but it just seems like too many layers of > abstraction and replicated code bases to me. HAL does not need acpid, it will listen to acpi events just fine without. HAL, dbus, etc are already installed on a modern desktop (both kde and gnome), they already define that policy layer. So why not take advantage of that? > But, as I say, whatever, one more won't hurt. I just feel a little > perturbed when I see some new project that needs HAL, dbus, and a half > dozen other things to handle something that can already be handled > with shell scripts and a very small daemon. Note that all discussion above is about HAL, not pm-utils. HAL will depend on pm-utils, not the other way around. And what pm-utils means to bring is a consistent interface and a should-just-work experience for bringing the machine a sleep state, not listen to acpi events. Heck, you could even use pm-utils in combination with acpid. (Funny, I'm arguing in favour of pm-utils, here while I've just been expressing my reservations on the hal-list against it...;) grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#389817: ITP: pm-utils -- utilities and scripts usefull for power management
Op Thu, 28 Sep 2006 01:04:40 +0200 schreef Michael Banck <[EMAIL PROTECTED]>: > On Wed, Sep 27, 2006 at 11:41:01PM +0200, Steinar H. Gunderson wrote: > > On Wed, Sep 27, 2006 at 11:08:24PM +0200, Tim Dijkstra wrote: > > > Provides simple shell command line tools to suspend and hibernate > > > computer that can be used to run vendor or distro supplied scripts > > > on suspend and resume. > > > > This is something like the fifth package in Debian that attempts to > > do this. What sets is apart from the ones already in Debian? Do we > > really need another one? > > * Upstream Author : Bill Nottingham <[EMAIL PROTECTED]>, Peter Jones > <[EMAIL PROTECTED]>, David Zeuthen <[EMAIL PROTECTED]>, Richard Hughes > <[EMAIL PROTECTED]> > * URL : http://webcvs.freedesktop.org/pm-utils/pm-utils/ > > I think this is the one to rule them all. Are you being cynical or serious? grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#389817: ITP: pm-utils -- utilities and scripts usefull for power management
Op Thu, 28 Sep 2006 00:00:28 +0100 schreef Stephen Gran <[EMAIL PROTECTED]>: > Not that I actually object to the package, but why can't HAL let acpid > manage acpi events? I am continually confused by the profusion of > packages that offer to work around acpid in order to provide the > functionality it could and should be providing. Note that this package is not really related to acpid, but I'll try to answer anyway. Acpid is just another deamon listening to /proc/acpi/event. It doesn't have a good way of communicating with a user. HAL is also able to listen to acpi events (by listening to /proc/acpi/event or acpid). The advantage HAL has over acpid, is that it is very well integrated in to the users (kde or gnome) session. That way it is able to notify the user (he, your battery is low!) get user feedback (should I suspend to ram, to disk?) and act on user configuration (suspend to ram when closing the lid, but only when on AC, else suspend to disk). Now acpid has technically nothing to do with bringing the machine in a sleep state. For that to work you have basically three options: 1) Patch your kernel with suspend2 2) Use swsusp build in kernel 3) Use uswsusp which is partly in kernel, partly user space. I think that with the profusion of packages you talk about are the packages (like pm-utils) the try to work around bugs in drivers and offer functionality before and after the actual sleep. Things like syncing the clock, stopping services, networks, fixing the state of the graphics card. I hope this clears it up a bit grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#389817: ITP: pm-utils -- utilities and scripts usefull for power management
Op Wed, 27 Sep 2006 23:41:01 +0200 schreef "Steinar H. Gunderson" <[EMAIL PROTECTED]>: > On Wed, Sep 27, 2006 at 11:08:24PM +0200, Tim Dijkstra wrote: > > Provides simple shell command line tools to suspend and hibernate > > computer that can be used to run vendor or distro supplied scripts > > on suspend and resume. > > This is something like the fifth package in Debian that attempts to > do this. What sets is apart from the ones already in Debian? Do we > really need another one? This will make all others obsolete;) More seriously, this will be a dependency of HAL and with that of the whole gnome power management stack. So I think we can't go around it in the future. I wanted to package it to make sure it plays nice with uswsusp (another package I maintain). grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#389817: ITP: pm-utils -- utilities and scripts usefull for power management
Package: wnpp Severity: wishlist Owner: "Tim Dijkstra" <[EMAIL PROTECTED]> * Package name: pm-utils Version : 0.0.1 Upstream Author : Bill Nottingham <[EMAIL PROTECTED]>, Peter Jones <[EMAIL PROTECTED]>, David Zeuthen <[EMAIL PROTECTED]>, Richard Hughes <[EMAIL PROTECTED]> * URL : http://webcvs.freedesktop.org/pm-utils/pm-utils/ * License : GPL Programming Lang: C, Shell Description : utilities and scripts usefull for power management Provides simple shell command line tools to suspend and hibernate computer that can be used to run vendor or distro supplied scripts on suspend and resume. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian cares more about documents than people
On Thu, 21 Sep 2006 10:45:06 -0500 "alfredo diega" <[EMAIL PROTECTED]> wrote: > Lastly, suspend doesn't work with Debian but does with Dapper. What kind of suspend? suspend-to-ram (S3), (user space) software suspend to disk? How do you trigger it? FWIW, the kernels in dapper and unstable both have the possibility to suspend (to ram and disk). Suspend to disk should mostly works on PC-hardware. Suspend to ram is a bit more tricky, but I think ubuntu has the same software as debian, in this case. I could be however, that ubuntu installs packages by default which debian doesn't. grts Tim signature.asc Description: PGP signature
Re: Creating packages with debconf
On Mon, 18 Sep 2006 13:54:40 + (GMT) Rodrigo Tavares <[EMAIL PROTECTED]> wrote: > Hello Tim, > > Yes I read this link, and i take a example of > changelog. After, the error messange was the same. > Then i try the below command. > > sky:~/script-gera-db-1.4# dh_gencontrol > dh_gencontrol: Compatibility levels before 4 are > deprecated. > found eof where expected more change data or trailer > at /usr/lib/dpkg/parsechangelog/debian line 156, > line 5. > dpkg-gencontrol: error: syntax error in parsed version > of changelog at line 0: empty file > dh_gencontrol: command returned error code 6528 > > How I can to resolve it ? Use dch to generate your changelog. It's better to ask these questions at [EMAIL PROTECTED], btw. And really, please read the new maintainers guide! grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Creating packages with debconf
On Mon, 18 Sep 2006 13:54:40 + (GMT) Rodrigo Tavares <[EMAIL PROTECTED]> wrote: > Hello Tim, > > Yes I read this link, and i take a example of > changelog. After, the error messange was the same. > Then i try the below command. > > sky:~/script-gera-db-1.4# dh_gencontrol > dh_gencontrol: Compatibility levels before 4 are > deprecated. > found eof where expected more change data or trailer > at /usr/lib/dpkg/parsechangelog/debian line 156, > line 5. > dpkg-gencontrol: error: syntax error in parsed version > of changelog at line 0: empty file > dh_gencontrol: command returned error code 6528 > > How I can to resolve it ? Use dch to generate your changelog. It's better to ask these questions at [EMAIL PROTECTED], btw. And really, please read the new maintainers guide! grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Creating packages with debconf
On Mon, 18 Sep 2006 11:47:34 + (GMT) Rodrigo Tavares <[EMAIL PROTECTED]> wrote: > Hello, > > I just configured the tree with debconf, by create a > package, but when i try to build a package the > makefile is required. I choose single package. > > Skipping copying to script-gera-banco-1.4.orig since > script-gera-dbar-1.4.orig exists. > Currently there is no top level Makefile. This may > require additional tuning. > You already have a debian/ subdirectory in the source > tree. dh_make will not try to overwrite anything. > > The intetion is, my package execute the script (create > bd in postgresql) and remove this script, and make > some a questions. > How I can to create Makefile in this case ? I think you're confused, you're mixing up debconf, dh_make and dpkg-buildpackage. You can use dh_make only to setup some defaults for your package-to-be, it does _not_ build a package. Have you read http://www.debian.org/doc/maint-guide/ ? I suggest you start there. grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Booting - new idea?
On Fri, 30 Jun 2006 13:25:39 -0300 "Gustavo Franco" <[EMAIL PROTECTED]> wrote: > On 6/30/06, Mike Hommey <[EMAIL PROTECTED]> wrote: > > On Fri, Jun 30, 2006 at 11:54:42AM +0200, Tim Dijkstra > > <[EMAIL PROTECTED]> wrote: > > > On Thu, 29 Jun 2006 15:14:07 -0300 > > > "Gustavo Franco" <[EMAIL PROTECTED]> wrote: > > > > > > > On 6/29/06, Christian Perrier <[EMAIL PROTECTED]> wrote: > > > > > > Software suspend which exists in kernel for several years? > > > > > > > > > > > > > > > And works properly in Debian since what? Weeks? Months?:-) > > > > > > > > It doesn't really work properly anywhere, does it? :-P > > > > > > Has worked properly here very well with suspend2, which isn't in > > > the stock kernel unfortunately. > > > > Has worked properly here very well with whatever is in the debian > > kernel, since 2.6.15 at least. > > > > Well Mike, maybe very well for you not for many users and some kernel > developers[0] agreed. Btw, Greg wrote an article for lwn (major > suspend changes), > read it there if you're subscribed. Really interesting content that > shows the current problems with the kernel implementation (up to > 2.6.17) that should be solved soon, since Linus came up with a > interesting patch. > > [0] = > http://thread.gmane.org/gmane.linux.power-management.general/1884/focus=1884 I didn't read the whole thread, but AFAICS it only talks about a (clever) hack to make debugging suspend-to-ram easier... grts Tim signature.asc Description: PGP signature
Re: code cpustat.c
On Fri, 30 Jun 2006 16:41:05 +0300 (EEST) "Ozgur Karatas" <[EMAIL PROTECTED]> wrote: > Hello, > i want to help as much as i can. i dont know very much but i want to > help debian evolve and improve myself at the same time. i am coding > small applications for this purpose. they could help some. You can read http://www.debian.org/devel/join/ and see what you can do for debian. grts Tim signature.asc Description: PGP signature
Re: code cpustat.c
On Fri, 30 Jun 2006 16:18:58 +0300 (EEST) "Ozgur Karatas" <[EMAIL PROTECTED]> wrote: > Re, > ps and top command gives the ram state. i am doing this to see cpu's > load and usage. huh? My top shows (admittedly not on my desktop machine;) shows: 15:31:22 up 50 days, 2:41, 2 users, load average: 3,81, 3,85, 3,86 75 processes: 70 sleeping, 5 running, 0 zombie, 0 stopped CPU states: cpuusernice systemirq softirq iowaitidle total 99,9%0,0%0,0% 0,0% 0,0%0,0%0,0% cpu00 100,0%0,0%0,0% 0,0% 0,0%0,0%0,0% cpu01 100,0%0,0%0,0% 0,0% 0,0%0,0%0,0% cpu02 99,8%0,0%0,2% 0,0% 0,0%0,0%0,0% cpu03 100,0%0,0%0,0% 0,0% 0,0%0,0%0,0% Mem: 15658564k av, 15618992k used, 39572k free, 0k shrd, 1138248k buff 10379544k actv, 3661724k in_d, 412448k in_c Swap: 2048276k av, 1134532k used, 913744k free 5722464k cached which will give the cpu load just fine... grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Booting - new idea?
On Thu, 29 Jun 2006 15:14:07 -0300 "Gustavo Franco" <[EMAIL PROTECTED]> wrote: > On 6/29/06, Christian Perrier <[EMAIL PROTECTED]> wrote: > > > Software suspend which exists in kernel for several years? > > > > > > And works properly in Debian since what? Weeks? Months?:-) > > It doesn't really work properly anywhere, does it? :-P Has worked properly here very well with suspend2, which isn't in the stock kernel unfortunately. Now it also works very well here with vanilla kernel 2.6.17 and the debian package for uswsusp which I've packaged. You can try them out if you like (you need a 2.6.17 kernel), http://www.famdijkstra.org/~tdykstra/debian/uswsusp But I hope they'll get uploaded very soon. grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: new tar behavior and --wildcards
On Tue, 27 Jun 2006 13:37:21 +0200 Thijs Kinkhorst <[EMAIL PROTECTED]> wrote: > On Tue, 2006-06-27 at 10:02 +0200, Pierre Habouzit wrote: > > Le lun 26 juin 2006 21:53, Petr Vandrovec a écrit : > > > Maybe it could be default for tar's POSIX mode, but I have no idea > > > why GNU mode behavior should be changed in any way. > > > > I second that. it's now completely unpossible to do basic packaging > > work, because such a change wasn't planned. I also don't find it > > wise, if we still want to release this year, to introduce such a > > change *now*. > > > > Bdale, I *really* beg you to postpone that default change post-etch. > > Is there any idea of the number of packages actually affected by this? > I've harly seen an RC bug flood arise out of this; I've only seen two, > one of which is already pending upload. Probably a few more will > arise, but the fix is trivial. > > So I wonder if it would be useful to revert the change, since we have > to change at some point and at this point the effects do not seem to > be quite dramatic. Maybe you have signs indicating otherwise? It is also bound to break numerous private scripts on peoples systems. And for no good reason, the default has been like this for years now, why change that? For the POSIX-pedantic people there is always the POSIX mode. grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#375218: ITP: liblzf-dev -- a very small data compression library
Package: wnpp Severity: wishlist Owner: "Tim Dijkstra (tdykstra)" <[EMAIL PROTECTED]> * Package name: liblzf-dev Version : 1.51 Upstream Author : Marc Alexander Lehmann <[EMAIL PROTECTED]> * URL : http://www.goof.com/pcg/marc/liblzf.html * License : BSD/GPL Programming Lang: C Description : a very small data compression library LibLZF is a very small data compression library. It consists of only two .c and two .h files and is very easy to incorporate into your own programs. The compression algorithm is very, very fast, yet still written in portable C. I need this for static linking in the muswsusp binaries resume and suspend. That's why I only intend to provide the a liblzf-dev. The upstream author also only provides infrastructure for static linking. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (900, 'testing'), (20, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.17.1 Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to nl_NL.utf8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#375217: ITP: muswsusp -- tools to use userspace software suspend provided by the linux kernel
Package: wnpp Severity: wishlist Owner: "Tim Dijkstra (tdykstra)" <[EMAIL PROTECTED]> * Package name: muswsusp Version : 0.2 Upstream Author : Rafael J. Wysocki <[EMAIL PROTECTED]>, Pavel Machek <[EMAIL PROTECTED]> * URL : http://suspend.sf.net * License : GPL Programming Lang: C Description : tools to use userspace software suspend provided by the linux kernel µswsusp contains the programs to use the userspace software suspend facility available in linux kernel 2.6.17-rc1 and higher. It enables you to save the state of the whole system to disk and power off your system. After restarting your system it will be put back in the exact system state you left it (this is sometimes called hibernation). . It also includes an option to suspend-to-ram after the state is saved to disk. In the suspend-to-ram state the system still uses power, but is faster in resuming. In case the battery depletes the state is still on disk and resume from disk can continue without data loss. . To use this package you need a linux kernel version 2.6.17-rc1 or newer configured to use an mkinitramfs. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (900, 'testing'), (20, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.17.1 Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to nl_NL.utf8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pmount-hal hald and acl for storage media
On Tue, 20 Jun 2006 22:49:37 +0200 Johannes Zellner <[EMAIL PROTECTED]> wrote: > > Hello, > > shouldn't pmount-hal & hald respect something like > > type="bool">true or > type="bool">true > > for removable storage devices for example? > I'm not sure which would be the correct one. Anyway, apparently > there's currently no way to get removable devices with acl mounted by > hald. > > Any comments? I think the debian setup requires the user calling pmount to be in the plugdev group. grts Tim signature.asc Description: PGP signature
Re: /usr/share and -common pkgs
On Mon, 12 Jun 2006 18:18:35 +0200 Goswin von Brederlow <[EMAIL PROTECTED]> wrote: > Justin Pryzby <[EMAIL PROTECTED]> writes: > > > > > The LFS intent of separating /usr/share and /usr/lib is to allow a > > filesever to export /usr/share to machines of *any* architecture > > running the same OS (/usr is supposed to be sharable to machines of > > I think that has been nearly completly abandoned in practice. Harddisk > space is just too cheap and debian never actualy supported this on a > package manager level (e.g. let dpkg know the server has /usr/share so > skip it on extract). Hmm, that would be a nice use case for a dpkg2.0 filter... grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: final warning, /usr/doc transition mass bug filing
On Sun, 5 Mar 2006 22:40:22 -0500 Joey Hess <[EMAIL PROTECTED]> wrote: > I plan to file normal severity bugs on the following 252 packages, > which all still create /usr/doc symlinks and which don't yet have a > bug filed about this. 23 such bugs already exist in the bts. > > > Tim Dijkstra (tdykstra) <[EMAIL PROTECTED]> >digitaldj This (among other things) will be fixed in the next upload, which is in my sponsor's hands right now. grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packages file missing from unstable archive
On Fri, 11 Nov 2005 14:51:30 +1000 Anthony Towns wrote: > Anyway, if it's recompressing like I think, there's no way to get the > same compressed md5sum -- even if the information could be > transferred, there's no guarantee the local gzip _can_ produce the > same output as the remote gzip -- imagine if it had used gzip -9 and > your local gzip only supports -1 through -5, eg. We could just mandate in policy that what the gzip level is supposed to be. If we're going to do that, it's probably easier to just use --rsyncable and teach zsync to do look-in-ar instead of look-in-gz. Also we wouldn't have the md5sum problem on the data.tar.gz then. Note that I haven't tested the efficiency of --rsyncable... grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A thought about killing two bird with one stone
On Thu, 27 Oct 2005 08:57:48 +1000 Brian May <[EMAIL PROTECTED]> wrote: > > (I have seen a system that appears to run ntpdate on startup before > the network is configured - but it hasn't bothered me enough to > investigate why yet.) I had one which needed working pcmcia for the network. Pcmcia is initialized after ntpdate, which gave me the same delays. grts Tim pgpBOnlfVd3sN.pgp Description: PGP signature
Re: libnss-db and /usr/lib/* libraries
On Fri, 12 Aug 2005 10:23:41 +0200 Piotr Roszatycki <[EMAIL PROTECTED]> wrote: > On Thursday 11 of August 2005 11:35, Tim Dijkstra wrote: > > > $ ldd /usr/lib/libnss_db.so.2 | grep /usr > > > libdb-4.3.so => /usr/lib/libdb-4.3.so (0xb7e1) > > > > > > So the system can't unmount /usr partition on poweroff process. I > > > wonder if I should link statically the BDB library. The other > > > distros works that way. It might be a problem if the libdb4.3 > > > package will be updated and then the libnss-db should be > > > recompiled. Another thing is the PIC and non-PIC stuff, so I'm > > > afraid that I would need the libdb4.3-pic package which doesn't > > > exist yet. > > > > > > What do you think? > > > > This is probably bug > > > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=120340 > > Should it be fixed with replacing #!/bin/sh with #!/bin/dash > in /e/i/umountfs ? dash is optional so you can't do that anyway. > I thougt the problem was not the /e/i/umountfs but /etc/init.d/rc > script which also uses /bin/bash so /usr/lib/libdb-4.3.so library... > > If umountfs is the only blocker, it could be splitted into umountfs > and i.e. remountrootro. I think it could solve the problem. I think any bash-script running at umount time will give you this problem, so yes also rc. So only installing dash as /bin/sh will help you for sure. Anything else would be a work-a-round for #120340, which stays a bug IMHO. grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libnss-db and /usr/lib/* libraries
On Thu, 11 Aug 2005 10:17:27 +0200 Piotr Roszatycki <[EMAIL PROTECTED]> wrote: > Hi. The problem is important not only for libnss-db package but also > for libnss-ldap, libnss-mysql and others. > > $ ldd /usr/lib/libnss_db.so.2 | grep /usr > libdb-4.3.so => /usr/lib/libdb-4.3.so (0xb7e1) > > So the system can't unmount /usr partition on poweroff process. I > wonder if I should link statically the BDB library. The other distros > works that way. It might be a problem if the libdb4.3 package will be > updated and then the libnss-db should be recompiled. Another thing is > the PIC and non-PIC stuff, so I'm afraid that I would need the > libdb4.3-pic package which doesn't exist yet. > > What do you think? This is probably bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=120340 grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: More on icons for packages
On Wed, 26 Jan 2005 20:18:39 -0500 "Dale C. Scheetz" <[EMAIL PROTECTED]> wrote: > > Thus it might be even better to define a policy the following way: > > > >1. Put all XPMs for the use in Debian-Menu into > > /usr/share/menu/pixmaps > >2. Put all PNGs (and others) into /usr/share/pixmaps if they are > > intended for applications which follow freedesktop.org > > specification > > I don't really see a need for the split. All menu icons should be xpm > so any other icons are for some other purpose. I think the point is we don't want to be stuck we xpm till eternity. Especially because we have window/desktop managers that support better formats like png or svg for example and programs supplying them. grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#290362: www.debian.org: Please add Root to list of programs that cannot be packaged
On Thu, 13 Jan 2005 14:09:41 -0500 Kevin McCarty <[EMAIL PROTECTED]> wrote: > There are two problems: first, the license [1] forbids redistribution > of modified binaries without permission of the authors, which some > have argued makes it unsuitable even for non-free [2]; second, and > worse, the software contains what appears to be code derived from > cernlib (GPL) [3] and Xclass(LGPL) [4] while having a license > incompatible with either. > > [1] http://root.cern.ch/root/License.html > [2] http://lists.debian.org/debian-legal/2003/01/msg00297.html > http://lists.debian.org/debian-legal/2003/01/msg00281.html > [3] http://cernlib.web.cern.ch/cernlib/conditions.html > [4] http://xclass.sourceforge.net/ > > This is most unfortunate, since Root is a very useful tool and a > number of interesting projects are based on it, but I don't see how > Debian can legally package it, even in non-free, until upstream > changes their license. I read the threads you linked to above, but I couldn't find a reference to anybody explaining the ROOT guys what the problem is. Did anybody try, what was their response? grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Generating ~/.ssh/known_hosts from LDAP
On Mon, 15 Dec 2003 17:06:32 -0500
Clint Adams <[EMAIL PROTECTED]> wrote:
> > I couldn't find any way to authenticate db.debian.org when using
> > direct LDAP(TLS doesn't seem to be supported), but nonetheless this
> > is damn convenient.
> >
> > (requires python-ldap)
>
> Or, for people who don't want python installed.
>
[debian-known-hosts text/plain (437 bytes)]
#!/bin/zsh
for i in ${(M)${(ps:\n\n:)${"$(ldapsearc
Now what do I do if I want neither python nor zsh installed ;)
grts Tim
Re: Debian Enterprise?
On Tue, 18 Nov 2003 22:10:07 +1100 Zenaan Harkness <[EMAIL PROTECTED]> wrote: > On Tue, 2003-11-18 at 05:17, Andres Salomon wrote: > > On Mon, 17 Nov 2003 11:51:43 -0500, Matt Zimmerman wrote: > > > If the sub-project approach would mean that the new packages and > > > enhancements would be folded into Debian, then I think that is > > > definitely preferable. I do not think that basing it on testing > > > is the best approach; in my experience, enterprises prefer a > > > longer (stable) release cycle than testing's daily churn. > > > > Normally I'd agree; however, one of the issues I'm trying to resolve > > is the need for numerous backports. However, I do believe the > > subproject/kernel is a good start. I would prefer to see it based > > around testing snapshots, not necessarily testing itself. > > Is it possible to create task or meta packages that depend on specific > versions - eg. a bunch of versions as at a specific "snapshot" date of > "testing"?? I think that will give problems. If this package gets into testing then the packages which it depends on can't get any new versions into testing. If it's not in testing there's no guaranty that it's dependencies will be in the archive (precisely because new versions of package get into testing). grtjs Tim
Re: Bug#220358: ITP: mecab-ipadic -- IPA dictionary compiled for Mecab
On 14 Nov 2003 13:18:02 +0100
Henning Makholm <[EMAIL PROTECTED]> wrote:
> Scripsit Tim Dijkstra <[EMAIL PROTECTED]>
> > TSUCHIYA Masatoshi <[EMAIL PROTECTED]> wrote:
>
> > > Each User may also freely distribute the Program, whether in
> > > its original form or modified, to any third party or parties,
> > > PROVIDED that the provisions of Section 3 ("NO WARRANTY") will
> > > ALWAYS appear on, or be attached to, the Program, which is
> > > distributed substantially in the same form as set out herein
> > > and that such intended distribution, if actually made, will
> > > neither violate or otherwise contravene any of the laws and
> > > regulations of the countries having jurisdiction over the User
> > > or the intended distribution itself.
>
> > First, IANAL and not a native speaker nor a regular debian-legal
> > reader, but I can't see what is exactly nonfree in this piece of
> > licence. In my reading it just says,
>
> Apart from the "you must follow the law" clause, it also only allows
> derivates that are "distributed substantially in the same form as set
> out herein". That is a restriction on modification, which fails the
> DFSG.
Which indeed seems a restriction, but a little vague one, especially as
the first two lines read: 'Each User may also freely distribute the
Program, whether in its original form or modified, to any third party or
parties'.
But I think I agree now that the 'follow the law' stuff is a
freedom-killer in it self.
grts Tim
Re: Bug#220358: ITP: mecab-ipadic -- IPA dictionary compiled for Mecab
On Fri, 14 Nov 2003 13:44:46 +0200 David Starner <[EMAIL PROTECTED]> wrote: > > First, IANAL and not a native speaker nor a regular debian-legal > > reader, but I can't see what is exactly nonfree in this piece of > > licence. In my reading it just says, > > > > 1) Do what you want with it > > 2) Keep a NO WARRANTY section in the licence > > 3) Don't do any illegal stuff > > The last is the killer; say you're a suspected dissident that's > prohibited from using a computer or computing software, making your > copying of the software illegal. Thus after using this software send > an email to journalists revealing the ongoing genocide of your people, > and escaping to the free world, you are now open to civil prosecution > for copyright violation. It discriminates against classes of users and > thus violates the DFSG. Living in a quitte civilised country (well they're doing their best to change it, last week our prime minister was saying people really shouldn't make jokes about the royal family), I didn't think of that one... grts Tim
Re: Bug#220358: ITP: mecab-ipadic -- IPA dictionary compiled for Mecab
On Wed, 12 Nov 2003 14:12:41 +0900
TSUCHIYA Masatoshi <[EMAIL PROTECTED]> wrote:
> computational processing of Japanese texts. Unfortunately, its
> license has small violation of DFSG, as follows:
>
> Each User may also freely distribute the Program, whether in its
> original form or modified, to any third party or parties, PROVIDED
> that the provisions of Section 3 ("NO WARRANTY") will ALWAYS
> appear on, or be attached to, the Program, which is distributed
> substantially in the same form as set out herein and that such
> intended distribution, if actually made, will neither violate or
> otherwise contravene any of the laws and regulations of the
> countries having jurisdiction over the User or the intended
> distribution itself.
>
First, IANAL and not a native speaker nor a regular debian-legal reader,
but I can't see what is exactly nonfree in this piece of licence. In my
reading it just says,
1) Do what you want with it
2) Keep a NO WARRANTY section in the licence
3) Don't do any illegal stuff
grts Tim
Re: d-i milo missing (might have fix)
On Wed, 1 Oct 2003 13:01:57 -0500 Steve Langasek <[EMAIL PROTECTED]> wrote: > On Wed, Oct 01, 2003 at 10:27:01AM +0200, Tim Dijkstra wrote: > > On Tue, 30 Sep 2003 13:46:33 -0400 > > Greg Folkert <[EMAIL PROTECTED]> wrote: > > > > > > I have a DEC Alpha 1000/4 and a DEC Alpha 2100/4 (sable) that > > > could be stand a linux install on them. . > > > The 2100 would be the nasty one to get it to work on. They both > > > require milo, the sable has never booted linux "proper" ever, as > > > it's is the "early version" > > > I know next to nothing about alphas other then, that I got a > > AlphaServer 2100 4/233 from my father-in-law once. Which I installed > > debian on quite easily with aboot... > > Not that I want you not to spend time on MILO, but I thought I'd > > tell you. > > There are three reasons why using MILO may be necessary: > > - there's no version of SRM for your subarch > - you need to dual-boot with WinNT (hah!) > - you need the PC BIOS emulation features of ARC > > If none of these apply, then certainly, SRM+aboot is the way to go. Ahh, never realized somebody would want WinNT ;) thanks for the explanation, Tim
Re: d-i milo missing (might have fix)
On Tue, 30 Sep 2003 13:46:33 -0400 Greg Folkert <[EMAIL PROTECTED]> wrote: > > I have a DEC Alpha 1000/4 and a DEC Alpha 2100/4 (sable) that could be > stand a linux install on them. . > The 2100 would be the nasty one to get it to work on. They both > require milo, the sable has never booted linux "proper" ever, as it's > is the "early version" I know next to nothing about alphas other then, that I got a AlphaServer 2100 4/233 from my father-in-law once. Which I installed debian on quite easily with aboot... Not that I want you not to spend time on MILO, but I thought I'd tell you. grts Tim
Re: Accepted galeon 1.3.7.20030825-1 (i386 source)
On Wed, 27 Aug 2003 16:50:28 +0200 [EMAIL PROTECTED] (Dagfinn Ilmari Mannsåker) wrote: > That's over two months (and two releases) old. The current galeon in > unstable is 1.3.7.20030813-1, which has the "Add bookmark to" submenu > at the top of the bookmark menu. Huh?!? well I must be blind then... ii galeon 1.3.7.20030813-1 GNOME web browser for advanced users And I don't see no "Add bookmark to"-submenu. Are you sure you didn't do any manual tweeking of some configuration file? grts Tim
Re: [custom] Some issues for custom debian distributions
On Fri, 25 Jul 2003 18:28:27 +0200 Tore Anderson <[EMAIL PROTECTED]> wrote: > * Petter Reinholdtsen > > > - Preconfigure the packages we install > > > > I believe the best option would be to extend all the packages > > we use to make it possible to configure everything we need > > using debconf answers. > > God, No! There's far too many Debconf questions being asked by > various Debian packages already, IMNSHO. > > If something like this should be implemented, I'd like to see these > questions only be asked at reconfigure time, or not asked at all. > That way Skulelinux could preseed the Debconf database and get the > package working the way you want, while I can install Debian without > going nuts about all the questions I'm asked. > If is debconf used 'the right way' (tm) it is only a blessing. The only thing maintainers should do is assign the right priority to a question (Well and of course take care that all changes to configuration files are preserved). That way people that want automation or just like questions get what they want and people that want to rewrite configuration files just set a high priority and get a nice and quite apt-get update/install. grts Tim
Re: [OT] Storms (Re: Do not touch l10n files (was Re: DDTP issue))
On Wed, 14 May 2003 09:28:53 +0200 Martin Godisch <[EMAIL PROTECTED]> wrote: > On Wed, May 14, 2003 at 09:02:20 +0200, Javier Fernández-Sanguino Peña > wrote: > > > "Tormenta en un vaso de agua" in Spanish. So it seems that french > > and spanish drink more water than tea. > > "Sturm im Wasserglas" in German. ;-) "Storm in een glas water" in Dutch. Tim
Re: location of UnicodeData.txt
On Thu, 28 Nov 2002 17:57:35 +0200 Richard Braakman <[EMAIL PROTECTED]> wrote: > On Thu, Nov 28, 2002 at 02:58:38PM +0100, Tim Dijkstra wrote: > > > UnicodeData is different, because we need the data in our program, > > > not only the ideas. And it this case we see that as software! > > > > Maybe you're right that we don't really need the rfc's in main. They > > actually are now and it would be a shame if we dropped them. But we > > need files like this unicode file in main, which is part of a > > specification(I think), so can't be altered. > > But do you think it's _okay_ for such a file not to be free? (Whether > it actually is or not is a topic for debian-legal). > What I mean to say is that it's useless to demand that you can modify a 'standard', so yes, I think it's OK that it is DSFG non-free. What is the use of changing this unicode table, but not telling the rest of the world? grts Tim
Re: location of UnicodeData.txt
On Thu, 28 Nov 2002 13:55:31 +0100 Giacomo Catenazzi <[EMAIL PROTECTED]> wrote: > No, we can live without standard in main. I never read ISO C and POSIX > standards (because these was non free (like free beer)). But > I program GNU/Linux in C. Also the RFC are not enough free, but I see > no problem readint it in non-free. > > It would better to have those standard in 'main' and to be able > to modify (translate, correct, collect, simplify,..), but yet... There is no use in changing standards without agreeing on it in some forum. > UnicodeData is different, because we need the data in our program, > not only the ideas. And it this case we see that as software! Maybe you're right that we don't really need the rfc's in main. They actually are now and it would be a shame if we dropped them. But we need files like this unicode file in main, which is part of a specification (I think), so can't be altered. grts Tim
Re: location of UnicodeData.txt
On Wed, 27 Nov 2002 16:53:00 -0500 Branden Robinson <[EMAIL PROTECTED]> wrote: > On Wed, Nov 27, 2002 at 04:23:51PM -0500, Jim Penny wrote: > > > I see no problem with this license as far as it goes, but it > > > doesn't go far enough. > > > > > > There is no permission granted to make modifications (and > > > distribute modified versions). (DFSG 3) > > > > So, according to Branden, international standards are supposed to > > allow debian the right to modify them and to distribute the modified > > versions. > > No, international standards can say whatever they want, and bear > whatever license the standards organization wants, within the law. > > Debian has its Free Software Guidelines and we do not, in theory, > apply them differently based on who the licensor is. > So doesn't this mean it's time to change the social contract or the DFSG (are standards software?) to make an exception for 'documents and files describing standards'. It's clear that we can't live without them (hence should be in main), and it is also clear there is no use in changing standards on you're own. And no I can't make an amendment, I'm not a DD. Tim
