Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 18 Feb 2006, Josselin Mouette wrote: Come on, please stop arguing with random, unsuited comparisons, and use common sense : what's the purpose of ndiswrapper without non-free drivers to use it on? We've always put things of the like in contrib, and if we stop doing it, we can remove contrib entirely. The purpose of ndiswrapper is to run non-free Windows drivers on Linux. The same is more or less true for wine and dosemu (otherwise we would probably make a native version of said apps). Would the situation change (contrib-wise) if ndiswrapper were integrated into the kernel? Would we want to split the ndiswrapper part to contrib then? - -- - -- arthur - [EMAIL PROTECTED] - http://people.debian.org/~adejong -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFD95rRVYan35+NCKcRAk9/AKCz0PEtSLrjUfa2JHUSxFp1GC3yGwCg5gfT S18zHSeAQGSETSaZfkyPmps= =f4Pu -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Ongoing Firefox (and Thunderbird) Trademark problems
On Tue, 2005-06-14 at 19:30 +0100, Matthew Garrett wrote: > Manoj Srivastava <[EMAIL PROTECTED]> wrote: > > While this argument was indeed tempting, I think we also need > > to look at how free the resulting package is: Can a derivbative take > > any package in main, modify it, and further redistribute it? If yes, > > then the package can remain in main, and is free; if not, then the > > package is not free. > > Our users have permission to modify it and further redistribute it *as > long as they change the name*. That's a limitation we're willing to > accept for ourselves - why should it not be free enough for our users? Let's say we call it mozilla-firefox (assuming we are allowed to in the first place) and downstream (making some modifications) is not allowed to call it mozilla-firefox. If we call it debian-firefox then downstream is still not allowed (under the same conditions) to call it mozilla-firefox. The difference is not that huge to me. (but naming the package just firefox seems to me like a good idea in the first place) -- -- arthur - [EMAIL PROTECTED] - http://people.debian.org/~adejong -- signature.asc Description: This is a digitally signed message part
Re: GFDL question
On Wed, 2006-03-15 at 14:06 -0800, Thomas Bushnell BSG wrote: > Norbert Preining <[EMAIL PROTECTED]> writes: > > > Ok, there are no invariant sections, but there is (a short) front and > > back cover text. > > > > How do we proceed with these documents? > > The resolution which passed excludes documentation with front cover > texts. Read it. I re-read it, and it states: | This means that works that don't include any Invariant Sections, Cover | Texts, Acknowledgements, and Dedications (or that do, but permission | to remove them is explicitly granted), are suitable for the main | component of our distribution. -- -- arthur - [EMAIL PROTECTED] - http://people.debian.org/~adejong -- signature.asc Description: This is a digitally signed message part
Re: NMUs for Python Policy -- please hold them a little
On Fri, 2006-06-23 at 18:43 +0200, Raphael Hertzog wrote: > Yes: > http://www.ouaza.com/wordpress/2006/06/23/the-python-transition-can-continue/ > > I wonder if I should make a second announce on -devel-announce just to > make it clear to everybody. At the lease I would appreciate (as a python application package maintainer) a post to debian-python with some confirmations from the involved parties. There has been a lot of confusion and conflict as to which solution package maintainers should follow. A sign of agreement on that list would be welcome. I would like to get a warm happy feeling that I won't have to change packaging again in a few days/weeks. It would also be helpful if this document http://people.debian.org/~aba/python-policy/ (was http://people.debian.org/~piman/python-policy/ before, but I just noticed http://www.debian.org/doc/packaging-manuals/python-policy/ is also 0.4.1.0) was updated with respect to the new rules (e.g. handling of XS-Python_Version). All in all I'm glad the conflicts seem to be over and appreciate the hard work that has been put into this. -- -- arthur - [EMAIL PROTECTED] - http://people.debian.org/~adejong -- signature.asc Description: This is a digitally signed message part
Re: PAM messages on chrooted console
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > After restarting init my tty6 works, however I keep getting PAM messages > on my console such as: > PAM_unix[19031]: (login) session opened for user minghua by minghua(uid=0) > I noticed such messages go to /var/log/auth.log in my stardard > installation, however this log in chroot (/var/chroot/var/log/auth.log) > is existent but empty. I also looked at my /var/chroot/etc/syslog.conf, > but it is identical to /etc/syslog.conf. The problem is that if you want to log to files inside the chroot you should probably run a seporate syslog from inside the chroot and configure it to only listen on /dev/log (inside the chroot). Also, programs that start logging outside the chroot will continue to log to that syslog since the connection is kept open. Using netstat -a -p and lsof may give you a little more information on who is accessing what. - -- arthur - [EMAIL PROTECTED] - http://tiefighter.et.tudelft.nl/~arthur -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) iD8DBQE+2H63VYan35+NCKcRAiwuAKCDGf6Jh2XAF/VgDg9n8qBoLtRz2wCg3hD4 7dt8kHewKtnCMhSbVFpjO04= =nv6J -END PGP SIGNATURE-
Re: Debian RC System/Init Scripts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > I'm curious if there has ever been any attempt to Policyize scripts > located in init.d. Specifically requiring inclusion of such lines as > DESC="description" or NAME="name". I ask because I am doing a little bit > of work on the rc startup script. I know there is some work in lsb. See this for details: http://www.linuxbase.org/spec/refspecs/LSB_1.3.0/gLSB/gLSB/initscrcomconv.html But debian policy does not require these last time I checked. - -- arthur - [EMAIL PROTECTED] - http://tiefighter.et.tudelft.nl/~arthur -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) iD8DBQE/dhNNVYan35+NCKcRApraAKDpFqWY0FBihVX+LRlr5aEqNFXWAgCferxg asu6komiQXQ+uaPtpK6cHoE= =zn4p -END PGP SIGNATURE-
Bug#326429: ITP: webcheck -- website link and structure checker
(resent to debian-devel because evolution did not add X-Debbugs-CC header) Subject: ITP: webcheck -- website link and structure checker Package: wnpp Owner: Arthur de Jong <[EMAIL PROTECTED]> Severity: wishlist * Package name: webcheck Version : 1.9.3 Upstream Author : Arthur de Jong <[EMAIL PROTECTED]> * URL : http://ch.tudelft.nl/~arthur/webcheck/ * License : GPL Description : website link and structure checker webcheck is a website checking tool for webmasters. It crawls a given website and generates a number of reports in the form of html pages. It is easy to use and generates simple, clear and readable reports. . Features of webcheck include: * support for http, https, ftp and file schemes * view the structure of a site * track down broken links * find potentially outdated and new pages * list links pointing to external sites * can run without user intervention Webcheck (release 1.0) was in Debian before, but was removed on 2005-02-02 (orphaned on 2004-05-31, request for removal on 2004-11-02, see bug #251931) because it was no longer maintained and there was no upstream development. Since I have taken over development and will maintain this package this is no longer the case. Bugs that were open at the time webcheck was removed: #71419 request for internationalization of output this is on the TODO list as a wishlist item #192868 handle relative links to file:/ urls nicely using file:/// urls is possible and supported, automatically translating relative or absolute paths into file:/// is also supported now #201154 please handle url()'s in stylesheets this is also implemented in the current version of webcheck #253424 recursion problem in sitemap module (key not found) this should be solved as most of the code is rewritten #271085 produce a validation report (using wdg-html-validator) there is an item on the TODO list to implement more html validation checking, however I do not think that submitting a large number of html pages to a web-based checker is a good idea #286017 problem with recent python version webcheck is developed using python 2.3 but is tested regularly with python 2.4 so this should be solved (this leaves two wishlist bugs in the TODO list) There are a couple of questions left though: * I'm not sure if I need some statement on the copyrights on the generated html files. The css file that is just copied has a BSD license. * The old package provides, conflicts with and replaces linbot (the name of webcheck a long time ago). Should I keep that or just drop it? (linbot was in slink, potato and woody but neither linbot or webcheck were in sarge) * The old package has a configuration file in /etc/webcheck and the new package no longer provides that. What would be the best way to get rid of it? (policy 10.7.3 has a note about removing conffiles but I'm not sure it's relevant) Should I delete it on upgrade? Btw, I'm packaging this as a native Debian package because I just want to release one version and have one source tarball. -- -- arthur - [EMAIL PROTECTED] - http://people.debian.org/~adejong -- signature.asc Description: This is a digitally signed message part
Re: Bug#326429: ITP: webcheck -- website link and structure checker
On Wed, 2005-09-07 at 00:47 -0500, Peter Samuelson wrote:
> [Arthur de Jong]
> > I'm not sure if I need some statement on the copyrights on the
> > generated html files. The css file that is just copied has a BSD
> > license.
>
> Generally, output from a program is not considered to be copyrighted.
> The templates from which it is built could be copyrighted, and if
> significant bits of a template are copied in verbatim, you may wish to
> copy in a license statement from the template too.
The templates are embedded in the python code (e.g. write('')) (except for the mentioned css file). The python code is GPL.
Most of the content (links, titles, other gathered information) is from
the crawled website.
> > The old package provides, conflicts with and replaces linbot (the
> > name of webcheck a long time ago). Should I keep that or just drop
> > it? (linbot was in slink, potato and woody but neither linbot or
> > webcheck were in sarge)
>
> Completely your call. You do not need to support upgrades from woody
> or prior, but you can if you wish. Three lines in debian/control
> which you'll never need to change is a pretty cheap price, but it *is*
> untidy if you want a minimalist control file.
I think I'll keep those lines for a while then (they're not in the way
for now).
> > The old package has a configuration file in /etc/webcheck and the
> > new package no longer provides that. What would be the best way to
> > get rid of it? (policy 10.7.3 has a note about removing conffiles
> > but I'm not sure it's relevant) Should I delete it on upgrade?
>
> Is the package configured in some other way, or have you dropped
> support for any site-wide configuration? If you still have a
> configuration mechanism, it's best if you can migrate /etc/webcheck to
> the new scheme automatically, then delete it, at upgrade time. If
> not, you can just delete it.
The new package does not use a configuration file at all any more (the
config.php file is still there but it is not really meant to be edited
any more and is not in /etc). I don't think I want to keep a site-wide
configfile. Maybe I'll support specifying a configfile from the
command-line one day.
I'm going for completely removing the /etc/webcheck directory on
upgrades. Anyone think there should be a debconf question about this at
install time (e.g. test if /etc/webcheck exists and ask the user to
remove it)?
> > Btw, I'm packaging this as a native Debian package because I just
> > want to release one version and have one source tarball.
>
> Not recommended - you'll have to release a whole new "upstream
> version" any time you fix a trivial Debian bug, or even just to
> recompile against a newer sid library. Providing backports or forks
> (for etch after etch is frozen) will require new upstream version
> numbers, which will confuse your non-Debian audience ("wait, what's
> the current release? Upstream 3.1.15 and 3.1.15~etch1 were released
> at the same time, but 3.0.4.etch2 was just added to the debian ftp
> site")
I think this would avoid confusion since every Debian version is also a
released version. If a release changes just Debian packaging (unlikely
at the moment since it is in development) that will be documented in the
NEWS file. Since this is a python package with architecture: all the
risk of recompiles are minimal. I'm not too worried about the version
numbers of backports or forks because priority is extra (not likely to
be affected by major freeze problems) but adding a .etch# or .sarge#
suffix shouldn't cause too much confusion.
> And there's the bandwidth issue - you and the build daemons have to
> transfer the whole source tarball every time you make a trivial change
> to debian/*.
The current tarball is pretty small (45k plus maybe 5k for a debian
directory) and since the architecture is all (no buildds) I don't think
we'll be having a lot of bandwidth issues.
Thanks for you comments!
--
-- arthur - [EMAIL PROTECTED] - http://people.debian.org/~adejong --
signature.asc
Description: This is a digitally signed message part
nss-ldapd init script sequence number
Hi, I maintain nss-ldapd, a replacement for nss_ldap which uses a local daemon (nslcd) to proxy name lookup requests (passwd/group/hosts/etc) to an LDAP server. I have received a bug report (#475626) that I would welcome some input on. The problem is that a lot of daemons are started at sequence 20 (/etc/rc2.d/S20...) an may want to do name lookups (e.g. exim is mentioned in the bugreport). This means that nslcd should probably be started before sequence 20. However, slapd is started at sequence 19 and it would be best to start nslcd after slapd. Currently nslcd is started at sequence 20. The problem with starting nslcd before slapd is that slapd does name lookups during startup which slow down slapd startup by about 5 seconds (because slapd is not ready to handle lookups yet) and leaves nslcd in a state where it believes the LDAP server is unreachable and will only retry after some timeout has expired. This could in turn cause failed lookups for processes that do name lookups just after slapd has been started. So, what would the best solution for this problem? - request slapd to be started at sequence 18 and start nslcd at sequence 19 when this has changed (haven't extensively checked if that would cause problems for slapd) - add some magic to nslcd to do more retries during startup and handle this case especially - something else?? This also brings up the problem with what to do with existing installations. If I understand correctly changing the parameter to update-rc.d will not change any existing symlinks so any changes that are made now will only affect existing installations. Feedback is very much appreciated (also other feedback related to nss-ldapd). Thanks. -- -- arthur - [EMAIL PROTECTED] - http://people.debian.org/~adejong -- signature.asc Description: This is a digitally signed message part
Re: Bug#475626: nss-ldapd init script sequence number
On Mon, 2008-04-28 at 16:38 +0200, Petter Reinholdtsen wrote: > This is exactly the kind of problems the dependency based boot > sequencing is supposed to solve. [...] I have added: Should-Start: slapd to fix the problem that nslcd should be started after slapd. However to solve the problem that nslcd should be started before mail servers I would like to add: Provides: $named at least exim and postfix have a Required-Start for this) but the description on http://wiki.debian.org/LSBInitScripts suggests that such a provides should be specified in a different place. Where should that be? > Anyway, while we wait for Debian to switch to dependency based boot > sequencing, I believe the best option for you is to get slapd moved at > the start and end. I have filed bug #478674 for this. The end sequence is already very high (80) so I don't think there is a reason to make this even higher. The dependencies of slapd are either started at runlevel S ($remote_fs and $network) or at sequence 10 ($syslog). > > This also brings up the problem with what to do with existing > > installations. If I understand correctly changing the parameter to > > update-rc.d will not change any existing symlinks so any changes > > that are made now will only affect existing installations. > > This is correct. If you want to change the sequence number, the only > option provided by the update-rc.d interface is to remove all > start/stop symlinks and insert it again with new sequence numbers. This would however change local customisations that administrators may have made to their init script order. Something like this could do it though in postinst: [ -l /etc/rc2.d/S20nslcd ] && mv /etc/rc2.d/S20nslcd /etc/rc2.d/S19nslcd [ -l /etc/rc3.d/S20nslcd ] && mv /etc/rc3.d/S20nslcd /etc/rc3.d/S19nslcd [ -l /etc/rc4.d/S20nslcd ] && mv /etc/rc4.d/S20nslcd /etc/rc4.d/S19nslcd [ -l /etc/rc5.d/S20nslcd ] && mv /etc/rc5.d/S20nslcd /etc/rc5.d/S19nslcd [ -l /etc/rc0.d/K20nslcd ] && mv /etc/rc0.d/K20nslcd /etc/rc0.d/K21nslcd [ -l /etc/rc1.d/K20nslcd ] && mv /etc/rc1.d/K20nslcd /etc/rc1.d/K21nslcd [ -l /etc/rc6.d/K20nslcd ] && mv /etc/rc6.d/K20nslcd /etc/rc6.d/K21nslcd However this would work around update-rc.d and be a policy violation: http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.3.3 I suspect not much packages do this when changing sequence number. e.g. I have an etch system which has been upgraded a lot of times that starts nscd at sequence 19 but my sid system that has been installed about a year ago starts it at 20. -- -- arthur - [EMAIL PROTECTED] - http://people.debian.org/~adejong -- signature.asc Description: This is a digitally signed message part
Re: mass bug filing for undefined sn?printf use
On Sun, 2008-12-28 at 12:02 -0600, Steve Langasek wrote: > I don't know whether these are also a problem in practice - but if so, > using sprintf(buf + strlen(buf) [...]) is definitely wrong. I don't know if any of my code uses such a construct but why is that wrong as long as [...] doesn't contain buf? (assuming proper bound checks are done and other parameters are sane) Thanks. -- -- arthur - adej...@debian.org - http://people.debian.org/~adejong -- signature.asc Description: This is a digitally signed message part
Re: mass bug filing for undefined sn?printf use
On Tue, 2008-12-30 at 10:41 -0600, Steve Langasek wrote:
> On Tue, Dec 30, 2008 at 10:06:41AM +0100, Arthur de Jong wrote:
> > On Sun, 2008-12-28 at 12:02 -0600, Steve Langasek wrote:
> > > I don't know whether these are also a problem in practice - but if so,
> > > using sprintf(buf + strlen(buf) [...]) is definitely wrong.
>
> > I don't know if any of my code uses such a construct but why is that
> > wrong as long as [...] doesn't contain buf?
>
> That's not the context of this discussion; we were talking about buggy code
> that *did* use buf as one of the args to the format string.
Ok, I misunderstood. Thanks.
In that case there can be a great number of situations in which the
buffer may be filled with it's own content (eg. pass the same array as
two arguments to a function and use the above construct in that
function, assignments to temporary variables, etc, etc). Very hard to
check for.
Perhaps this would be a good test for tools such as split, rats or
flawfinder (none of them currently warn about this problem and neither
do any gcc flags that I commonly use). Those kind of tools already to
quite some analysis of source code so perhaps it isn't too difficult to
implement it there.
I've just performed a test with the following code on my system (sid,
hardening-wrapper not installed, compiled with gcc without any extra
flags):
char buf[20];
strcpy(buf,"FOO");
snprintf(buf,sizeof(buf),"%s%s",buf,"BAR");
printf("%s\n",buf);
strcpy(buf,"BAR");
snprintf(buf,sizeof(buf),"%s%s","FOO",buf);
printf("%s\n",buf);
which returned
BAR
FOOFOO
so in any case the behaviour is not as could be naively expected
(FOOBAR).
--
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --
signature.asc
Description: This is a digitally signed message part
Re: Why is su preserving the environment?
On Sat, 2009-01-24 at 11:07 +0100, Josselin Mouette wrote: > The question is whether we can consider safe to pass authentication > tokens as environment variables. Either we do, and we fix applications > that pass environment where they shouldn’t. Either we don’t, and we have > to find another way to pass them. You can easily get the environment of a process (of when the process started or the actual value depending on the application) by giving ps the e option. It seems this information is from /proc//environ but I don't think all *nixes properly protect the environment. So in general I would say not to put authentication tokens into the environment. However, most applications that do something like that put a reference to the authentication token in the environment (e.g. XAUTHORITY=/tmp/.gdm0QI8NZ) which is ok as long as the access to the real token (socket mostly) is protected. -- -- arthur - adej...@debian.org - http://people.debian.org/~adejong -- signature.asc Description: This is a digitally signed message part
Re: dh_installinit
On Sun, 2007-11-11 at 11:04 +0100, Vincent Danjean wrote: > When these mechanisms will be ready, a deamon will be unable to close > all its file descriptors (unless it closes the whole range of fd > (0--2^16 ?) or unless an application can get a list of its open fds). This seems to be quite common code (from one of my packages (cvsd), don't know what the original source for this code was): m=sysconf(_SC_OPEN_MAX); for (i=0;ihttp://people.debian.org/~adejong -- signature.asc Description: This is a digitally signed message part
Re: dh_installinit
On Mon, 2007-11-12 at 12:34 -0600, Steve Greenland wrote: > On 11-Nov-07, 14:25 (CST), Arthur de Jong <[EMAIL PROTECTED]> wrote: > > This seems to be quite common code (from one of my packages (cvsd), > > don't know what the original source for this code was): > > > > m=sysconf(_SC_OPEN_MAX); > > for (i=0;i > close(i); > > > > There are hurd packages for this package so that should also work. > > Wrong. That code is buggy. The limit of OPEN_MAX can be indeterminate, > and thus sysconf(_SC_OPEN_MAX) can return -1. Thanks, fixed that in my code (if the call returns negative, we just close the first 32 file descriptors and hope that's enough). Anyone have a better way to detect the highest open file descriptor (preferably something that also works inside a chroot jail that does not have /proc mounted)? NetBSD seems to have fcntl(F_MAXFD) that should do the trick, but it's unavailable on Linux. -- -- arthur - [EMAIL PROTECTED] - http://people.debian.org/~adejong -- signature.asc Description: This is a digitally signed message part
Re: Debian Package
On Tue, 2010-03-09 at 18:25 +, brian m. carlson wrote: > On Tue, Mar 09, 2010 at 12:52:31PM -0500, Jake wrote: > > I was creating a Debian package and after it install I would like it > > to prompt the user to reboot the computer, is there anyway to do > > this? > > Except in very limited circumstances, there should be no need to reboot > the computer after installing a package. The only exception I can think > of is something related to the kernel; in general, root should be aware > that a reboot is required to make that functionality work, but may want > to defer it indefinitely (for example, on a server). > > So yes, the right way to do this is debconf, but what you want to do is > probably the wrong thing. You could also have a look at update-notifier. It has a mechanism to signal users that they should reboot. Rebooting from maintainer scripts is probably a bad idea (may leave dpkg in an inconsistent state). -- -- arthur - adej...@debian.org - http://people.debian.org/~adejong -- signature.asc Description: This is a digitally signed message part
Re: [RFC] disabled root account / distinct group for users with administrative privileges
On Thu, 2010-10-21 at 16:48 +0100, Philip Hands wrote: > If we decide to reject 'admin', I think we should use sudo. I find the > argument that admin is confusing given the presence of adm fairly > convincing -- It's all too easy to say something like "could you add > fred to the adm group" over the phone and pronounce 'adm' as 'admin'. At work we use "admin" to hold all administrative staff (think paperwork) so I would vote against that. > Sadly, we are not the first to make this decision though, and having > admin on Ubuntu and sudo on Debian would be a pain for people that have > mixed sites, or even for admins that just have access to some of each. The admin group is already used in update-notifier though (#502392) and perhaps also other software coming from Ubuntu. -- -- arthur - adej...@debian.org - http://people.debian.org/~adejong -- signature.asc Description: This is a digitally signed message part
Re: Init dependency between nfs-kernel-server and name server
On Thu, 2010-10-21 at 20:27 +0200, Tollef Fog Heen wrote: > | Besides, I believe $named is a existing and fitting virtual facility > | for this use. > > Indeed, it seems quite appropriate. It would at least simplify things for my nslcd package which provides name lookups (user, group, hosts, etc) via LDAP. It currently has a long list of things in the X-Start-Before header which is ugly. The thing is, that nslcd may also have a dependency on hostname lookups (e.g. if the LDAP server is specified as a hostname instead of an IP address) which makes things even more complex. For some background you may want to check out #478807, #544093 and #585968 -- -- arthur - adej...@debian.org - http://people.debian.org/~adejong -- signature.asc Description: This is a digitally signed message part
Re: enable/disable flags in /etc/default
On Sat, 2011-02-26 at 21:44 +0100, Tollef Fog Heen wrote: > Personally, I'd rather we didn't have them, as this is supposed to be > controlled by the rcN.d links and if that interface is too hard for > people we should fix that rather than invent multiple ways of disabling > daemons, but the current mess is, well, a mess. I would also love to have a way to easily configure which daemons should be started at boot time. I don't know whether switching to insserv made things simpler in that regard though. In general I don't like having to mess with /etc/default/foo because it also makes it more difficult to start/stop by hand. Once nice compromise is what the mldonkey-server package does: - /etc/default/mldonkey-server can be used to disable starting at boot, but: - /etc/init.d/mldonkey-server force-start still allows manual starting of the service - the service is correctly stopped on shutdown I would personally really like to see this in most daemons that not all users may need all the time. Extra bonus points for having some convention for option names. -- -- arthur - adej...@debian.org - http://people.debian.org/~adejong -- signature.asc Description: This is a digitally signed message part
Bug#618473: general: Problems to handle NIS group names
reassign nfs-common thanks On Tue, 2011-03-15 at 15:10 +0100, Christian Andretzky wrote: > I've really no idea, which package(s) are responsible for this problem. Reassigning to nfs-common because that seems to be the most likely candidate (assuming autofs is used to mount nfs filesystems). > In my log files I can find messages like: > > Mar 15 14:56:09 oedibus automount[1983]: set_tsd_user_vars: failed to get > group info from getgrgid_r > > As the result the output from ls command looks like > > ... > drwx-- 21 saadi 12000 4096 19. Nov 12:22 saadi > ... > > The output of 'ypcat group' shows the correct group names. > > If I dont use autofs and mount the filesystem manual using 'mount', > the same problem happens. It would really be hulpful if you could post more information. /etc/nsswitch.conf, /etc/auto.master, nfs mount settings (nfs version), etc come to mind. I know nfs4 uses and idmap that has caused issues in the past if the naming service is not available during boot (see e.g. #500778). -- -- arthur - adej...@debian.org - http://people.debian.org/~adejong -- signature.asc Description: This is a digitally signed message part
Re: When bind9 reinstalls, no db.root
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 21 Aug 2002, Marc Singer wrote: > On Wed, Aug 21, 2002 at 09:42:53PM +0200, Josip Rodin wrote: > > > > Sounds like you want dpkg --force-confmiss. > > > > > > I wouldn't expect that since the documentation states: > > > > > > confmiss: Always install a missing configuration > > > file. This is dangerous, since it means not pre- > > > serving a change (removing) made to the file. > > > > > > How could it be dangerous to install a *missing* configuration file? > > > > If the default configuration data in the file do something you don't want. > > For example... Logcheck has a number of files under /etc/logcheck/ignore.d... that are marked as configuration files. Removing a configuration files means that more information is present in the log summary. (automaticly) Replacing these configuration files would result in unwanted behaviour. - -- arthur - [EMAIL PROTECTED] - http://tiefighter.et.tudelft.nl/~arthur -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) iD8DBQE9ZKQgVYan35+NCKcRAoZSAJ4u1IeVFKCujBEuSr3yj9L9CZpCxQCfYgZO e+MVu8TbK1ViLL5zA6i9ui8= =W8zs -END PGP SIGNATURE-
Re: When bind9 reinstalls, no db.root
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 22 Aug 2002, Arthur de Jong wrote:
> > For example...
>
> Logcheck has a number of files under /etc/logcheck/ignore.d... that are
> marked as configuration files. Removing a configuration files means that
> more information is present in the log summary. (automaticly) Replacing
> these configuration files would result in unwanted behaviour.
Oh I just thought of a better one: a lot of packages have configfiles in
/etc/cron.{daily,monthly,weekly}. Removind a configfile is clearly not the
same as having a default in this case.
Bluntly overwriting the db.root file is also not a good idea since some
people use alternative root nameservers. If you screwed up your package
configuration you should do:
apt-get --purge remove bind9
apt-get install bind9
(maybe apt-get --purge --reinstall install bind9 would be nice)
You either replace you whole configuration or just your binaries. I don't
think tat changing dpkg to do vodoo for you is a good idea.
- -- arthur - [EMAIL PROTECTED] - http://tiefighter.et.tudelft.nl/~arthur --
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
iD8DBQE9ZKg+VYan35+NCKcRAoRDAKDpCk9sGyA1IhYEOx4uYSNfaivl3gCdHu+d
8wFw7M3PKUaMpmIiSTbEz3s=
=8G62
-END PGP SIGNATURE-
Re: debconf review of cvsd (was Re: stop abusing debconf already)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > Arthur de Jong wrote: > > Ok, could you review my cvsd package for me for correct debconf usage > > and tell me what you do and don't like? > > Thanks for taking advantage of that offer. (So far you're the only one.) > I am ccing this to -devel just because. > > All of the debconf questions are pretty well worded and clear, but > there's always room for improvement: Thanks for the review. I've changed most of the wording according to your suggestions (English isn't my native language). >s/zero (0)/0/ # Apparently writing it out has the possibility to make > # someone enter the number the wrong way so why not just > # not write it out? I spelled out zero because some (most) fonts don't represent 0 differently from O. Same goes for 1 and l. > - It's sort of odd that you use spaces to separate multiple items in one > question, and then colons to separate them in the next. It would be nice if debconf would have some unified way of entering lists. I'm also not very happy with the way it is currently done, but I've modeled it after the cvs questions and a colon is the "standard" seporator for directories, while using : in addresses may provide problems with IPv6 addresses (improving this is on my TODO list). > - I was fairly confused by cvsd/limit_memorylocked, because I thought > that only programs run as root could lock memory, and why would cvs > want to? Was this just added for (over)completeness? Probably. I provided questions for all the limits I could find. The code also covers limits for things that are not settable on linux (there is even a debconf question about it that is never asked). > - You have no translations for the debconf templates in the package. The > DDTP project has a complete German translation at > http://ddtp.debian.org/debconf/source/cvsd. Of course you may want to > make the above changes first, and wait for an updated translation.. I have received a Brazillian translation of the debconf questions that I'm merging into cvsd (bug #187795). I saw the German translation at http://ddtp.debian.org/cgi-bin/ddtp.cgi?part=debconf&package=cvsd before but I never saw the page you linked (very useful page but I can't find it linked from the site). And since the site says "(Now) we don't need any action from the debian package maintainer." I didn't take any action regarding the translation. > If I reconfigure cvsd, pick all the limits, and take the default value > for everything else, it exits with code 20: > > debconf (developer): <-- GET cvsd/limits > debconf (developer): --> 0 coredumpsize, cputime, datasize, filesize, > memorylocked, openfiles, maxproc, memoryuse, stacksize, virtmem > debconf (developer): <-- GET cvsd/limit_coredumpsize cputime datasize > filesize memorylocked openfiles maxproc memoryuse stacksize virtmem > debconf (developer): --> 20 Incorrect number of arguments > zsh: exit 20DEBCONF_DEBUG=. dpkg-reconfigure cvsd > > Looks like a bug.. After doing this I also did not see all the limits > stuff in cvsd.conf, it had only these config items: > > Uid cvsd > Gid cvsd > PidFile /var/run/cvsd.pid > RootJail /var/lib/cvsd > MaxConnections 10 > Nice 1 > Listen * 2401 This looks like it may be due to a bug (or incompatibility) in zsh. Do you have /bin/sh set to zsh? I have some strange results if I use zsh to process the postinst. I'll do some more testing. Somehow the result of the 'GET cvsd/limits' is passed to the next command. > Looking at your priorities, I'm not sure why the maximum connection > limit is at priority medium. I already changed it to low for the next release (couldn't remember either why it was set to medium). > > I've set it up to ask first whether to use debconf to manage > > configuration of /etc/cvsd/cvsd.conf (not a conffile). If the user > > chooses to not use debconf, he's on his own (an example cvsd.conf is > > provided). > > Of course this is where in my opinion you lose. First of all, as Colin > pointed out recently, any question that asks "use debconf" and defaults > to true results in the package violating debian policy on any system > where the debconf priority is higher than the question, or > noninteractive mode is used. If the question is not shown to the user at > all, and a default config is put into place, and the user edits that > config and loses changes on upgrade, then you've violated policy. > > Secondly of course, I hate all "use debconf" questions. It's the wrong > way to use debconf; you should be intelligently parsing answers out o
Re: /run/, resolvconf and read-only root
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > I don't know what it will take to convince you, but I would like you to > answer these questions: I also have a problem with adding another toplevel directory and I suspect there are some more. I haven't read the complete thread (I also have other things to do) but I've picked up bits and pieces. > Do you think having programs write to /etc is a bad thing? I think creating /run is worse. I think it should be possible for any program that writes to /etc (it it cannot use /var) either to be configurable to store it's data somewhere else or use a symlink to store the data somwhere else (e.g. /proc/flashrom or /nfsmounteddiskbutnotroot or other unusual place). I think that should be the first step in tris transition. > Where would you put /etc/mtab, to keep /etc sacrosanct? I think that state about the mounted filesystems should be kept by the kernel (that meens /proc). If there is some state that is not kept by the kernel but by userspace it should probably stored in /var somewhere (if /var is not available on boot writing the file could be delayed until it is mounted). Having mtab in /etc may be useful for historical reasons to a couple of people though and you might consider a symlink to some file in /var. I haven't seen a very good description of /run yet and I'm not completely sure that something like "a place to write files to when you can't write to /var yet" is useful. This is not a useful description because /var may be mounted at different times on different systems (e.g. nfs mounted /var vs localy mounted /var). I think finding a soltion for the ro root, nfs /var combination is a good thing but I doubt it should be this invasive. - -- arthur - [EMAIL PROTECTED] - http://tiefighter.et.tudelft.nl/~arthur -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) iD8DBQE+r8wJVYan35+NCKcRAn+UAJ93q4FPQV8CQfbrplEsFL/gjkckBQCeMBYj pXPlDwCZhivmJJuR8EjvDjo= =m5Gm -END PGP SIGNATURE-
Re: Release Candidate 2 of Debian Installer
On Sun, 2009-02-01 at 03:46 +, The Fungi wrote:
> On Sat, Jan 31, 2009 at 07:56:01PM -0600, Andrew Deason wrote:
> > Label names could be generated to minimize collisions. Something like
> > ${hostname}-/ instead of /, or maybe something even more specific.
>
> The namespace here is, unfortunately, pretty limited. The manpages
> for mkreiserfs and mke2fs mention a 16-character limit for
> filesystem labels [...]
Also using slashes in labels causes problems with the symlinks showing
up in /dev/disk/by-label.
--
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --
signature.asc
Description: This is a digitally signed message part
Re: handling group membership in and outside d-i
On Thu, 2009-02-26 at 13:01 +, Ben Hutchings wrote: > On Thu, 2009-02-26 at 08:31 +0100, Peter Palfrader wrote: > > This is of course broken. It breaks granting console users access > > to the netdev or powerdev groups through pam_groups, which is really > > really annoying when you get your users from say ldap. > > But that's broken to start with, since you can't revoke group > membership when the user logs out. The group membership is only assigned to the process, not in the group database. I generally have something like: gdm; :*; *; Al-2400; audio,floppy,video,cdrom,scanner,plugdev,voice in /etc/security/group.conf to ensure that any user that is logged in on the console can do most things you can expect console users to do. So for a gdm session: % groups users voice cdrom floppy audio src video plugdev scanner But the NSS databases contain the following: % groups arthur arthur : users src I've found that with lenny for some things (dbus?) you need consolekit (I install policykit-gnome which has all the dependencies I need) to accomplish (part of?) what you did with secondary groups before. -- -- arthur - adej...@debian.org - http://people.debian.org/~adejong -- signature.asc Description: This is a digitally signed message part
Re: xcdroast does no longer work with wodim: Who to blame?
On Sat, 2009-02-28 at 12:43 +1100, Russell Coker wrote: > http://en.wikipedia.org/wiki/Joerg_Schilling > > I notice that Joerg's Wikipedia page is rather bare. > > Instead of spending time covering all the old arguments on this list, > perhaps some people could add links (such as the ones you cited) to > Joerg's Wikipedia page. A Wikipedia page about Joerg that is remotely > complete and also neutral requires a reference to these issues (the > current page only has two paragraphs). Have a look at the cdrtools page: http://en.wikipedia.org/wiki/Cdrtools The cdrkit page also has some info: http://en.wikipedia.org/wiki/Cdrkit -- -- arthur - adej...@debian.org - http://people.debian.org/~adejong -- signature.asc Description: This is a digitally signed message part
Re: Bug#419209: lvm2: Hangs during snapshot creation
On Thu, 2009-03-05 at 09:58 +0100, Klaus Ethgen wrote: > Well, I did also some tests and wasn't able to trigger that bug on my > laptop too. But I also have the lvm direct on the hard disk. On my > server there is a md device underlying. So I suggest the problem is > just with a lvm on top of a md device (which you see not that often on > desktop systems). FWIW, I have a similar setup and cannot reproduce this: # uname -a Linux bobo 2.6.26-1-amd64 #1 SMP Sat Jan 10 19:55:48 UTC 2009 x86_64 GNU/Linux # mdadm --detail /dev/md0 /dev/md0: Version : 00.90 Creation Time : Sun Apr 29 20:01:14 2007 Raid Level : raid1 Array Size : 58596992 (55.88 GiB 60.00 GB) Used Dev Size : 58596992 (55.88 GiB 60.00 GB) [...] Number Major Minor RaidDevice State 0 810 active sync /dev/sda1 1 8 171 active sync /dev/sdb1 # pvs PV VG Fmt Attr PSize PFree /dev/md0 main lvm2 a- 55.88G 9.88G # lvs LV VG Attr LSize Origin Snap% Move Log Copy% Convert home main -wi-ao 30.00G foo main -wi-ao 6.00G root main -wi-ao 2.00G squidmain -wi-ao 2.00G srv main -wi-ao 2.00G swap main -wi-ao 2.00G tmp main -wi-ao 512.00M var main -wi-ao 1.50G # dmsetup table main-squid: 0 4194304 linear 9:0 75497856 main-swap: 0 4194304 linear 9:0 7340416 main-root: 0 4194304 linear 9:0 384 main-foo: 0 8388608 linear 9:0 79692160 main-foo: 8388608 4194304 linear 9:0 104857984 main-tmp: 0 1048576 linear 9:0 11534720 main-var: 0 3145728 linear 9:0 4194688 main-srv: 0 4194304 linear 9:0 109052288 main-home: 0 62914560 linear 9:0 12583296 # lvcreate -s --size 2G -n foobar /dev/main/srv Logical volume "foobar" created -- -- arthur - adej...@debian.org - http://people.debian.org/~adejong -- signature.asc Description: This is a digitally signed message part
Re: Sponsorship requirements and copyright files
On Sun, 2009-03-22 at 12:11 +, Noah Slater wrote: > Firmly in my mind is the cost/benefit of this extra effort. If we > succeed in integrating debian/copyright checks into lintian, or dpkg > and it's front-ends, it seems reasonable to imagine that this effort > would be a good trade-off. I have been reading this discussion a bit and I've been wondering what use-case you actually have for machine-readable debian/copyright files. FTP masters have indicated that they don't care about the format. This seems logical because they don't "trust" what the maintainer put in debian/copyright and need to review the source by hand anyway. As a package maintainer I don't see much benefit for my work with this new format. My packages are extremely simple when copyright is concerned though. As a user I hardly ever look at /usr/share/doc/*/copyright. If the package is in main I consider that enough information for just using it. If I'm developing software and I want to use another piece of software (e.g. library, framework or component) I check the license (I don't care about the copyright holders btw.) and perhaps sometimes I check the copyright file but most of the time I just check what upstream put on their website. For these seldom uses a common format or tools wouldn't help me much. So for me debian/copyright is mostly a write-only file. I can understand there may be benefits of a parsable format but I don't directly see enough gain. On the other hand there seems to be a lot of (perceived) cost involved (maintainer work). This means that if you want to introduce a new format you have to convince the maintainer of a package that there is some benefit, be it in tools that make their life easier or some concrete benefit for our users. Anyway, thanks for the work on the format. To me it seems to probably be a good thing. I hope this mail wasn't too negative. -- -- arthur - adej...@debian.org - http://people.debian.org/~adejong -- signature.asc Description: This is a digitally signed message part
Re: What are the benefits of a machine-parseable ‘debian/copyright’ file? (was: Sponsorship requirements and copyright files)
On Mon, 2009-03-23 at 10:03 +1100, Ben Finney wrote: > > Anyway, thanks for the work on the format. To me it seems to > > probably be a good thing. I hope this mail wasn't too negative. > > I find this a little confusing, since you spent most of your message > saying how you *don't* think it's a good thing (nor, presumably, much > of a bad thing), but thanks for the positive note :-) I think having a uniform format for debian/copyright is a good thing in general. It makes it easier to read and write. The problem is that I don't see much use for a machine-parsable format though at this point. Firstly (and most importantly for me), there are no tools to support it so there is no immediate benefit (except the improvement in readability). Secondly, the use-cases that have been pointed out are very limited and IMHO don't justify the amount of effort that has to be put into converting files. BTW, the use-case where you don't want to install FDL content and have some way for apt to warn you before doing so won't be solved by a new format because debian/copyright is written at the source-level and not on the binary package level (think -doc packages that have FDL stuff and -bin packages that have other-licensed stuff). (not that I've given this too much thought) Also I think that for complexly licensed packages a single line wouldn't do justice to the license at all (think of a GPL-licensed work with some BSD-licensed source parts, CC-licensed documentation, MIT-licensed whatever, etc,). For those, if you would be really interested, you would have to read the copyright files completely anyway (either that or GPL + CC docs would also do it). I have converted a couple of my packages to the new format (it's probably old by now) but for a more recent one (nss-ldapd) I skipped because the wiki page was unreadable and it would also be more effort (patches are welcome though ;) ). Note that this is completely separate from whether or not to list all copyright holders and for which files to list them. I would like to see some simplifications here or at least some rationale (but that's another subthread). -- -- arthur - adej...@debian.org - http://people.debian.org/~adejong -- signature.asc Description: This is a digitally signed message part
integrating PAM module into nss-ldapd (RFH)
Hello list (I've put a couple of people in Bcc to try to get more feedback), I'm working on integrating a PAM module into nss-ldapd and am looking for input on this. The PAM module was kindly provided by Howard Chu from the OpenLDAP project but I'm still working on the server part. (more info on nss-ldapd: http://packages.debian.org/nss-ldapd) With this new functionality I'm planning to generate three binary packages (instead of the now one): libnss-ldapd (the NSS module), libpam-ldapd (the PAM module) and nslcd (the daemon). The reason for this split is that some users may want to stick with the other PAM module. Also the OpenLDAP people are working on an overlay that could replace the nslcd part (but it's up to the OpenLDAP maintainers if they want to provide such a package). Also, I'm looking for people who are willing to spend some time on nss-ldapd. I could use some help with the PAM packaging part, I know libpam-runtime was changed recently so if anyone can help to get the the PAM packaging into shape that would be great. Since nss-ldapd seems to be used more often now, having a co-maintainer for the package would really help. There is still enough development work to be done but also packaging work with the upcoming split. Another important part where I would really welcome suggestions is a better name for the software. I've seen some confusion over the current name (people not noticing the d at the end) and with the integration of PAM functionality the name no longer covers the functionality. Current work on integrating the PAM functionality can be tracked here: http://arthurenhella.demon.nl/svn/nss-ldapd/nss-pam-ldapd/ http://arthurenhella.demon.nl/viewvc/nss-ldapd/nss-pam-ldapd/ Any comments and suggestions are very much appreciated. Thanks. -- -- arthur - adej...@debian.org - http://people.debian.org/~adejong -- signature.asc Description: This is a digitally signed message part
Re: integrating PAM module into nss-ldapd (RFH)
On Sat, 2009-05-30 at 16:05 -0700, Richard A Nelson wrote: > This is great news! I've already converted all my boxes and am > continually exhorting conversion to libnss-ldapd (mostly on IRC, but > also those who report bugs on the libnss-ldap package). > > It seems to me, as the libnss-ldap maintainer, that libnss-ldapd is > functional enough that we should deprecate libnss-ldap. nss-ldapd still has some rough edges here and there but should be stable enough for most environments. nss_ldap has some features though that aren't implemented in nss-ldapd (most of which aren't documented if I remember correctly). Also nss_ldap has seen more testing, especially in Kerberos, SASL and SSL-related setups. > I would also, as the pam-ldap maintainer, recommed similar deprecation > for it once you have bind-auth (for auth), and exop (for pw change) > going. The PAM implementation I'm working on does a username to DN lookup and attempts to bind with that DN. That seems to work fine in my test setup. This module has seen very little testing though and authorisation and password change currently aren't implemented. > > There is already so many mis-configured machines out there, and the > older packages have some significant issues, that I really believe > Debian would do well by standardizing/offering only the one, superior, > solution. I think that keeping nss_ldap and pam_ldap around is generally a good idea (mostly because of to the feature differences) for as long as someone is willing to maintain it. Having said that I don't see a problem with having nss-ldapd as the default NSS module for LDAP. For the PAM module I'm not confident enough about the current code yet. > > Also, I'm looking for people who are willing to spend some time on > > nss-ldapd. I could use some help with the PAM packaging part, I know > > libpam-runtime was changed recently so if anyone can help to get the > > the PAM packaging into shape that would be great. > > Whilst I'm no pam wizard (by any stretch), we can likely take some > information from the extant pam-ldap package. Neither am I (but I'm learning now). I didn't know much about NSS before I began on nss-ldapd. I already took the patch from Steve Langasek in #517971 which seems to work ok. The only thing I noticed was that pam_sm_acct_mgmt() does not seem to be called with that configuration (probably pam_unix thinks enough authorization has taken place in /etc/pam.d/common-account). > > Since nss-ldapd seems to be used more often now, having a > > co-maintainer for the package would really help. There is still > > enough development work to be done but also packaging work with the > > upcoming split. > > Count me in - in whatever way I can be of assistance ... I've moved > most of my machines to KRB5 auth, but the LDAP passward are being > still kept in sync; so I can easily run tests. Great, I'll add you to the Uploaders field in the upcoming upload. I'll also provide you with commit access to the repository. I'm thinking about having one, maybe two more releases in the 0.6.x series and have a 0.7.x series with the PAM module enabled, the package rename and the split into three packages. > > Another important part where I would really welcome suggestions is a > > better name for the software. I've seen some confusion over the > > current name (people not noticing the d at the end) and with the > > integration of PAM functionality the name no longer covers the > > functionality. > > Yes, the name does cause confusion (often an issue on #ldap and > #openldap), which is one reason I favour deprecation of the older > packages (if not removal), and having one solution for Debian. That does not fix the problem outside Debian though, e.g.: http://www.securityfocus.com/bid/34211 https://bugzilla.redhat.com/show_bug.cgi?id=491623 > But even if we don't do that, I think the current name proposals make > sense - even if somewhat confusing. It's the best I could come up with ;) So unless a better alternative is presented I think we'll have to stick with that. > > Current work on integrating the PAM functionality can be tracked > > here: > > http://arthurenhella.demon.nl/svn/nss-ldapd/nss-pam-ldapd/ > > http://arthurenhella.demon.nl/viewvc/nss-ldapd/nss-pam-ldapd/ > > /me makes a note to pull these Tuesday afternoon (this weekend is my > 28th anniversary) - and we're still recovering from 3weeks on the > road, so I wont have much computer time until then. I plan to integrate as much as possible from the nss-pam-ldapd branch into the nss-ldapd branch to already get some code into the 0.6.x releases. Thanks for the feedback! -- -- arthur - adej...@debian.org - http://people.debian.org/~adejong -- signature.asc Description: This is a digitally signed message part
Re: DEP-5: Please clarify the meaning of "same licence and share copyright holders"
On Wed, 2009-06-10 at 11:06 +0200, Fabian Greffrath wrote: > I am sorry if it's just me who doesn't understand this sentence, but > please clarify the meaning of "...indicating files that have the same > licence and share copyright holders." in the current DEP-5 proposal > for the 'Files' field. > > Imagine I have three files in the source: a, b and c. > File a is copyrighted by Person A, file b is copyrighted by Person B > and file c is copyrighted by both Persons A and B. All files are > licensed under the GPL. Let's make it even more interesting, let's say a has: Copyright (C) 2006 Person A b has: Copyright (C) 2007 Person B and c has: Copyright (C) 2007 Person A Copyright (C) 2008 Person B or even a file d which has: Copyright (C) 2008 Person A What I now would put in debian/copyright is: Copyright (C) 2006-2008 Person A Copyright (C) 2007-2008 Person B -- -- arthur - adej...@debian.org - http://people.debian.org/~adejong -- signature.asc Description: This is a digitally signed message part
Bug#678676: ITP: svn2cl -- Generate GNU-style changelog from svn repository history
Package: wnpp Severity: wishlist Owner: Arthur de Jong X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: svn2cl Version : 0.13 Upstream Author : Arthur de Jong * URL : http://arthurdejong.org/svn2cl/ * License : BSD-3-clause Programming Lang: Bourne shell and XSLT Description : Generate GNU-style changelog from svn repository history This tool uses an xsl stylesheet for generating a classic GNU-style ChangeLog from a subversion repository log. This software was part of the subversion-tools package but was dropped in the 1.7 version because upstream dropped the contrib section. -- -- arthur - adej...@debian.org - http://people.debian.org/~adejong -- signature.asc Description: This is a digitally signed message part
Re: Bug#680226: lib{nss,pam}-ldapd: apt wants to remove them on dist-upgrade in favour of lib{nss,pam}-ldap:i386
found 680226 0.8.5
tags 680226 + help
thanks
On Wed, 2012-07-04 at 15:42 +0200, Thorsten Glaser wrote:
> this situation is a bit weird, on an M-A enabled system (debugging
> hindered a bit due to #680225), after upgrading libnss-ldapd and
> libpam-ldapd to the latest version (or even before doing that), a
> further dist-upgrade wants to kill them and install libnss-ldap and
> libpam-ldap (the nōn-“d” versions, which thus will not work due to
> #423252) from i386 (WTF?).
Thanks for pointing this out.
My guess is that this is due to the Conflicts/Replaces that is included
in libnss-ldapd on libnss-ldap and in libpam-ldapd on libpam-ldap.
I guess the conflicts is interpreted to apply to any installed version
of the package while what should be interpreted as a conflict/replaces
only of the package of the same architecture.
I'm not sure what the proper way is to specify that Conflicts and
Provides should only apply for a same-architecture version of the
package. If I do this (just trying some things):
Conflicts: libnss-ldap:${Arch}
Provides: libnss-ldap:${Arch}
the package is built but Lintian complains loudly and dpkg refuses to
install with:
# dpkg -i libnss-ldapd_0.8.10-2_i386.deb
dpkg: error processing libnss-ldapd_0.8.10-2_i386.deb (--install):
parsing file '/var/lib/dpkg/tmp.ci/control' near line 9 package 'libnss-ldapd':
'Conflicts' field, reference to 'libnss-ldap': invalid architecture name
'i386': a value different from 'any' is currently not allowed
This page [https://wiki.ubuntu.com/MultiarchSpec] says: "consideration
of a syntax extension for Conflicts(and Replaces) is deferred until
after the initial implementation"
Does anyone know how to deal with this situation? I could perhaps drop
the provides (or make it Provides: libnss-ldap:${Arch}). There is only
one package in the archive that has a suggests on libnss-ldap so the
"damage" within the archive should be minimal. This would only leave the
case where you would want to have libnss-ldap on i386 and libnss-ldapd
on amd64 impossible (which is theoretically valid).
Any ideas?
--
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --
signature.asc
Description: This is a digitally signed message part
Re: Bug#680226: lib{nss,pam}-ldapd: apt wants to remove them on dist-upgrade in favour of lib{nss,pam}-ldap:i386
On Fri, 2012-07-06 at 10:00 +0200, David Kalnischkies wrote:
> > I'm not sure what the proper way is to specify that Conflicts and
> > Provides should only apply for a same-architecture version of the
> > package. If I do this (just trying some things):
>
> There is simple no way.
Thanks for your reply.
I guess I could drop the Provides for now then which seems to be the
least disruptive change to support multiarch (but also see below).
I can't drop the Conflicts because libnss-ldapd and libnss-ldap share
the same file (at least the same library which may be in the same file
depending on whether you are comparing multiarch or non-multiarch
versions).
> > # dpkg -i libnss-ldapd_0.8.10-2_i386.deb
> > dpkg: error processing libnss-ldapd_0.8.10-2_i386.deb (--install):
> > parsing file '/var/lib/dpkg/tmp.ci/control' near line 9 package
> > 'libnss-ldapd':
> > 'Conflicts' field, reference to 'libnss-ldap': invalid architecture name
> > 'i386': a value different from 'any' is currently not allowed
>
> Which dpkg version is that?
This was 1.16.4.2 that was lying around in a play chroot. dpkg 1.16.7
installs the deb just fine.
I've been playing a bit with only changing the conflicts to include
:${Arch} which seems to work with dpkg (though lintian still complains),
however apt doesn't seem to understand it and doesn't remove
libnss-ldapd when installing libnss-ldap.
Then again, I can't reproduce the problem that Thorsten reported. I've
got both libnss-ldapd:i386 and libnss-ldapd:amd64 installed (both
0.8.10-1) in a chroot with dpkg:i386 1.16.7. The installation was done
with apt-get (apt:i386 0.9.7.1) and went fine. Also apt-get dist-upgrade
doesn't want to remove either of the packages (for some reason apt does
want to switch back to the i386 coreutils that I managed to switch to
amd64).
On Fri, 2012-07-06 at 11:02 +, Thorsten Glaser wrote:
> Could this work: libnss-ldap and libnss-ldapd both provide the same
> virtual package and conflict with it? Same for the pam ones but a
> different virtual package.
My guess is that it wouldn't because the conflict would still match it
on the other architecture.
--
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --
signature.asc
Description: This is a digitally signed message part
Re: Removing packages from unofficial repositories
On Thu, 2014-01-02 at 12:52 -0500, Simon Ruggier wrote: > However, I would expect that most users would not have the patience to > do this via apt preferences, and if there is an easier way, I was not > aware of it. I also did this a few times. I remove the third-party repositories from sources.list, apt-get update and check the output of apt-show-versions | egrep -v '/(testing|unstable).*uptodate' Not ideal, but it works. -- -- arthur - adej...@debian.org - http://people.debian.org/~adejong -- signature.asc Description: This is a digitally signed message part
Re: Crypto consolidation in debian ?
On Sun, 2011-05-01 at 14:08 +0100, Roger Leigh wrote: > If we could move to having a central service, rather than having every > process load in a pile of extra libraries, I would probably be in > favour of it. If would make some things, such as NSS queries inside > chroots, much more efficient and robust. This is what nss-pam-ldapd does to replace nss_ldap (NSS part in libnss-ldapd). It uses a central daemon running as a dedicated user (for LDAP NSS requests only). The original reason for the creation of nss-ldapd was that the OpenLDAP libraries are not meant to be in processes that do not expect them. I guess there are more. Another solution (that Joss already pointer out) is libnss-sss which has a slightly broader scope. I'm not sure that having a central process to read stuff from simple flat files is a good idea though as it adds extra complexity and a single point of failure. -- -- arthur - adej...@debian.org - http://people.debian.org/~adejong -- signature.asc Description: This is a digitally signed message part
Re: Crypto consolidation in debian ?
On Sun, 2011-05-01 at 12:55 +0200, Bastien ROUCARIES wrote: > It seems fedora is moving to nss for openldap I don't think it's completely free from the same kind of issues as GNUTLS. For example, I recently came across this: https://bugzilla.redhat.com/show_bug.cgi?id=701587 NSS (Network Security Service, not Name Service Switch) seems to change the scheduling parameters of a process. Also OpenLDAP itself isn't that good a candidate to load into every process. Just look at all the hacks nss_ldap needs to do keep it in a sane state. Also environment variables and files in user's home directory influence libldap's workings. Although switching SSL/TLS library to something different may be a good idea, I don't think it will fix the problem for NSS (Name Service Switch here) modules. -- -- arthur - adej...@debian.org - http://people.debian.org/~adejong -- signature.asc Description: This is a digitally signed message part
