Re: Bug#391246: general: Buildds should consider changing $HOME
Mike Hommey <[EMAIL PROTECTED]> wrote: > On Wed, Oct 11, 2006 at 07:55:54AM +0200, Frank Küster <[EMAIL PROTECTED]> > wrote: >> Yes, that's the ideal solution. In the real world, my suggestion may >> improve the situation faster. >> >> Just got an other idea, slower too, but makes the "ideal solution" more >> realistic: Someone writes a tool analogous to piuparts, but not for >> install/upgrade, but for package building. This tool would check >> whether any tool used in the build process does nasty things, like >> accessing $HOME, communicating over the network, assuming existence of >> particular files in /sys or /proc, and the like. > > Something similar should be done with package installations... I hate > that my /root is cluttered with .gconf, .anthy, .gnome, .gnupg, .qt ... > while I never run that kind of software as root... This could be done inside piuparts, couldn't it? Or isn't that kind of behavior already checked, since piuparts complains about all leftover files on the system? Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Bug#392291: ITP: mooedit -- a useful programming and around-programming text editor
Package: wnpp Severity: wishlist Owner: alex bodnaru <[EMAIL PROTECTED]> * Package name: mooedit Version : x.y.z Upstream Author : Name <[EMAIL PROTECTED]> * URL : http://www.example.org/ * License : (GPL, LGPL, BSD, MIT/X, etc.) Programming Lang: (C, C++, C#, Perl, Python, etc.) Description : a useful programming and around-programming text editor (Include the long description here.) mooedit is a text editor. Started originally as a simple built-in editor component in GGAP, it grew up to a real text editor. The intention now is to make it a useful programming and around-programming text editor. Features * Configurable syntax highlighting. * Configurable keyboard accelerators. * Multiplatform - works both on unix and windows. * Plugins: can be written in C or Python. * Configurable tools available from the main and context menus. They can be written in Python, or it can be a shell script, or in MooScript - simple builtin scripting lanugage. * Regular expression search/replace, grep and find frontends, builtin file selector and whatnot. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-skas3-v8.2 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#391246: general: Buildds should consider changing $HOME
On Wed, Oct 11, 2006 at 07:40:42AM +0200, Frank Küster wrote: > Of course the clean solution would be to signal to the tools not to look > and write into HOME, but it's hardly realistic to assume that all tools > used (an ever increasing and changing set) will always follow such a > rule. Therefore the idea to change HOME to something in the build > directory. Maybe just unsetting it might do as well. The default configuration on buildd is to set $HOME to a directory that does not exist... -- Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22
Re: Bug#391246: general: Buildds should consider changing $HOME
Le mercredi 11 octobre 2006 à 08:20 +0200, Mike Hommey a écrit : > Something similar should be done with package installations... I hate > that my /root is cluttered with .gconf, .anthy, .gnome, .gnupg, .qt ... > while I never run that kind of software as root... As for .gconf, GConf schemas are now registered with a temporary $HOME, therefore it should currently not be created anymore. As for .gnome2, it may be created by some software gaining root privileges, like gnome-system-tools, but I don't know any standard GNOME postinst actions that could create it. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: apt-findremovable v0.1 (initial release)
On Sat, Oct 07, 2006 at 06:32:08PM +0200, Michelle Konzack wrote: > Am 2006-10-06 18:06:47, schrieb Mikhail Gusarov: > > Do aptitude checks terminal even for 'aptitude install' or 'aptitude > > search'? > > Good question! The two offending Servers use Monocrom-Graficcards. > Maybe aptitude can not enter a colormode and crash? How can that interfere with the ssh tunnel? Ionut -- signature.asc Description: Digital signature
Re: Packages up for adoption
* Steve Kemp ([EMAIL PROTECTED]) : > I've recently orphaned all my packages whilst being on a > bit of hiatus from project work. [...] > Several packages are still unclaimed, although people have > offered on some of them. Please take a look at the list if > you're interested: [...] >* libcgi-session-expiresessions-perl[O] As a member of the Debian Perl Group, I suggest that we adopt that one. If nobody disagrees, I'm going to adopt the package for the Perl Group. Cheers, -- Alexis Sukrieh [EMAIL PROTECTED] 0x1EE5DD34[EMAIL PROTECTED] The real glory of maintainership isn't making the big and important decisions. The real glory lies in all the small stuff that doesn't really matter, and that people will just argue forever. -- Linus Torvalds -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Call for votes for "GR: : Handling source-less firmware in the Linux kernel"
On Sat, Oct 07, 2006 at 06:52:41PM -0500, Debian Project Secretary wrote: > - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- > c2d43675-9efa-4809-a4aa-af042b62786e > [ ] Choice 1: Release Etch even with kernel firmware issues Manoj, you have again overstepped your Secretarial position, by issuing a misleading title for the proposal you propose. The proposal of Frederik would have allowed etch to release, while the one amended by you, will cause more problems that it solves, in particular it will mean many firmwares will have to go, among them the tg3 one, and so we either drop support for the users of those hardware (and there was general outcry for this one, even inside the kernel team when this was first proposed), or we delay etch until the d-i folk get the support for non-free firmware going. So, given this poorly worded ballot, i suppose the vote will be void anyway, and i strongly call for everyone to vote further discussion over the other solutions. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian GNU/Minix?
Le mardi 10 octobre 2006 à 19:22 +0200, HXC a écrit : > I am wondering if it is possible to use the Minix kernel in Debian. If > so wouldn't that be an interesting project to release a Debian minix > version? (just like Debian BSD and Debian Hurd :-) ) A first thing to do, to see if this is possible at all, would probably be to port the GNU libc to Minix, as many things in Debian are relying on this libc. This is what has boosted the FreeBSD port to the point of usability. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Bug#391246: general: Buildds should consider changing $HOME
Wouter Verhelst <[EMAIL PROTECTED]> wrote: >> Steve Langasek <[EMAIL PROTECTED]> wrote: >> >> > On Wed, Oct 04, 2006 at 09:32:16AM +0200, Frank Küster wrote: >> > >> > > However, I'd like to point out that this problem is not special to TeX. >> > > Many programs create ~/.progname directories when run for the first time >> > > - and these directories contain configuration options which might cause >> > > trouble, since they are not updated or subject to dpkg conffile >> > > questions when the package changes configuration options. It might be a >> > > good thing to require such tools to have a commandline switch or obey a >> > > commandline variable that prevents this. Alternatively, HOME could be >> > > set to the temporary build directory, so that everything happens there. > > Even more alternatively, these tools should not fail horribly when > writing to directories in $HOME seems impossible for some reason. That > falls under 'standard good programming practices'. This misses the point. Of course no build process may fail if writing to $HOME is impossible, and if they do they have a RC bug. There's a different issue, though: Many tools create a user-specific configuration or preferences directory in $HOME when they are first used. The problem with that is that these files override the configuration in /etc/, but are not subject to dpkg conffile handling. As a result, a tool on a buildd might use settings that were the default in a previous version, but are now suboptimal. Of course the clean solution would be to signal to the tools not to look and write into HOME, but it's hardly realistic to assume that all tools used (an ever increasing and changing set) will always follow such a rule. Therefore the idea to change HOME to something in the build directory. Maybe just unsetting it might do as well. Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
gdm/Gnome/KDE and device permissions
Dear DDs & D-friends,
what is the standard/canonical way of handling device permissions
in Debian ("etch" in my case) on desktop PCs running a GUI?
It seems that users have to be added to group "audio"
in order to be able to access audio devices, group "video" to access
video devices, "cdrom" to access cdrom, and so on. Or did I miss some
setting during installation of etch?
Having to add users to particular groups is not reasonable in a
desktop setting. There, one would like to have the current user
at the console (logged in via gdm or similar) to be the one with
exclusive rights on local devices (fixed ones like audio and video
as well as variable ones like external usb devices).
Part of the problem can be solved by using libpam-permdev:
it handles well fixed builtin devices like audio, video, cdrom,
but fails with dynamic devices like usb sticks (the pam module
is only active during login and therefore misses dynamic devices
plugged in during the session).
Moreover, since the module is not installed automatically with gdm,
it doesn't seem to be the intended solution.
For dynamic devices I haven't found a solution yet. Autodetection
and automounting of e.g. usb sticks works with gnome, if there are
entries in /etc/fstab. However, such entries are not reasonable
since one doesn't know in advance which devices are plugged in
in which order. I found some hints on the web how to use udev
hooks and events, but I suppose there are already ready-to-use
solutions somewhere hidden in Debian.
I'd appreciate any hints. Thanks in advance, and thanks for reading
this far,
Gernot
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gdm/Gnome/KDE and device permissions
On Wed, 11 Oct 2006 13:08:27 +0200, Gernot Salzer wrote: > It seems that users have to be added to group "audio" > in order to be able to access audio devices, group "video" to access > video devices, "cdrom" to access cdrom, and so on. Or did I miss some > setting during installation of etch? > > Having to add users to particular groups is not reasonable in a > desktop setting. There, one would like to have the current user > at the console (logged in via gdm or similar) to be the one with > exclusive rights on local devices (fixed ones like audio and video > as well as variable ones like external usb devices). I don't think it's possible to arrange for _exclusive_ access. Once a user has been granted access to a group it is not really possible to revoke the grant. > Part of the problem can be solved by using libpam-permdev: > it handles well fixed builtin devices like audio, video, cdrom, > but fails with dynamic devices like usb sticks (the pam module > is only active during login and therefore misses dynamic devices > plugged in during the session). > Moreover, since the module is not installed automatically with gdm, > it doesn't seem to be the intended solution. There is also pam_group which seems to do the same thing--adds users to groups depending on their name, login method and time of day. > For dynamic devices I haven't found a solution yet. Autodetection > and automounting of e.g. usb sticks works with gnome, if there are > entries in /etc/fstab. However, such entries are not reasonable > since one doesn't know in advance which devices are plugged in > in which order. 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. 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. -- Sam Morris http://robots.org.uk/ PGP key id 1024D/5EA01078 3412 EA18 1277 354B 991B C869 B219 7FDB 5EA0 1078 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: apt-findremovable v0.1 (initial release)
On Thu, 05 Oct 2006, Jan Kechel wrote: > Brian May wrote: > >> "Jan" == Jan Kechel <[EMAIL PROTECTED]> writes: > > > > > > Jan> I wrote a little perl-script: > > > > How does this compare with deborphan? > > > > deborphan shows you the 'leave' packages of your dependency-tree > > apt-findremovable checks for a given leave what else can be removed if > you removed that leave Ever tried the simulate button in the orphaner frontend? I don't know apt-findremovable's UI but I very much like orphaner's. But then I might be just slightly biased. :) Peter -- | .''`. ** Debian GNU/Linux ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `-http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: apt-findremovable v0.1 (initial release)
Peter Palfrader wrote: > Ever tried the simulate button in the orphaner frontend? I don't know > apt-findremovable's UI but I very much like orphaner's. But then I > might be just slightly biased. :) don't care about apt-findremovable anymore, debfoster does it's job much better :) > Peter Jan signature.asc Description: OpenPGP digital signature
Re: gdm/Gnome/KDE and device permissions
> > Having to add users to particular groups is not reasonable in a > > desktop setting. There, one would like to have the current user > > at the console (logged in via gdm or similar) to be the one with > > exclusive rights on local devices (fixed ones like audio and video > > as well as variable ones like external usb devices). > > I don't think it's possible to arrange for _exclusive_ access. Once a > user has been granted access to a group it is not really possible to > revoke the grant. 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. > There is also pam_group which seems to do the same thing--adds users to > groups depending on their name, login method and time of day. Thanks for the hint, I will check it. > 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? > 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. 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", ...? 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? Gernot -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#392315: ITP: datrie -- Double-array trie library
Package: wnpp Severity: wishlist Owner: Theppitak Karoonboonyanan <[EMAIL PROTECTED]> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: datrie Version : 0.1.0 Upstream Author : Theppitak Karoonboonyanan <[EMAIL PROTECTED]> * URL : http://libthai.sourceforge.net/ * License : LGPL Programming Lang: C Description : Double-array trie library Trie is a kind of digital search tree, an efficient indexing method with O(1) time complexity for searching. Comparably as efficient as hashing, trie also provides flexibility on incremental matching and key spelling manipulation. This makes it ideal for lexical analyzers, as well as spelling dictionaries. . This is an implementation of double-array structure for representing trie, as proposed by Junichi Aoe. The details of the implementation can be found at http://linux.thai.net/~thep/datrie/datrie.html . Homepage: http://libthai.sourceforge.net/ - -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17 Locale: LANG=th_TH.UTF-8, LC_CTYPE=th_TH.UTF-8 (charmap=UTF-8) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFLKUtqgzR7tCLR/4RAqtSAJ9DmaDeupHJYblddQV1Zrpu6gOrjQCfZkUp 4Gua436msy4UWK1s1z47Yn8= =i+8l -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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]
Bug#391246: general: Buildds should consider changing $HOME
Wouter Verhelst <[EMAIL PROTECTED]> wrote: > On Wed, Oct 11, 2006 at 07:40:42AM +0200, Frank Küster wrote: >> Of course the clean solution would be to signal to the tools not to look >> and write into HOME, but it's hardly realistic to assume that all tools >> used (an ever increasing and changing set) will always follow such a >> rule. Therefore the idea to change HOME to something in the build >> directory. Maybe just unsetting it might do as well. > > The default configuration on buildd is to set $HOME to a directory that > does not exist... Not on the alpha, mips and mipsel buildds that revealed our bug, http://bugs.debian.org/388399. If the buildds consequently set HOME to a nonexistent directory, this would solve this bug as well, but they don't currently. That's why this bug is open. Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: gdm/Gnome/KDE and device permissions
> 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 ?
> 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,
it would be most useful to be able to install a package that sets up
the computer for this special case
such that people can work under gnome/kde like they are used to from
windows or mac-os. This includes to be able to access devices easily,
but without being pried upon by curious (but otherwise friendly and
non-hacker) remote users.
> 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.
> 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
> 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.
Thanks, I'll check it.
> 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.
Good to know. So I'm not wasting time when constructing a (simple) solution
for my situation.
Gernot
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#392333: ITP: irrtoolset -- IRRToolSet is a suite of policy analysis tools to operate with routing policies in RPSL [RFC 2622] format, registered in Internet Routing Registry(IRR).
Package: wnpp Severity: wishlist Owner: Jan Wagner <[EMAIL PROTECTED]> * Package name: irrtoolset Version : 4.8.4 Upstream Author : Joao Damas <[EMAIL PROTECTED]> * URL : http://www.isc.org/index.pl?/sw/IRRToolSet/ * License : 3-clause BSD with non-commercial only restriction Programming Lang: Description : IRRToolSet is a suite of policy analysis tools to operate with routing policies in RPSL [RFC 2622] format, registered in Internet Routing Registry(IRR). The "Internet Routing Registry Toolset" (IRRToolSet) project is a new activity proposed by the RIPE NCC. This project has been migrated from the USC Information Sciences Institute, where it was developed in 1997-2001 as the "Routing Arbiter ToolSet" (RAToolSet) project. As the RAToolSet is no longer developed by ISI but is used worldwide, the RIPE NCC proposed to migrate this project to the RIPE NCC in order to continue its development and support. The original name of the project was preserved during the transition process, but has been finally changed to IRRToolSet. Currently, the RIPE NCC has transfered mainteinance of this toolset to ISC, who will be accepting code from the community and providing code mainteinance. . IRRToolSet is a suite of policy analysis tools to operate with routing policies in RPSL [RFC 2622] format, registered in Internet Routing Registry (IRR). The main goal of the project is to make routing information more convenient and useful for network engineers, by providing tools for automated router configuration, routing policies analysis, and maintenance. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-2-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: anticipating the upstart migration
Eric Dorland <[EMAIL PROTECTED]> writes: >> - If you set up the alternatives in preinst, then there is a time when >> the symlink exists but the pointed binary hasn't been unpacked yet -> >> unbootable system. >> - If you set up the alternatives in postinst, there is a time when there >> is no /sbin/init at all -> unbootable system. > > The second case is only true if the init providing packages conflict > with each other, which I don't think would necessarily be the case. It would also be true if the admin chooses to deinstall tho old package and install the new package at the same time. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#392333: ITP: irrtoolset -- IRRToolSet is a suite of policy analysis tools to operate with routing policies in RPSL [RFC 2622] format, registered in Internet Routing Registry(IRR).
On Oct 11, Jan Wagner <[EMAIL PROTECTED]> wrote: > * Package name: irrtoolset Do you actually /use/ it? The precedent version used to reliably segfault when I tried to process non-trivial configurations. > The "Internet Routing Registry Toolset" (IRRToolSet) project is a new The package history has no place in the Description field anyway. -- ciao, Marco signature.asc Description: Digital signature
support of aoe devices and aoetools package
Debian Developers, I hope this is the right forum to express this idea. I have not received any feedback from the maintainer of the aoetools package, so I wanted to voice my concerns over that package in front of a wider audience as I don't want to see the aoetools ship in the crappy form in which they now exist for Etch. I have sent many messages to bugs and received little to no correspondence from the maintainer. First of all, the implementation aoetools include to enable mounting the aoe devices at boot time is severely lacking. This support was implemented in response to bug #387552 [1], which is now closed. They depend on a filesystem argument in fstab called _netdev, and they do not work with lvm (or any other dev mapper based system) at all as far as I can tell. I contributed a new init script [2] that attempts to address these shortcomings while removing the need for the special fstab option. I submitted this info to bug #387552, but have received no response yet. I was tempted to reopen the bug, but I didn't think that'd be proper. I have also CCed the maintainer on all mailings to make sure that he got it. I am basically writing here to see what I can do to at least get someone to look over the idea presented in the script to see if they think it would be a good idea. It is also frustrating to not receive any response when I clearly have a personal stake in this matter (that being that I have to support aoe based hardware). wt [1]http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=387552 [2]http://bugs.debian.org/cgi-bin/bugreport.cgi/etc.tar.gz?bug=387552;msg=20;att=1 wt -- Warren Turkal, Research Associate III/Systems Administrator Colorado State University, Dept. of Atmospheric Science -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Report debian-devel-digest
Hey, If you need instant finances to do with any way you like, here are our endeavors 200K at 4.78 % 556K at 5.46 % 612K at 4.24 % http://geocities.com/Combs6_s941/ Goodbye, Sanction Administrator Adam Mertens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Making SELinux standard for etch
Ian Jackson wrote:
> Furthermore, the SELinux patches I have seen in various applications
> have given me an extremely poor impression of the code quality[1].
> This will probably extend to other areas of SELinux.
>
> I say, ditch SELinux.
>
> Ian.
>
> [1] Here's just one example, from src/archives.c in dpkg:
>
> #ifdef WITH_SELINUX
> /*
> * if selinux is enabled, restore the default security context
> */
> if (selinux_enabled > 0)
> if(setfscreatecon(NULL) < 0)
> perror("Error restoring default security context:");
> #endif /* WITH_SELINUX */
>
> Error checking ? We don't need no steenking error checking, this is
> SECURITY software ! Quick, dump your brains and deploy it !
Without checking these functions for what they return its hard to say
how bad this is, but it does look like its checking the return values
for an error (albeit not doing anything other than printing a message).
Without more context its impossible to say whether not resetting the
default security context is bad or not.
Matt.
Send instant messages to your online friends http://uk.messenger.yahoo.com
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: anticipating the upstart migration
Henrique de Moraes Holschuh wrote: > On Mon, 09 Oct 2006, Gabor Gombas wrote: >> On Sun, Oct 08, 2006 at 10:53:39PM -0300, Henrique de Moraes Holschuh wrote: >>> No wrappers for the single most critical binary in a Unix system after the >>> libc. Sorry. >> Right. How about upstart not providing a /sbin/init binary at all, but >> instead using an "init=/sbin/upstart" boot parameter? The other binaries > > That may be ugly, but it is safe if done right. I would have little > against it as a stopgap measure for Etch/Etch+1. > Having the "init" binary installed as /sbin/upstart and only diverting the not so critical binaries seems to be the safest option indeed. The only problem I see, is that someone might forget to update /boot/grub/menu.lst (or lilo.conf) and set init=/sbin/upstart. I could use a debconf message and/or provide a README.Debian, but people are known to ignore such hints. This would mean, people would boot into a system with a mix of upstart's support binaries and init from sysvinit. As I want to avoid this potential problem, I think it's best, if upstart simply diverts all conflicting binaries from sysvinit. The only critical timespan will be between preinst and the upstart package being unpacked. This risk is acceptable to some extent, especially as you'd still be able to boot with init=/sbin/init.sysvinit, should the machine crash in between. So, with all the concerns raised so far, I'd propose the following: 1.) Remove "Conflicts/Replaces: sysvinit" from the upstart package. Divert all conflicting binaries from sysvinit and upload the package to experimental to give it some wider testing first. 2.) If no major problems are found, upload it to unstable after some time (weeks/months?). 3.) In the meantime work on a solution for the sysvinit-being-essential problem. Either by introducing a new essential package or through other means. This would happen after etch is released. 4.) Upload a version of upstart which removes the diversions again [*] and replaces sysvinit (meaning, sysvinit is uninstalled upon installation of upstart) Does that sound like an acceptable plan? Cheers, Michael [*] How can I get rid of a diversion again cleanly, without having to carry preinst around forever with something like: if dpkg --compare-versions $old_version lt $version_without_diversions; then remove_old_diversions fi -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: anticipating the upstart migration
* Matthias Julius ([EMAIL PROTECTED]) wrote: > Eric Dorland <[EMAIL PROTECTED]> writes: > > >> - If you set up the alternatives in preinst, then there is a time when > >> the symlink exists but the pointed binary hasn't been unpacked yet -> > >> unbootable system. > >> - If you set up the alternatives in postinst, there is a time when there > >> is no /sbin/init at all -> unbootable system. > > > > The second case is only true if the init providing packages conflict > > with each other, which I don't think would necessarily be the case. > > It would also be true if the admin chooses to deinstall tho old > package and install the new package at the same time. Sure, but then they are explicitly taking that risk. -- Eric Dorland <[EMAIL PROTECTED]> ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 signature.asc Description: Digital signature
Re: anticipating the upstart migration
Eric Dorland <[EMAIL PROTECTED]> writes: > * Matthias Julius ([EMAIL PROTECTED]) wrote: >> Eric Dorland <[EMAIL PROTECTED]> writes: >> >> >> - If you set up the alternatives in preinst, then there is a time when >> >> the symlink exists but the pointed binary hasn't been unpacked yet -> >> >> unbootable system. >> >> - If you set up the alternatives in postinst, there is a time when there >> >> is no /sbin/init at all -> unbootable system. >> > >> > The second case is only true if the init providing packages conflict >> > with each other, which I don't think would necessarily be the case. >> >> It would also be true if the admin chooses to deinstall tho old >> package and install the new package at the same time. > > Sure, but then they are explicitly taking that risk. Yes, but probably without being aware of it. How do you tell them about it before the old init package is removed? Matthias -- 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]
Returned mail: Data format error
The original message was received at Wed, 11 Oct 2006 15:25:20 +0200 from dgp.ro [175.6.114.244] - The following addresses had permanent fatal errors - debian-devel@lists.debian.org
Re: gdm/Gnome/KDE and device permissions
On Wednesday 11 October 2006 14:12 pm, Gernot Salzer 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. That doesn't prevent a user from e.g. writing a program to keep /dev/dsp open after logout and then on request play a sound clip designed to embarrass the current user. -- Daniel Schepler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Critical news for lists.debian.org consumers
Attention, Do you need immediate capital to utilize any way you like, here are our suggestions 295K at 4.89 % 464K at 4.30 % 745K at 4.46 % http://geocities.com/Kyle51_u171/ Thanks Alot, Robbie Jones -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: anticipating the upstart migration
On Oct 11, Michael Biebl <[EMAIL PROTECTED]> wrote: > Having the "init" binary installed as /sbin/upstart and only diverting > the not so critical binaries seems to be the safest option indeed. I had to use many diverions in the module-init-tools package because there was no other acceptable solution, and it's not pretty. Please do not accept to be defeated yet, diversions are only a workaround which makes maintaining the package much more complex (look at the list of diversions-related bugs in the m-i-t changelog...). > 2.) If no major problems are found, upload it to unstable after some > time (weeks/months?). I do not think that an upstart package using diversions should ever be uploaded to unstable, and definitely not enter stable. -- ciao, Marco signature.asc Description: Digital signature
Re: Allowing @ in user names?
* Roberto C. Sanchez: > Then, I guess the relevant question has to do with whether or not > adduser (and the rest of the components that touch or use the username) > are RFC2822 compliant. Most certainly they are not. Embedded NUL characters are allowed in local-parts. I don't think this is a problem (apart from the fact that the internet will be secure once you can send mail to <"\Trouble? Contact [EMAIL PROTECTED]
ppp: co-maintainer and urgent help needed
I will not be able to spend much time on the ppp package before the release, so I am requesting help in triaging and fixing as many bugs as possible (the list is long, but let's only consider the ones opened this year) and uploading a new package ASAP. There is nothing actually *terrible* in the package, but it could use some work. Applications for co-maintainership are also encouraged. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: anticipating the upstart migration
Eric Dorland writes ("Re: anticipating the upstart migration"):
> Shouldn't it be possible to move the alternatives around in an atomic
> fashion? ln -sf bar foo.tmp ; mv foo.tmp foo . Or am I missing
> something?
This is in theory possible, I suppose. You would have to avoid
update-alternatives --rename and do half of it manually and take
extraordinary care.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Call for votes for "GR: : Handling source-less firmware in the Linux kernel"
Sven Luther <[EMAIL PROTECTED]> writes: > So, given this poorly worded ballot, i suppose the vote will be void anyway, > and i strongly call for everyone to vote further discussion over the other > solutions. If people do not READ THE RESOLUTION, then they get what they deserve. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Non-free IETF RFC/I-Ds in source packages
Gervase Markham <[EMAIL PROTECTED]> writes: > Simon Josefsson wrote: >> http://wiki.debian.org/NonFreeIETFDocuments > > A useful thing to add to that page would be simple instructions on how > those authoring IETF documents could make them available under a > DFSG-free licence (presumably in parallel to the IETF one) - perhaps > some sample boilerplate text to include. Good idea! I've added two new sections to the wiki page: 1. Template for license to include in RFCs. [1] 2. Template for e-mail to request additional rights from RFC authors. [2] The text is just in draft form, so please review it. Possibly, we could use something simpler in [2], or even in [1] too. /Simon [1]: x. Copying conditions The author(s) agree to grant third parties the irrevocable right to copy, use and distribute the work, with or without modification, in any medium, without royalty, provided that, unless separate permission is granted, redistributed modified works do not contain misleading author, version, name of work, or endorsement information. [2]: Subject: Requesting additional rights to RFC Dear Author, The Debian GNU/Linux distribution wishes to incorporate the IETF RFC as part of its distribution, and to allow users to develop, modify and evolve the document. Because the authors of contributions to the IETF standards retain most intellectual property rights with respect to such contributions under IETF policies in effect during the development of RFC , and because you are an author of said document, the Debian community hereby requests that you kindly agree to release your contributions in RFC under the license below, for inclusion in Debian. I agree to grant third parties the irrevocable right to copy, use and distribute the work, with or without modification, in any medium, without royalty, provided that, unless separate permission is granted, redistributed modified works: (a) do not contain misleading author, version, name of work, or endorsement information, and (b) do not claim endorsement of the modified work by the Contributor, or any organization the Contributor belongs to, the Internet Engineering Task Force (IETF), Internet Research Task Force (IRTF), Internet Engineering Steering Group (IESG), Internet Architecture Board (IAB), Internet Assigned Numbers Authority (IANA), Internet Society (ISOC), Request For Comments (RFC) Editor, or any combination or variation of such terms (including without limitation the IETF "4 diamonds" logo), or any terms that are confusingly similar thereto, and (c) remove any claims of status as an Internet Standard, including without limitation removing the RFC boilerplate. The IETF suggests that any citation or excerpt of unmodified text reference the RFC or other document from which the text is derived. To indicate that you agree to these terms, please reply to this e-mail and quote the license above and indicate that you agree to this. If you prefer another widely recognized free license instead, such as the revised BSD license, the GPL, the MIT/X11 license, that is also fine. Sincerely yours, Simon Josefsson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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
Removing obexserver (Re: RFA: obexserver -- Receive files with OBEX protocol)
Hello! Taking this out of bug [1] and to d-d to have a more advice on the correct action to be taken (as per DevRef §5.9.2 [2]). On Wed, 11 Oct 2006 16:47:08 +0200, Michael Holzt wrote: >> Good idea, I talked with Eugeniy about that. Though, I guess the >> final decision is to the obexserver maintainer. > > Totally fine with me. Go ahead and remove obexserver from the > distribution. > >> Since my NMU on affix, when it propagates to testing, obexserver >> will be the last user of the old libopenobex-1.0-0 package: > > This is nice as well. As the maintainer agrees, we should ask for remotion of obexserver (and successively libopenobex-1.0-0, cc:ing its maintainer). While the latter has no opened bugs, the former has 4 bugs: how should we deal with them? Just close them with remotion of the package? Another question: is it worth to remove the package from etch, too? Thx, bye, Gismo / Luca Footnotes: [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=363689 [2] http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-removing-pkgs pgpzLEgjCs2cT.pgp Description: PGP signature
Request for virtual package ircd
Hello, as described in http://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt I announce here my idea of the virtual package ircd. When I count correctly are at the moment 7 different IRC-daemons in Debian and they logically conflict with each other. So I would think an official virtual package would be a fine solution. There are also IRC services which work in general with all ircds, so it would be easier if those packages also could only depend on "ircd". I file now the bug against debian-policy and say thank you in advance for your answer. Regards -- .''`. Mario Iseli <[EMAIL PROTECTED]> : :' :proud user of Debian unstable `. `'` `- Debian - when you have better things to do than fixing a system -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Call for votes for "GR: : Handling source-less firmware in the Linux kernel"
Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: > Sven Luther <[EMAIL PROTECTED]> writes: > > > So, given this poorly worded ballot, i suppose the vote will be > > void anyway, and i strongly call for everyone to vote further > > discussion over the other solutions. > > If people do not READ THE RESOLUTION, then they get what they > deserve. In a vote, those who do not read the resolution affect others who do. This is one of the benefits of a discussion period -- the opportunity to ensure people understand the resolution before voting. -- \ "Saying that Java is nice because it works on all OSes is like | `\saying that anal sex is nice because it works on all genders" | _o__) -- http://bash.org/ | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Removing obexserver (Re: RFA: obexserver -- Receive files with OBEX protocol)
Am Donnerstag 12 Oktober 2006 00:06 schrieb Luca Capello: > As the maintainer agrees, we should ask for remotion of obexserver The bug for removal is already filed: #392447 > (and successively libopenobex-1.0-0, cc:ing its maintainer) We'll see if it goes automatically. It should as the source package does not exist anymore. > While the latter has no opened bugs, the former has 4 bugs: how should we > deal with them? Just close them with remotion of the package? All should be solved with the replacement: #300908, #278609: I don't see why it shouldn't just work #294108, #230988: not an issue with the replacement > Another question: is it worth to remove the package from etch, too? AFAIK, etch will follow sid automatically. HS pgpkHgYxl8f29.pgp Description: PGP signature
Re: anticipating the upstart migration
* Matthias Julius ([EMAIL PROTECTED]) wrote: > Eric Dorland <[EMAIL PROTECTED]> writes: > > > * Matthias Julius ([EMAIL PROTECTED]) wrote: > >> Eric Dorland <[EMAIL PROTECTED]> writes: > >> > >> >> - If you set up the alternatives in preinst, then there is a time when > >> >> the symlink exists but the pointed binary hasn't been unpacked yet -> > >> >> unbootable system. > >> >> - If you set up the alternatives in postinst, there is a time when there > >> >> is no /sbin/init at all -> unbootable system. > >> > > >> > The second case is only true if the init providing packages conflict > >> > with each other, which I don't think would necessarily be the case. > >> > >> It would also be true if the admin chooses to deinstall tho old > >> package and install the new package at the same time. > > > > Sure, but then they are explicitly taking that risk. > > Yes, but probably without being aware of it. > > How do you tell them about it before the old init package is removed? Maybe some sort of prerm check, but why bother? Someone installing alternative init systems is probably knowledgeable enough. -- Eric Dorland <[EMAIL PROTECTED]> ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 signature.asc Description: Digital signature
Re: Removing obexserver (Re: RFA: obexserver -- Receive files with OBEX protocol)
Hello! On Thu, 12 Oct 2006 00:21:03 +0200, Hendrik Sattler wrote: > Am Donnerstag 12 Oktober 2006 00:06 schrieb Luca Capello: >> As the maintainer agrees, we should ask for remotion of obexserver > > The bug for removal is already filed: #392447 Oh, that's very good, I thought that a note would have been posted on the RFA bug, too ;-) >> While the latter has no opened bugs, the former has 4 bugs: how >> should we deal with them? Just close them with remotion of the >> package? > > All should be solved with the replacement: > #300908, #278609: I don't see why it shouldn't just work ^^ I've a SE K700i and can confirm that obexpushd works nicely with it (tested today). >> Another question: is it worth to remove the package from etch, too? > > AFAIK, etch will follow sid automatically. I know this, but I was wondering about the time needed to remove both packages. Anyway, just a question, nothing more. Thx, bye, Gismo / Luca pgpD8DS6ILBB0.pgp Description: PGP signature
Re: Request for virtual package ircd
Am Donnerstag 12 Oktober 2006 00:10 schrieb Mario Iseli: > as described in > http://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt > I announce here my idea of the virtual package ircd. When I count > correctly are at the moment 7 different IRC-daemons in Debian and they > logically conflict with each other. Wouldn't "relay-chat-server" or "relay-chat-daemon" be a better name. > There are also IRC services which work > in general with all ircds, so it would be easier if those packages also > could only depend on "ircd". Only if they really work with _all_ of them, even new ones. Really? HS pgpoMQmHHqo3D.pgp Description: PGP signature
Re: Request for virtual package ircd
On Oct 12, Mario Iseli <[EMAIL PROTECTED]> wrote: > as described in > http://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt > I announce here my idea of the virtual package ircd. When I count > correctly are at the moment 7 different IRC-daemons in Debian and they > logically conflict with each other. So I would think an official virtual > package would be a fine solution. There are also IRC services which work > in general with all ircds, so it would be easier if those packages also > could only depend on "ircd". Services do not need to depend on a daemon. It's not clear which problem an ircd virtual package would solve. Unless you can present a better rationale I oppose to create one. -- ciao, Marco signature.asc Description: Digital signature
Re: Bug#392315: ITP: datrie -- Double-array trie library
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/11/06 03:02, Theppitak Karoonboonyanan wrote: > Package: wnpp > Severity: wishlist > Owner: Theppitak Karoonboonyanan <[EMAIL PROTECTED]> > > > * Package name: datrie > Version : 0.1.0 > Upstream Author : Theppitak Karoonboonyanan <[EMAIL PROTECTED]> > * URL : http://libthai.sourceforge.net/ > * License : LGPL > Programming Lang: C > Description : Double-array trie library > > Trie is a kind of digital search tree, an efficient indexing method with > O(1) time complexity for searching. Comparably as efficient as hashing, > trie also provides flexibility on incremental matching and key spelling > manipulation. This makes it ideal for lexical analyzers, as well as > spelling dictionaries. > . > This is an implementation of double-array structure for representing trie, > as proposed by Junichi Aoe. The details of the implementation can be found > at http://linux.thai.net/~thep/datrie/datrie.html > . > Homepage: http://libthai.sourceforge.net/ Should the package name be libtrie? - -- Ron Johnson, Jr. Jefferson LA USA Is "common sense" really valid? For example, it is "common sense" to white-power racists that whites are superior to blacks, and that those with brown skins are mud people. However, that "common sense" is obviously wrong. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFLXTtS9HxQb37XmcRAhHPAJ9UyQg7hcvwLmdXs5eYssKQr2RaAgCgkCoK Ex9luugykqLNGmMpx+GbRAE= =pQzs -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request for virtual package ircd
Marco d'Itri wrote: > On Oct 12, Mario Iseli <[EMAIL PROTECTED]> wrote: > >> as described in >> http://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt >> I announce here my idea of the virtual package ircd. When I count >> correctly are at the moment 7 different IRC-daemons in Debian and they >> logically conflict with each other. So I would think an official virtual >> package would be a fine solution. There are also IRC services which work >> in general with all ircds, so it would be easier if those packages also >> could only depend on "ircd". I'm not sure that multiple IRC-daemons logically conflict with other, given that you can configure them to run on different ports. In fact, IIRC, I've had more than one ircd-like package installed on a single system in the past. Perhaps you could share more information about what the virtual package would allow? tony signature.asc Description: OpenPGP digital signature
Re: Removing obexserver (Re: RFA: obexserver -- Receive files with OBEX protocol)
Am Donnerstag 12 Oktober 2006 00:21 schrieb Hendrik Sattler: > > (and successively libopenobex-1.0-0, cc:ing its maintainer) > > We'll see if it goes automatically. It should as the source package does > not exist anymore. Well, it does still exist. If it does not go automatically, I'll file a new bug. HS pgpUebUUYjI4u.pgp Description: PGP signature
Re: Call for votes for "GR: : Handling source-less firmware in the Linux kernel"
Ben Finney <[EMAIL PROTECTED]> writes: > Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: > > If people do not READ THE RESOLUTION, then they get what they > > deserve. > > In a vote, those who do not read the resolution affect others who > do. This is one of the benefits of a discussion period -- the > opportunity to ensure people understand the resolution before voting. s/people/more people/ -- \ "Democracy is the art of running the circus from the monkey | `\ cage." -- Henry L. Mencken | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request for virtual package ircd
On Thu, Oct 12, 2006 at 12:38:03AM +0200, Hendrik Sattler wrote: > Wouldn't "relay-chat-server" or "relay-chat-daemon" be a better name. I think no, we also call it "httpd" and not "web-server" or "hypertext-transfer-protocol-server". > Only if they really work with _all_ of them, even new ones. Really? Yes, there are services which work with all ircds, "anope" is one of them. Poorwise it's not in Debian (anyone knows why? license issues? maybe I'm gonna have a look at it). Regards -- .''`. Mario Iseli <[EMAIL PROTECTED]> : :' :proud user of Debian unstable `. `'` `- Debian - when you have better things to do than fixing a system -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request for virtual package ircd
Mario Iseli writes: > Hello, > > as described in > http://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt > I announce here my idea of the virtual package ircd. When I count > correctly are at the moment 7 different IRC-daemons in Debian and they > logically conflict with each other. So I would think an official virtual > package would be a fine solution. There are also IRC services which work > in general with all ircds, so it would be easier if those packages also > could only depend on "ircd". > > I file now the bug against debian-policy and say thank you in advance > for your answer. Some people -- developers such as myself and some server hosting companies -- find it useful to have several ircds installed on one computer for testing purposes. Artificially introducing conflicts hurts these users. Why do you think these servers conflict with each other? There are virtual packages for many network services, but not all -- for example, there are no http-server or dns-server virtual packages. The services with virtual packages almost universally use well-known ports and (except for ftp-server) it does not make sense to run several of them on one machine. In contrast, IRC, HTTP and DNS are often running several instances on different ports or network interfaces. Which IRC services work "in general with all ircds"? Anope is the most compatible one I know, but most IRC services packages that I have seen support just one or two variants of server-to-server protocol. Michael Poole -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request for virtual package ircd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/11/06 17:50, tony mancill wrote: > Marco d'Itri wrote: >> On Oct 12, Mario Iseli <[EMAIL PROTECTED]> wrote: >> >>> as described in >>> http://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt >>> I announce here my idea of the virtual package ircd. When I count >>> correctly are at the moment 7 different IRC-daemons in Debian and they >>> logically conflict with each other. So I would think an official virtual >>> package would be a fine solution. There are also IRC services which work >>> in general with all ircds, so it would be easier if those packages also >>> could only depend on "ircd". > > I'm not sure that multiple IRC-daemons logically conflict with other, > given that you can configure them to run on different ports. In fact, > IIRC, I've had more than one ircd-like package installed on a single > system in the past. > > Perhaps you could share more information about what the virtual package > would allow? It's also possible to run multiple FTP servers, each listening on a different port, but all the packaged ftp daemons "Conflicts: ftp-server". - -- Ron Johnson, Jr. Jefferson LA USA Is "common sense" really valid? For example, it is "common sense" to white-power racists that whites are superior to blacks, and that those with brown skins are mud people. However, that "common sense" is obviously wrong. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFLX+RS9HxQb37XmcRAhoiAJ9dZSyrlMXo/hBj00KeGe2iy9RXGQCfXAvH plZVoE5N6/GDwYTkKPSTkWQ= =IWta -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request for virtual package ircd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/11/06 17:58, Mario Iseli wrote: > On Thu, Oct 12, 2006 at 12:38:03AM +0200, Hendrik Sattler wrote: >> Wouldn't "relay-chat-server" or "relay-chat-daemon" be a better name. > > I think no, we also call it "httpd" and not "web-server" or > "hypertext-transfer-protocol-server". The ftpd virtual package is ftp-server. - -- Ron Johnson, Jr. Jefferson LA USA Is "common sense" really valid? For example, it is "common sense" to white-power racists that whites are superior to blacks, and that those with brown skins are mud people. However, that "common sense" is obviously wrong. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFLX/fS9HxQb37XmcRAsS9AKCb/aCGKkbS7xwXvc2ddPbJGLGspgCcDy/z rDq/BaRPWRSR7dr7i0A4auo= =YKNi -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Making SELinux standard for etch
On Wed, 11 Oct 2006 12:20:05 +0100, Yan <[EMAIL PROTECTED]> said:
> Ian Jackson wrote:
>> Furthermore, the SELinux patches I have seen in various
>> applications have given me an extremely poor impression of the code
>> quality[1]. This will probably extend to other areas of SELinux.
>>
>> I say, ditch SELinux.
>>
>> Ian.
>>
>> [1] Here's just one example, from src/archives.c in dpkg:
>>
>> #ifdef WITH_SELINUX
>> /*
>> * if selinux is enabled, restore the default security context
>> */ if (selinux_enabled > 0) if(setfscreatecon(NULL) < 0)
>> perror("Error restoring default security context:");
>> #endif /* WITH_SELINUX */
>>
>> Error checking ? We don't need no steenking error checking, this
>> is SECURITY software ! Quick, dump your brains and deploy it !
Assuming for an instant Ian may know what he is talking about,
could an example be given about what the so called missing error
checks are, by him or anyone else who knows what he is referring to?
How would people code this differently?
So far, I think the criticism reflect more of a lack of
understanding of SELinux trhan anything else, but I would be happy if
someone could show me the error of my ways.
> Without checking these functions for what they return its hard to
> say how bad this is, but it does look like its checking the return
> values for an error (albeit not doing anything other than printing a
> message). Without more context its impossible to say whether not
> resetting the default security context is bad or not.
Since the default permissions are to deny all access, all it
means is that any special permissions accorded by policy to the
package being installed would not be set by dpkg. So the package may
not work in enforcing mode until the file system is relabelled; but
that is failing safe; if there are things wrong in the system that
dpkg can't set the initial file contexts for the packages being
installed, it is reasonable to assume that you might have to relable
your file system to recover from the error condition.
manoj
--
Fools ignore complexity. Pragmatists suffer it. Some can avoid it.
Geniuses remove it. -- Perlis's Programming Proverb #58, SIGPLAN
Notices, Sept. 1982
Manoj Srivastava <[EMAIL PROTECTED]>
Re: delay of the full etch freeze
Le Wed, Oct 11, 2006 at 06:58:55PM +0200, Andreas Barth a écrit : > > For these reasons, we are delaying the full archive freeze for a few days. > We haven't chosen a date yet, but you can still expect it to happen in > October or early November. Dear Andreas, May I suggest to delay the freeze as long as it is necessary for the packages which were uploaded to NEW before the 8th to enter in Etch if they have no bugs? The rationale is that the 8th is "old freeze deadline minus 10 days", so it was not completely unreasonnable to take this day as the deadline for having new packages in Etch. Unfortunately, the time a package stays in NEW is completely unpredictable, it has been 0-3 days most of the time, except around Debconf and this month, where is is more something like 1-3 weeks. As a consequence, packages uploaded one week before the old freeze deadline minus 10 days can not enter in Etch. With the delay, you have an opportunity to correct this "downstream". By setting the cutoff on packages uploaded before the 8th, you would ensure that the uploads were not targeted for sid only, as a migration to etch was expectable. Have a nice day, -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gdm/Gnome/KDE and device permissions
On Wed, 11 Oct 2006, Roland Mas wrote: > 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. /dev is a tmpfs and that filesystem supports ACL only in very recent kernel. IIRC it has been introduced in the (upcoming) 2.6.19. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request for virtual package ircd
On Wed, Oct 11, 2006 at 06:34:41PM -0500, Ron Johnson wrote: > It's also possible to run multiple FTP servers, each listening on a > different port, but all the packaged ftp daemons "Conflicts: > ftp-server". That is bad, IMO. (and chance to raise my opinion about virtual packages ;) ) Conflicts tag is used overmuch. Sometimes I want to have more than one ftp-server or mail-transport-agent installed but Conflicts tag does not allow that. I know that inexperienced user or admin have benefit from Conflicts (and some other tags) and virtual packages but experienced ones have problem with them. Regards -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request for virtual package ircd
On 12/10/06 at 00:10 +0200, Mario Iseli wrote: > Hello, > > as described in > http://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt > I announce here my idea of the virtual package ircd. When I count > correctly are at the moment 7 different IRC-daemons in Debian and they > logically conflict with each other. So I would think an official virtual > package would be a fine solution. There are also IRC services which work > in general with all ircds, so it would be easier if those packages also > could only depend on "ircd". Those packages should not depend on ircd anyway, because the service and the ircd can run on different systems. -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
