Re: software updates file in /usr -- policy bug?
hey martin, On Tue, Oct 26, 2004 at 05:47:03PM +0200, martin f krafft wrote: > - The administrator has no place in /usr, it's the package > manager's domain. > > - Tools keep MD5 sums for files installed. When a file in /usr > changes, it is usually an indication of something fishy; thus, > certain programmes will fire alarms. > > Lastly, the policy promises that /usr can be read-only and > guarantees software to be fully functional. fwiw i think it's Very Wrong that any package or tool should try and update the contents of anything in /usr outside of placing their pre-packaged files in there[1]. if this information is variable state, then it should go where variable state information is supposed to go, no question about it. if the admin should be able to edit it, there's a place for that too. neither of these is /usr... sean [1] of course, symlinks, diversions, etc all fall in the same spirit. -- signature.asc Description: Digital signature
another update on common database app infrastructure
hey all, an update on this database common stuff: - i've made a few alterations to the debconf templates and pre-configuration outline based on both on and off-list feedback - i've made some updates to the "best practices" web page, primarily the "build time and run time tools" section. - i've added a few initial scripts to the common package for using debconf input/settings to add users and create databases. the guts currently use ola's code in wwwconfig-common. - i've made a proof of concept "db-test-mysql" package to test the setup provided by the common package. i'd still consider both packages to be rather volatile in composition (and also not anywhere near complete), but the current package does prompt the user with the existing templates, create the mysql user, and set up the initial database. so, in addition to "proof of concept", it's also a "work in progress". my current TODO list is a superset of what's on the "best practices" web page, the TODO file in the common package, and things in my head not yet synchronized to disk. i'll be posting another update sometime in the next week and a half with a more feature complete common package, stabilized api, and a more complete example package. after this point, i plan to start lobbying for help from non-mysql database packagers to make sure this whole setup would work with them, and to finalize the api. after that, i suppose it will be time to start looking for vict^H^H^H^Hvolunteers to try the setup with their packages. i'd encourage those with a vested interest in this to take another look at the "best practices" page and the two packages. as always, all relevant information is available at: http://people.debian.org/~seanius/policy/dbapp-policy.html sean -- signature.asc Description: Digital signature
Re: Debconf is not a registry (was: Right Way to make a configuration package)
On Mon, Nov 01, 2004 at 08:04:14AM +0100, Marc Haber wrote: > Why is the information given during package installation stored > persistently in the first place? it's not stored persistently, that's why it's in /var/cache :) sean -- signature.asc Description: Digital signature
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor
On Wed, Dec 01, 2004 at 05:38:39PM +0100, Michelle Konzack wrote: > > However, I'd be *highly* agitated if someone gave my daughter a > > CD-ROM with *any* nudy cartoons. > > Agreed. then don't give your daughter sudo privileges on your debian machines, and she can't install it! :) sorry, couldn't help it... sean -- signature.asc Description: Digital signature
Bug#283903: ITP: dbconfig-common -- common framework for packaging database applications
Package: wnpp Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package name: dbconfig-common Version : 0.7 Upstream Author : sean finney <[EMAIL PROTECTED]> URL : http://people.debian.org/~seanius/policy/dbconfig-common.html License : BSD Description : common framework for packaging database applications dbconfig-common is an implementation of the "best practices for database applications" (http://people.debian.org/~seanius/policy/dbapp-policy.html) draft, which provides debian packagers with an easy, reliable, and consistant method for managing databases used by debian packages. dbconfig-common can: * create databases and database users * access local or remote databases * upgrade/modify databases when upstream changes database structure * remove databases and database users * prompt users with a set of normalized, pre-translated questions * do all the hard work automatically * work for package maintainers with little effort on their part * work for local admins with little effort on their part * comply with an agreed upon set of standards for behaviour * do absolutely nothing if it is the whim of the local admin * reconfigure the database of a package via dpkg-reconfigure currently, only support exists for mysql databases, but i'm now working on integrating postgresql support too. i've started an alioth project if anyone is interested in helping out. sean - -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.7-1-686 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBrqg9ynjLPm522B0RAhd/AJ0cuCr3am3D0TUu6m5V5OCa8ZvaDgCdGs1p 2baq0syNN63jQTDirt15NmE= =zhGO -END PGP SIGNATURE-
Re: Bug#283903: ITP: dbconfig-common -- common framework for packaging database applications
hi paul, On Fri, Dec 03, 2004 at 12:09:38AM +1100, Paul Hampson wrote: > _Sweeet!_ What's the timeframe on seeing this? And any chance > of it making Sarge? honestly, i think i'd rather not see it go into sarge, at least while it's still half-finished and possibly buggy. of course i reserve the right to change my mind on this, but no matter what it would need to be used and tested by a much larger audience first. now that mysql support is nearly complete, i think it's actually worth uploading into unstable. however, i think i'd like to drop it in experimental first and get somebody other than me to actually use it. sean -- signature.asc Description: Digital signature
ldap - a completely new method for fetching lists of packages?
hey folks, in the past year or so i've been spending a fair amount of time with ldap. a while back, the thought occurred to me, why not put the list of available packages in ldap? so.. i did that. i found if you put a timestamp with the package on its way way into the ldap tree, you could then do ridiculously fast queries on what's new. this could lead to exponentially faster apt-get updates if a compatible method were added to apt. anyway, it's not horribly useful as it stands now, but it's a pretty neat proof of concept. if you're interested: ldap server ip: 130.58.64.9, port 3389 base dn: dc=debianpackages,dc=swarthmore,dc=edu please, please treat this machine politely. it's my workstation and i have no qualms with turning off slapd if it's getting in the way :) a sample from the ldap tree: dc=debianpackages,dc=swarthmore,dc=edu cn=dists cn=sarge cn=sid cn=woody cn=contrib cn=non-free cn=main cn=binary-i386 debPackage=3dchess you'll notice that this is almost an exact copy of the directory hiearchy on an ftp site. probably not necessary, but i needed something to start with. i actually set this up a few months back, and then proceeded to completely forget i had done it. given all the talk lately of a "new packages method", however, i not only remembered, but felt compelled to at least mention it. btw, and haven't touched it in a while so the packages list hasn't been updated since then. anyway, feedback and thoughts are welcome. sean -- signature.asc Description: Digital signature
Re: ldap - a completely new method for fetching lists of packages?
On Thu, Dec 02, 2004 at 12:03:27PM -0500, Simon Law wrote: > On Thu, Dec 02, 2004 at 11:47:38AM -0500, sean finney wrote: > > please, please treat this machine politely. it's my workstation and > > i have no qualms with turning off slapd if it's getting in the > > way :) > > If you're using OpenLDAP, there is no way that this could ever be fast. sounds like you have some experience with openldap too :) seriously though, i think it could in many situations... as it stands now, apt has to refetch the Sources/Packages.gz files from every source listed in sources.list. now, if the apt method kept a timestamp of the last successful update, it could send as part of the ldap query filter something like '(debTimeStamp>$lasttime)'. this would make keeping debian up to date over dialup a much easier experience i imagine. the one major problem with using a method like this is that apt is designed with the assumption that it fetches the list of packages in the same manner that it fetches the packages themselves. i think this could be worked around, but it's the only real stumbling block i see to building an ldap protocol method into apt. sean -- signature.asc Description: Digital signature
Re: RFC: common database policy/infrastracture
hi andreas, On Thu, Dec 02, 2004 at 10:32:50PM +0100, Andreas Tille wrote: > More questions on your version 0.7: > > - I asked in previous mail what to do for PostgreSQL support. While >having a quick view on the code I wonder if just using a variable >for the database server most of the code could be shared between >databases servers. Is this to naive? most of the script stuff could be shared in between the two, yeah. i designed the system such that it could eventually handle supporting multiple database types, as well as packages that support multiple database types themselves. then, i proceeded to start with what i know :) currently, i'm using code from wwwconfig-common for doing the actual db stuff, and there is pgsql support in that package, so i don't think implementing pgsql support would be initially too hard. > - The application I want to package (GnuMed) has a bootstrapping >script using a configuration file which cares for installation >of several SQL code files in the correct sequence. This >bootstrap script has to know the database administrator password. >Formerly I did this the following way so dbconfig-common provides two hooks for running install/bootstrap/upgrade code. the first is just a plain sql file, the second is a shell script that can effectively do anything. i have not tested the latter at all, but have written code that i think will work. the dbconfig-common-using.html document provides the details. however, in both cases i don't have it set up to run as the database administrator, that was really a design choice and not a limitation, and if it turns out it's not worth it i could have it run as administrator instead. > ... > db_get gnumed/pgsql/admin-pass > insert_passwd_into_temporary_config_file $RET > bootstrap_gnumed_database --config temporary_config_file > rm temporary_config_file > >My problem is now: How to address gnumed/pgsql/admin-pass in >your dbconfig-common framework? the big question in my mind is what about the package needs administrative access? this might stem from my not understanding differences between mysql and postgresql. sean -- signature.asc Description: Digital signature
Re: ldap - a completely new method for fetching lists of packages?
On Thu, Dec 02, 2004 at 07:08:17PM -0500, Daniel Burrows wrote: > On Thursday 02 December 2004 11:47 am, sean finney wrote: > > exponentially faster > > How, exactly, is this "exponentially faster"? Is it guaranteed to run in > logarithmic time relative to a normal download? > > Sorry to bug you, but I see this phrase being used a lot to mean "a whole > lot faster" and it's one of my pet peeves. :) right you are. bad computer science graduate. bad! it would perhaps be several orders of magnitude faster, but not exponentially in the mathemtical "big O" sense. sean -- signature.asc Description: Digital signature
Re: removing in postrm rc*.d symlinks that I did not create
On Thu, Dec 16, 2004 at 12:34:21AM +0100, Nicolas Boullis wrote: > But a user felt concerned that, in the future, he may remove the package > and forget to delete the links. Then I thought I could remove the links > in postrm on purge, considering they are part of the package's > configuration (their absence being the default configuration). if the package is removed, the init script should just exit with 0 status. removing the links during purge would also be appropriate. you could also install the links by default, but have some other variable in /etc/default/$package control whether or not it actually starts (i think somebody else has mentioned this too). sean -- signature.asc Description: Digital signature
Re: RFC: common database policy/infrastracture
On Thu, Dec 16, 2004 at 08:27:20AM +0100, Andreas Tille wrote:
> Yes, but I do not want to store the password *anywhere* - it could even
> be removed from debconf database because it makes no sense to store it
> in case the local maintainer changes the database password the value
> is absolutely useless in any config file or debconf database. Moreover
> it is even a security risk to store a password in an additional place.
well, the admin pass shouldn't be stored anywhere, or at least the
admin should be prompted whether or not the admin pass should
be stored. this is not the current behavior of dbconfig-common,
but it is the planned behavior.
> So my question remains: How to obtain the admin-pass value for the
> database application in question *inside* the postinst script.
> Otionally we should remove it from debconf database in the end of the
> postinst
> script.
ah. the short answer for the time being is that there's a variable
dbadmpass, which will have the answer stored. if your application
wants to get the admin password too, i don't see any problem with doing
a db_input/db_get again on the admin password question (it is a question
belonging to your package, after all), though if the password isn't
stored the admin could be prompted twice.
but something to point out: dbconfig-common already performs the
administrative actions needed to set up the database and database user
in the first place, so does your package even need the admin password?
> Sure. My problem with your current 0.7 version is that yu provide *.mysql
> scripts which are about 90% reusable for postgresql. IMHO we should do
> something like
>
> {config,postinst,postrm,preinst,prerm}
>
> which source a further file containig special things for the database
> in question according to the variable $DBTYPE like
>
> . /$DBTYPE/`basename $0`
take a look at 0.8 :) this was the plan all along, but i had to start
with what i knew. also, i discovered that you can't reliably use
$0 in the maintainer scripts because when a package is first
preconfigured before being unpacked the filename doesn't follow
the same naming scheme. but now there are subscripts for
the supported mysql and pgsql database types, and a larger common
type (which will eventually support applications that support
multiple db types):
mini-me[~]10:28:00$ ls /usr/share/dbconfig-common/dpkg/
commonpostinstpostrm.mysql preinst.pgsql
configpostinst.mysql postrm.pgsql prerm
config.mysql postinst.pgsql preinstprerm.mysql
config.pgsql postrm preinst.mysql prerm.pgsql
> >a ". /etc/dbconfig-common/$package.config" should take care of that.
> As I said - I do not want to write passwords into extra files. But if this
> file would be created by the config script I could read this file in
> postinst
> and remove the password afterwards from there while keeping the other
> values untouched. I did not really tested the dbconfig-common stuff because
> I was unsure about the postgresql issue but did I understand you right,
> that this file exists after finishing the configure script?
for the admin pass, it should be configurable globally whether or not
the admin password is stored at all. for the user password, it will
have to be stored in a file somewhere anyway for whatever application
uses the database, so i'm not too concerned about that.
i'm not against providing a way around that, however, if there really
is a situation in which you wouldn't need the password.
> Well, the policy speaks only about *configuration*. But the main database
> is installed in the *postinst* script. I did not found anything about the
> fact that the postinst from a dependant package has to be installed first.
> But the locale part of the database only installs if the main server exists
> in the postgresql database.
i believe that when policy speaks of configuration it is in fact
speaking of the postinst script. the .config script is usually
referred to as "pre-configuration". with pre-configuration, it is
true that you can't rely on any dependencies being met, but touching
files in the .config script is generally a bad practice, and i don't do
anything other than ask debconf questions in the config script.
sean
--
signature.asc
Description: Digital signature
Re: RFC: common database policy/infrastracture
On Thu, Dec 16, 2004 at 04:17:11PM +0100, Olaf van der Spek wrote: > Ah, k. It makes less/no sense to store that password. > But I wonder, is there no way to use the 'power' of the root account > to do such DB administration without password then? in mysql, at least, there is. however, you have to take the database down in order to do it, which isn't really acceptible imho. sean -- signature.asc Description: Digital signature
Re: removing in postrm rc*.d symlinks that I did not create
On Fri, Dec 17, 2004 at 02:16:00AM +0100, Nicolas Boullis wrote: > > if the package is removed, the init script should just exit with 0 > > status. removing the links during purge would also be appropriate. > > So you think lintian is wrong to complain? no, i think lintian is correct to complain, but that you're also within reason to remove those symlinks if the package is purged. > > you could also install the links by default, but have some other > > variable in /etc/default/$package control whether or not it actually > > starts (i think somebody else has mentioned this too). > > Yes, I know such solutions but don't like them much. But if "my" > solution is proved to be wrong, I'll implement such a workaround... what's so bad about such a solution? i think it's simple to implement, easy to understand, and less prone to break. sean -- signature.asc Description: Digital signature
Re: Orphaning some packages
hi thorsten, On Sat, Jan 01, 2005 at 04:14:03PM +0100, Thorsten Sauter wrote: > I plan to orphan some of my packages. At the moment I have not enough > time for those packages. > >cacti - Frontend to rrdtool for monitoring systems and services i'm a cacti user myself and would be happy to take this one over. at some point i even wrote up some code to help transition people from the version in woody, which i could probably dig up. sean -- signature.asc Description: Digital signature
Re: Orphaning some packages
hi thorsten, On Thu, Jan 06, 2005 at 06:08:02PM +0100, Thorsten Sauter wrote: > | i'm a cacti user myself and would be happy to take this one over. at > | some point i even wrote up some code to help transition people from > | the version in woody, which i could probably dig up. > > yes. Please take it. okay, when i return from VAC in three days i'll start packaging the new upstream release for it, and take over the package with a new upload. have you filed an O: bug against it? sean -- signature.asc Description: Digital signature
Re: PHP application packaging policy/best practice?
hi there, On Sat, Jan 08, 2005 at 03:05:15PM +0100, Jérôme Warnier wrote: > > Any thoughts? > I collected some interesting Debian packaging Web Applications policy > drafts some time ago: > http://glasnost.beeznest.org/articles/184 to throw another link out: http://people.debian.org/~seanius/policy/ right now, there's a heck of a lot more work done on the database-specific aspect of web-applications, though it's my intention to eventually cover the whole gamut. my two recommendations are to use /usr/share/$pkg (or a subdir) for the application pages, and don't modify configuration files of other packages. sean -- signature.asc Description: Digital signature
Re: Orphaning some packages
hi martin, On Tue, Feb 01, 2005 at 02:11:30PM +, Martin Michlmayr wrote: > > okay, when i return from VAC in three days i'll start packaging the new > > upstream release for it, and take over the package with a new upload. > > What's the status of this? i haven't finished packaging the new upstream version, but am actively working on it, albeit somewhat slowly. would you like me to follow up with you when i have, or would simply closing the wnpp bug be enough? sean -- signature.asc Description: Digital signature
Re: Bug#293561: ITP: player -- music player and organizer for GNOME
On Fri, Feb 04, 2005 at 01:39:16PM +, Steve McIntyre wrote: > Please use a less generic name. "player" alone means very little and > is likely to cause confusion. also, keep in mind that a package named "player" (different software) was previously ITP'd, and the packager was told the same thing: http://lists.debian.org/debian-devel/2004/11/msg00553.html might i suggest something like "gnome-player"? sean -- signature.asc Description: Digital signature
Re: what is /.udev for ?
On Wed, Feb 09, 2005 at 06:51:11PM +0100, Björn Krombholz wrote: > .dev is just a binding to the original (static) /dev/ that is created > before udev mounts it's dynamic /dev over the existing one. So if you > rm everything in /.dev you would delete everything in /dev which might > be needed at boot time before udev is initialized. how does /.dev fit in with the fhs? sean -- signature.asc Description: Digital signature
Re: what is /.udev for ?
On Wed, Feb 09, 2005 at 10:46:29PM +0100, Marco d'Itri wrote: > On Feb 09, sean finney <[EMAIL PROTECTED]> wrote: > > > how does /.dev fit in with the fhs? > It does not, but there is no other place to put it. Just do not look at > it and it will not bother you. that's a great line of reasoning. :p seriously though, is there really no where else that it can go? i'm not too familiar with udev, but i'm guessing that it has to go on the root partition, or at the least it can't go under a directory that could possibly be mounted over it. so that precludes /var, which is too bad. > If you really can't stand it, then unmount the bind mount and rmdir the > directory. It will not be created again. must it be mounted for everyone, or is it merely a convenience/necessity for a few people in specific situations? if the latter is true, wouldn't it be better to default to not having it mounted and give a way to have it mounted for those who need it? sean -- signature.asc Description: Digital signature
Re: what is /.udev for ?
On Thu, Feb 10, 2005 at 12:13:40AM +0100, Marco d'Itri wrote: > > must it be mounted for everyone, or is it merely a convenience/necessity > > for a few people in specific situations? if the latter is true, wouldn't > For people who want MAKEDEV to keep updating the static /dev. that hardly sounds like a necessity then. why not defualt it to off, and put instructions or commented out code in the init script? sean -- signature.asc Description: Digital signature
Re: eleventh-hour transition for mysql-using packages related to apache
On Fri, Feb 11, 2005 at 10:15:55AM +0100, Francesco P. Lovergine wrote: > FYI: new mysql FLOSS includes OpenSSL license, so many packages could > migrate to current libmysqlclient starting from no starting from now.. that's great to hear! i'm cc'ing the relevant wishlist bug i have open against mysql-server. christian: any chance of getting an openssl enabled version of the mysql-client and mysql-server packages? sean -- signature.asc Description: Digital signature
Re: Request for Help: apt 0.6
On Mon, Feb 14, 2005 at 08:04:51PM +0100, Peter Palfrader wrote: > A similar 2 key system is probably a good idea for security, and maybe > also for the normal rotated keys (just ship 2005 and 2006 keys now). i think having two keys would make logistics a lot simpler for release upgrades, assuming we had a system that mandated valid gpg signatures. like you suggest, only use one of the two keys, and additionally have the backup key's secret stored offline in a safe place (does SPI have a lock box or safe deposit box we could use?). when it comes time for a new release, or if there is a serious security breach, et c, the new key could be brought out, used to sign a new backup key (which would be placed back in the lockbox), the package providing the key could be updated, and life could happily go on. sean -- signature.asc Description: Digital signature
pwc-source headed for unstable this weekend
i've been using this new pwc driver for a while now and have not had any problems with it, tested on i386 and amd64 boxen. so, after looking over the latest version, assuming there are no new issues i'll plan on uploading the pwc-source package to unstable. i don't think this really warrants a cool off period in experimental, but if someone has a reasonable objection then i will put it there instead. i'll probably do this on saturday. quoth teemu: > Since this package claims to be GPL (although there might be issues with the > reverse engineering which this code is based on) is there any reason not to > integrate this code into the kernel-source package and have the pwc.ko > module compiled automatically to kernel-packages? > > The kernel-package-2.6.10-1-686 package already contains several usb-webcam > drivers in the /drivers/usb/media/ directory which are approximately the > same size as pwc.ko. i suppose it could be added to the debianized kernel source package, but since the original author asked to have it yanked from the mainline kernel and it is now itself forked and maintained outside of the kernel, i think this approach makes the most sense. at least for the time being. sean -- signature.asc Description: Digital signature
Re: pwc-source headed for unstable this weekend
On Thu, Feb 17, 2005 at 09:08:11PM +0100, Eric Lavarde wrote: > pwc: no version for "struct_module" found: kernel tainted. i'm guessing that this has to do with how you compiled the module. i don't get this message if i use "m-a build pwc-source" or the appropriate --append-to-version flags with make-kpkg. could you provide a little more info? > pwc: Unknown symbol video_devdata ... these symbols comes from videodev, which should be loaded automatically before pwc as the pwc module lists it as a dependency. strange... something i really hadn't put much thought into is how this package should handle the pre-existing pwc module found in 2.6.8 and earlier. i guess a conditional diversion should be added? i'll file a phony rc bug against pwc to keep it out of sarge until this can be handled properly. sean -- signature.asc Description: Digital signature
b.d.o -> ldap gateway reeeeaally slow
example below. is this a problem of the server being generally over-taxed, or just a sluggish ldap implementation? in either case, has someone looked to see if the ldap db could be optimized/indexed? if not and someone could send me the slapd.conf i could send some recommendations on things to speed it up... sean (note, this query *should* return no results, i'm just surprised by the delay) sativa[~]16:49:30$ time ldapsearch -x -h bugs.debian.org -b dc=bugs,dc=debian,dc=org '(&(debbugspackage=wuzzah)(debbugsstate=open))' debbugsid # extended LDIF # # LDAPv3 # base with scope sub # filter: (&(debbugspackage=wuzzah)(debbugsstate=open)) # requesting: debbugsid # # search result search: 2 result: 0 Success # numResponses: 1 real5m40.462s user0m0.017s sys 0m0.003s -- signature.asc Description: Digital signature
splitting a source package into 2 source packages
hi, i'm maintaining a source package that produces two binary packages. however, one of the packages is built from a seperately distributed (same author, same website, but different tarball and versioning scheme) tarball. so i'm thinking these two packages should be generated from their own respective tarballs (and i'm not sure why they weren't in the first place). however, one thing that's not clear to me is whether or not the new second source package will have to make it through the NEW queue. if it does, this is a problem given that NEW seems to be stalled and the previous version of the package will be totally broken when the other is updated. comments would be appreciated... thanks. sean -- signature.asc Description: Digital signature
Re: splitting a source package into 2 source packages
hi josh, On Sat, Feb 26, 2005 at 02:18:19PM -0500, Josh Metzler wrote: > I seem to recall hearing that NEW processing is based solely on binary > packages, so that the new source package would not need to go through NEW > if it creates a binary package that is already in the archive. > > I couldn't find anything about this through google, though, so it may be > best to upload to experimental first and see if your new packages go right > in or not. istr the same thing, and was thinking that this might be the case. since i don't suppose the ftp-master illuminati are going to come out of hiding just to answer this question, i guess i'll upload, find out, and report back :/ sean -- signature.asc Description: Digital signature
[OT] maildir (was Re: procmail and Large File Support)
can't help but chime in here :) On Mon, Feb 28, 2005 at 09:22:30AM +1100, Brian May wrote: > Not every situation warrants using maildir, it uses a large number of > inodes, is slow to scan (yes, mbox isn't very good either), > inefficient at storing large number of very small files (due to block > size limitations of file system), and more complicated to > transfer/move/share. it does use a large number of inodes, but i've found that even on large filesystems with many users, there's not a real risk of starving the fs of inodes. ymmv. i'm not sure about the transferring/moving/sharing though. figuring the average email is about 13-15k, i believe an ext2/ext3 filesystem created with default options would fill up before running out of inodes. > Of course, all of these factors depend on the file system used. I am > confident somebody could point out a file-system that eliminates many > of these disadvantages. recent versions of kernel/ext2/ext3 have built-in dirent hashing, which cuts heavily on the many-files penalty. another benefit of maildir is that when you modify a single message, you only need to modify the individual file, as opposed to the entire mailbox. in some of the sloppier imap servers (*cough* uw-imap *cough* *cough*), this can cause huge, grind-your-server-to-a-halt performance hits as deleting, or merely reading a new message necessates a huge amount of i/o. sean -- signature.asc Description: Digital signature
Re: [OT] maildir (was Re: procmail and Large File Support)
On Sun, Feb 27, 2005 at 06:51:32PM -0600, Ron Johnson wrote: > That seems awfully huge. In my (Maildir) archive of d-u, the > average size is 4,959 bytes. Of course, there are no html mails. > Though, even in my Evolution list archive, where there are many > more html-mails, the average size is only 6,097. i came up with the number by totalling the mailbox sizes of a 3000 user mail system, and then dividing by the total number of messages in these mailboxes. this generated a number around 13k average message size. i had to do this as part of assessing the feasability of migrating to maildir without reformatting the filesystem. > > recent versions of kernel/ext2/ext3 have built-in dirent hashing, which > > cuts heavily on the many-files penalty. another benefit of maildir > > is that when you modify a single message, you only need to modify the > > I thought it was "illegal" to modify a message. marking a message as read is one example. moving a message from one mailbox to another is another example. although it's not modifying the message itself, it's moving its location, which with a crappy imap server can mean re-writing the contents of two mailboxes. sean -- signature.asc Description: Digital signature
Re: [OT] maildir
On Tue, Mar 01, 2005 at 09:03:06AM +1100, Brian May wrote: > Also, all mailing list software I have seen so far exclusively uses > mbox files. > > Sure, these are implementation issues that could be solved, but > currently mbox wins. if the use of your stored mail is append-only and read-only, then mbox is the best way to go, for reasons you mentioned. it sucks for just about anything else though. sean -- signature.asc Description: Digital signature
Re: splitting a source package into 2 source packages
On Tue, Mar 01, 2005 at 12:29:09AM +0100, Bill Allombert wrote: > Given that some people might find offensive to be compared to > illuminati, I don't think this is the best way to engage the ftp-master. > YMMV. perhaps i should have made it a bit more apparent that my tongue was slightly in-cheek when i said that. it was also slightly not in-cheek, as i do feel that the world of ftp-master is often shrouded in a veil of secrecy. however, i by no means meant to offend anyone personally and if i have i withdraw the comparison. sean -- signature.asc Description: Digital signature
please test new version of cacti in experimental
hi there, i've packaged the next upstream version of cacti, which i'll be keeping in experimental until i work out this whole single source -> multiple source for the 2 binary packages formerly produced by cacti. in the meantime, i would be very interested to hear how the upgrade path from the previous version works for folks. thanks, sean -- signature.asc Description: Digital signature
Re: splitting a source package into 2 source packages
On Mon, Feb 28, 2005 at 10:04:03PM +0200, Cesar Martinez Izquierdo wrote: > > istr the same thing, and was thinking that this might be the case. > > since i don't suppose the ftp-master __ are going to come out > > of hiding just to answer this question, i guess i'll upload, find out, > > and report back :/ > > Please, do it (report back). I'm interested in the same question. looks like it works, as long as the binary packages have the same name you can split a source package into two source packages without having to traverse new. huzzah! sean -- signature.asc Description: Digital signature
announcing first release of common database infrastructure package
hey folks, you might remember some time ago i started a thread[1] or two[2] about developing a consistant policy/feel for how database (more specifically rdbms) application packages should work. well, since then i've spent a lot of time working on both a 'best practices' document as well as a debian developer toolkit for easily implementing the previously mentioned suggestions. dbconfig-common abstracts almost 100% of the database-maintainance related work into a common package that can be used by any package maintainer. it consolidates efforts, code, and bugs into a single more easily maintainable place, provides for an easier experience on the part of the developer, and a more integrated experience for the end-user/admin. anyway, i've uploaded my first "public" release of dbconfig-common to experimental. minus a couple bells and whistles (and probably plus a bunch of undiscovered bugs), it's pretty much feature complete for what's mentioned on my webpage[3], so at this point i'd like to call for some brave volunteers. anyone who is tired of having to spend hours maintaining their home-rolled mysql/pgsql mangement maintainer script code is whole heartedly encouraged to check this out! sean [1] http://lists.debian.org/debian-devel/2004/10/msg00340.html [2] http://lists.debian.org/debian-devel/2004/10/msg00962.html [3] http://people.debian.org/~seanius/policy/dbconfig-common.html -- signature.asc Description: Digital signature
Re: announcing first release of common database infrastructure package
to reply to my own post... i was under the impression that because dbconfig-common was previously in experimental that i wouldn't have problems related to the stalled NEW queue, but i was wrong. so you can get them here: deb http://people.debian.org/~seanius/policy/examples/ ./ deb-src http://people.debian.org/~seanius/policy/examples/ ./ you want version 1.4. thanks, sean -- signature.asc Description: Digital signature
Re: announcing first release of common database infrastructure package
hi martin, On Mon, Mar 07, 2005 at 01:23:51PM +1300, Martin Langhoff wrote: > sounds really good. How do your scripts relate to the db management > scripts provided by wwwconfig-common, maintained by Ola Lundqvist > <[EMAIL PROTECTED]>? my code is a superset of what's done in wwwconfig-common. providing the scripts/code to manage databases is only half of the idea behind this project. the other half is providing a normalized method for doing so (that is, not just the scripts, but debconf questions, translations, and a pre-arranged set of code for each maintainer script). > I suspect your package should be either supercede wwwconfig-common or > be rolled into it. this supercedes what's in wwwconfig-common. in fact, much of the underlying internal code is taken from or at least originally based on code from that package. sean -- signature.asc Description: Digital signature
Re: Key management using a USB key
On Tue, Mar 08, 2005 at 12:46:46AM +0100, David Härdeman wrote: > o In order to minimize the exposure of the key, it might be wise to > mount the drive, load the keys (ssh,gpg) into the memory of the > appropriate agents and then unmount the drive. On the other hand, does > this actually provide any extra security as opposed to having the key > mounted for the entire session? i have a usb/hotplug/ssh-add script that loads an ssh key off of a usb stick, and removes it when the usb stick is removed. if you're interested i can send you a copy off-list. sean -- signature.asc Description: Digital signature
Re: Key management using a USB key
hi, On Mon, Mar 07, 2005 at 09:52:31PM -0800, Steve Langasek wrote: > > i have a usb/hotplug/ssh-add script that loads an ssh key off of a usb > > stick, and removes it when the usb stick is removed. if you're > > interested i can send you a copy off-list. > > Any reason not to post it on-list? I was hoping to improve the > security/usability of my own setup based on the best practices offered up in > reply to this thread. well, me wanting to do things the "right way" it ended up being a pretty long script and i didn't think the list would appreciate random shell scripts flying around. but, i'll go ahead and put it online: http://www.seanius.net/linux/keyloader/usb-storage how it works: - plop the script in /etc/hotplug/usb/ - copy your public/private keys onto a usb disk, list them in ~/.keyloader (KEYS="key1 key2", read script comments for more info) - plug in the usb disk - ssh-add xterm (or ssh-askpass if you have it installed) pops up if it needs a passphrase, and your key is loaded - remove the disk - key is unloaded. i think the approach i take is fairly sound securitywise, but i'd appreciate someone else taking a look at it. also, i'm not sure whether it still works on 2.4 kernels, i haven't had a 2.4 machine to test on in a while. sean -- signature.asc Description: Digital signature
Re: announcing first release of common database infrastructure package
hi christian, On Mon, Mar 07, 2005 at 05:58:43PM +0100, Christian Perrier wrote: > You might want to post a call for translations for the common > templates in the package, as I understand this package includes a set > of common templates. yeah, this project aims at making life easier for three distinct groups of people: the package maintainers, the "local admins", and the translators. > This can be made by just posting to debian-i18n with a pointer to the > templates.pot file. You just need to give a bit of context so that > potential translators know what this is all about (having a common set > of templates for DB-related packages in order to avoid them > translating the same thing over and over). okay, i'll do that some time in the near future. i'd like to give a final look over my templates to make sure that i like my own english before i ask anyone to translate it though :) > I promise you'll soon get tons of translations in > various languages and I'll personnally give some push so that > translators know this is a really important thing to translate. thanks! sean -- signature.asc Description: Digital signature
Re: announcing first release of common database infrastructure package
On Tue, Mar 08, 2005 at 10:51:48PM +0100, Christian Perrier wrote: > Comments about the templates: wow... thanks for all these. i'll work on incorporating these suggestions in with the next version, before i make a request for translations. sean -- signature.asc Description: Digital signature
Re: Key management using a USB key
hello, On Wed, Mar 09, 2005 at 01:38:22AM +0100, David Härdeman wrote: > o when the usb key is inserted, the user is prompted for a password to > the encrypted loopback file which is then mounted, the ssh keys within > are fed to ssh agent, and the file is unmounted again. you could easily extend the script i wrote to unencrypt/loop-mount a filesystem-in-a-file without too much effort. prod me enough and i might do it myself. > o hopefully, in combination with libpam-usb and/or libpam-mount, it > would be possible to reduce the number of password prompts to one. you should only need a password for encrypted things. since the hotplug script runs as root you can have that take care of all the other details. so, as long as you have either an unencrypted ext2 filesystem-file with encrypted ssh-keys or vice versa, you should only need one password. > Bonus stuff: > > o It would be a neat trick to have the keys which were once loaded from > the usb key into the ssh agent automatically removed from the agent > when the key is removed from the computer (meaning you could quickly > yank the key, go for lunch, return, reinsert it and continue working). my script already does this. in fact, it's selective enough to leave other keys that it didn't load still in memory. this was a little tricky to accomplish, and is done by copying the public key into a temporary location (under /var/cache/keyloader/pubkeys/$USER), and when the device is removed those keys are passed to ssh-add -d. > o check both at insertion time and at "first login" time for the usb key > (so that the key can be either inserted from boot or inserted during an > existing session). that would be nice, though a quick workaround is to remove and re-insert the key :). > o a /dev/udev.d file which is run after the node is created that does > the necessary root-level setup and then calls > > o a user-specific script which loads the keys (and prompts for necessary > passwords) etc. better watch out where root and the user cross paths... sean -- signature.asc Description: Digital signature
Re: Cron-standard package to replace current tasks in 'cron'
hi,
On Wed, Mar 09, 2005 at 04:00:49PM +0100, David Schmitt wrote:
> Why {c,sh}ouldn't they be implemented as cron.daily scripts in the respective
> packages?
i'd like to ack that. however, if the non-arch specific stuff (generic
cron jobs, init scripts, etc) for cron is still sufficiently complicated
it might make sense to have an Arch: all cron-common type package.
sean
--
signature.asc
Description: Digital signature
Re: Cron-standard package to replace current tasks in 'cron'
hi, On Wed, Mar 09, 2005 at 08:36:24PM +0100, Javier Fernández-Sanguino Peña wrote: > They are already are, please review the (simple) package. For some of the > packages that provide them (like systat) the tasks are pulled in from the > depends:, for other packages there might be users that might not want an > active cron job. Take 'sac' for example, a user that installs sac, > installs a tool to do something, he doesn't necessarily want a cronjob to > send sac's output to him weekly, for example. i would argue then that user should use a tool called "rm", or "mv" :) sean -- signature.asc Description: Digital signature
Re: Debian LDAP schema for Debian Packages
hi, On Thu, Mar 10, 2005 at 12:15:32PM -0300, [EMAIL PROTECTED] wrote: > I wonder if there is a debian ldap schema to > store debian packages. Better yet, > are we going to have one ever? while i am not the maintainer of the debian oid arch, i wrote an unofficial debian package schema some time back for an packages->LDAP gateway i threw together[1]. at the time there didn't seem to be much interest by other people, so i haven't worked on it in several months. sean [1] which could hypthetically allow apt-get update to only need to fetch changed package entries instead of the entire Packages.gz, among other neat features. -- signature.asc Description: Digital signature
Re: Key management using a USB key
On Mon, Mar 14, 2005 at 09:30:54AM +0100, Matthias Urlichs wrote: > > o gpg-agent support in the same manner as ssh-agent would be neat. I > > understand that this requires gnupg 2.0 though. > > While gpg-agent is built from the gnupg 2.0 sources (a development > snapshot of which is currently sitting in the NEW queue ...), the agent > itself is perfectly useable with gnupg 1.2. then i'm wondering why someone hasn't packaged it already :) sean -- signature.asc Description: Digital signature
Re: Key management using a USB key
hi, On Mon, Mar 14, 2005 at 02:19:46PM +0100, Erik Schanze wrote: > Your fingers lie on a bloody wound. ;-) > > There was ITP #187548 for newpg, but was closed last summer. aha. > Please reopen it and make a package for newpg to make KMail-Users happy. > If you have not enough time, would you sponsor such package? i would be willing to do so only if james thought it was okay (it's his package, so it's his call). i think what would need to be done would be something along the lines of: - create a source package gnupg2 - gnupg2 *only* produces package(s?) for the peripheral binar(y|ies) - when gnupg releases an official version 2, james uploads a new gnupg that replaces the previous source package (or would it have to have the same name?), and generates all binary packages. james: thoughts? also, istr seeing something about gnupg2 needing a new version of some library already present in debian. if that's the case, i don't think this will fly at all. that said, there's nothing wrong with hosting binary packages somewhere else and if you do so without breaking my system i'll try them and build support for gpg-agent into the keyloader scripts. sean -- signature.asc Description: Digital signature
Re: [RFC] OpenLDAP automatic upgrade
hi torsten, much of what you're trying to do touches a similar vein to a project i'm currently working on[1]. while unfortunately i haven't built in any support for ldap (only mysql/pgsql), the topics, concepts, and practices are directly relevant to your situation and i'd recommend reading through it. i'd also welcome any comments you have. On Tue, Mar 15, 2005 at 01:36:17AM +0100, Torsten Landschoff wrote: > a) the preinst checks if the database format has changed between the old > version and the version that we are upgrading to is this an underlying database format change, or simply stricter schema checks? if it is a change to the db format, will the new server work with the old format (even if less optimally)? if so it might make a better quality package to leave the data in the old format and provide instructions to the admin (who will know more than you about the directory server) for how to get the new optimised format. > b) if it has each LDAP directory is dumped to .ldif using slapcat might want pipe that through gzip/bzip2 :) > c) the postinst checks if an ldif file is available from the old version if this is an upgrade that will always need to happen in between 2.0/2.1 and 2.2, you should rely on the version numbers provided by dpkg instead. set the preinst to fail if it can't successfully dump the file, which will keep the admin in as sane of a state as possible (with a working old install) > d) if it is, the fix_ldif script is run to adapt the contents of the > directory to the more strict checking of the new OpenLDAP server does this mean you will have to drop the contents of the ldap server before re-adding them with the correct format/syntax? > e) next old data in the directory of the database is moved away so the > new DB can be created that's really scary sounding. remember that some people have some Important Data in these servers. at the *very* least you'll want to give them a big scary debconf warning and the ability to quit the install. > f) the corrected ldif file is piped into the new directory using slapadd instead of dumping to an ldif, moving the database out of the way, and reading back in from a corrected ldif, could you do the following? - dump the data in ldif format through a pipe - pipe it through your syntax/schema checker, outputting all the violations, perhaps even as ldap modify commands - if there are no violations, continue with the upgrade - otherwise leave this in a file somewhere, and try to perform the commands - if this fails, tell the admin where the file is and let them perform the modifications before they upgrade (assuming this will not break a 2.0 server), and fail the install gracefully. > This sounds simple. There are a lot of problems so: no it doesn't :) > ad b) where is that .ldif file to be saved? For small directories not an > issue (take /var/backups or something). For big directories it should be > on a different disk than /var/lib/ldap with enough space to get sensible > performance. somewhere under /var/cache would be appropriate, though you might want to give the admin the option via debconf to put it somewhere else. > ad c) what happens if the upgrade fails for incompatibilities in > slapadd? will the next dpkg --configure slapd give the right value for > previous version to the postinst? like i said earlier, you'll want the upgrade to fail as early as possible, ideally in the preinst before you've unpacked the latest version. this way every call to dpkg --configure will provide the same values for the current and old version, and failure won't leave the admin with a totally b0rken system. > ad e) where to move the directory? Should be on the same disk so that > the mv command is most effective. if you really have to move the databases, i'd recommend against hard coding where you put it. give the admin the option of where to put it. he/she will know much more about where there's free space to put it. hth, sean [1] http://people.debian.org/~seanius/policy/dbapp-policy.html -- signature.asc Description: Digital signature
Re: [RFC] OpenLDAP automatic upgrade
hey, On Tue, Mar 15, 2005 at 10:02:23PM +0100, Torsten Landschoff wrote: > As far as I can see your are mostly targetting packages /using/ a > database? Good work so far looking at your text. The few database using > packages I tried to install did not work as good as I'd have expected... this is true, though more precisely it's packages needing to manage databases, which i think applies to this case. > The first. Basically upstream changes the database format quite often. > I am even not entirely sure if the database format stays compatible in > the 2.1 or 2.2 line but I'd expect it to. The 2.2.23 Debian packages > uses libdb4.3 instead of libdb4.2 as used in 2.1.x so the reload has to > be done in any case. that sucks. > > if it is a change to the db format, will the new server work with the > > old format (even if less optimally)? if so it might make a better > > No way. double sucks. > > might want pipe that through gzip/bzip2 :) > > Hmm, good question. On a slow system this will hit really hard for big > databases. On the other hand who will run a big LDAP server on a slow > machine... yeah, i'm wondering whether or not that actually makes sense to do, now that i'm thinking about it. you make a valid point though... i would hope there aren't any directory services running on 386's, heh. > > > c) the postinst checks if an ldif file is available from the old version > > > > if this is an upgrade that will always need to happen in between 2.0/2.1 > > and 2.2, you should rely on the version numbers provided by dpkg instead. > > Instead of what? I am using the version numbers from dpkg currently. i think i misread your statement that "if postinst finds a dump file to act on it", as opposed to "if the version changes suggest it should check for a dump file". > > that's really scary sounding. remember that some people have some > > Important Data in these servers. at the *very* least you'll want to > > give them a big scary debconf warning and the ability to quit the install. > > That kind of contradicts seamless upgrades. And at install time (in > postinst) it is already too late in the game. They'd need to reinstall > the old package anyway. if you warn them and give the ability to opt-out in the config, you'll get all the folks who use apt (which preconfigures the packages before unpacking them). if your maintscripts automatically stop slapd during the upgrade, even failing based on their response after unpacking would be okay, as they could back up to an old version before slapd started and mangled their data. > > reading back in from a corrected ldif, could you do the following? > > > > - dump the data in ldif format through a pipe > > - pipe it through your syntax/schema checker, outputting all the > > violations, perhaps even as ldap modify commands > > Way to complicated. In fact I don't even know the exact list of > incompatibilities. okay, just a thought. > > - if there are no violations, continue with the upgrade > > The old Debian configuration created a directory that does not pass the > schemacheck of the new packages so it is almost guaranteed there are > violations. d'oh. > > > This sounds simple. There are a lot of problems so: > > > > no it doesn't :) > > It is mostly working already at least for simple setups. And I did not > get that many reports about upgrade problems. that's definitely reassuring. > > somewhere under /var/cache would be appropriate, though you might want > > to give the admin the option via debconf to put it somewhere else. > > /var/cache? I'd rather not put it there. Quoting the FHS: i think /var/cache is the a sensible default location. the only other location that fits within the fhs is /var/tmp or /tmp, which has even more liberal (the admin should be able to delete anything) requirements. plus, the data can arguably be reconstituted by dumping the ldap database again, assuming nothing goes wrong :) > > if you really have to move the databases, i'd recommend against hard > > coding where you put it. give the admin the option of where to put it. > > he/she will know much more about where there's free space to put it. > > Yes, another debconf question :(( you could do something like - use low priority to prompt for the location (so most folks won't see it) - dump the database - if failure dumping, display a debconf note saying why the dump failed (full disk), and that setting debconf priority to low and reinstalling the package will give the option of where to dump. sean -- signature.asc Description: Digital signature
Re: Key management using a USB key
hi matthias, On Tue, Mar 15, 2005 at 08:02:34AM +0100, Matthias Urlichs wrote: > > - when gnupg releases an official version 2, james uploads a new gnupg > > that replaces the previous source package (or would it have to have > > the same name?), and generates all binary packages. > > > That has been agreed to. i didn't see anything to that regard in the wnpp bug... do you have a pointer to somewhere that i could verify that? also, what about the library issue? assuming james is okay with it and there isn't some kind of library dependency issue, i'd gladly sponsor a gpg-agent. sean -- signature.asc Description: Digital signature
Re: Key management using a USB key
hi, On Wed, Mar 16, 2005 at 01:39:44AM +0100, Matthias Urlichs wrote: > > also, what about the library issue? > > > Which library issue? AFAIK the packages co-exist nicely. istr trying to build gpg-agent from the upstream source but the configure script would fail because i didn't have the appropriate version of one of the gpg-related libraries. the source package seems to build debs okay though, so at least i have something to play with... however, don't you think it's a little pre-emptive to have a gnupg2 binary package when they haven't yet released gnupg version 2? this smacks of the infamous redhat gcc release... > > assuming james is okay with it and there isn't some kind of library > > dependency issue, i'd gladly sponsor a gpg-agent. > > > Umm, s/sponsor/push it through NEW already, dammit/ ;-) ah, sorry, can't help there. sean -- signature.asc Description: Digital signature
Re: Bug#299724: ITP: groach -- pests such as roaches hide under your windows (xroach clone)
On Tue, Mar 15, 2005 at 06:18:43PM -0700, Wesley J. Landaker wrote: > groach is a clone of the classic xroach program, but with multiple > themes, more modern code, and a free license. why would anyone want to use this program? it's so... full... of... bugs... (/me goes and hides under an xterm) sean -- signature.asc Description: Digital signature
Re: Bug#263743: Call For Help - Please support the ppc64 architecture
On Wed, Mar 16, 2005 at 10:24:04PM +, Scott James Remnant wrote: > Because it's a 64-bit version of an already supported architecture. > Having "ppc" and "ppc64" would be fine, as would having "powerpc" and > "powerpc64". Having "powerpc" and "ppc64" is inconsistent. and deviating from an already established standard isn't? i'm wondering what the actual benefits of having a similarly (powerpc/powerpc64) named port are, apart from being aesthetically pleasing. sean -- signature.asc Description: Digital signature
Re: mixing different upstream sources in one package
hi jay, On Sat, Nov 19, 2005 at 12:27:33PM -0500, Jay Berkenbilt wrote: > From time to time, someone announces an intention to package some tiny > script or program, and people suggest including it in some other > package instead to avoid pollution of the archive with lots of tiny > packages. Although I understand the reasoning and the issues here > (additional overhead for each package), this has always bothered me a > little. I'm not sure that, as an upstream author, I would necessarily > want the debian version of my package to be bundled with other > software that was similar in functionality but otherwise unrelated to > my package. as an upstream author, you'd better be allright with it if you've released your software under a free-as-in-speech license. that's kind of the point of Free Software. of course, it goes without saying that any terms of the original work's copyright need to continue to be honored (as you mentioned there can't be any licensing conflicts). for most gpl-within-gpl situations, this simply means updating debian/copyright. > I've recently taken over maintenance of psutils and am gradually > working through the outstanding bugs on that package. A few of the > bugs suggest adding external programs. Assuming there are no other > impediments (like licensing problems), do people generally think that > it's reasonable to do this even if the other packages aren't really > part of the upstream package? If so, are there usual mechanisms for > doing this? What about version numbers? it really depends on the situation, i think, but ultimately it's your call for your packages. as for logistics of doing so, if it's an inclusion of a relatively small amount of code (a script or two) into another non-native/diff.gz package, i see no reason the version should percolate up to the debian package version. if you make modifications to the included program, finding some way to append debian-specific versioning information to the code itself would probably be good enough. as far as how to include the source in a non-native package, i would keep it in the diff and simply mention updates of said program in debian/changelog, and maybe elsewhere in /usr/share/doc/package. if it gets to be a lot of code, that's probably when it's due time to consider splitting it off into another package (someone else already gave such a suggestion). sean signature.asc Description: Digital signature
Re: How to deal with dependencies/conflics on third party packages
hi joerg, On Sun, Nov 20, 2005 at 10:23:58AM +, Joerg Sommer wrote: > I've got a bug report (#336527) my package bootchart-view do not work > with j2re1.3. But j2re1.3 is not in Debian. Can I set a conflict upon a > packages that is not in Debian? But if it do not work with j2re1.3 it > should more than ever not work with older version. But I would assume > older version have different packages names. So I must add a list of > packages names (j2re1.3 j2re1.2 j2re1.1), because I can not use the > version clause (j2re1.3 (<< 1.3)). So what should I do? adding conflicts lines for packages that don't exist in debian has limited effectiveness imo. even if there are packages (blackdown, or whatever) for j2re, i would imagine that there's a large number of users out there (myself included) who simply download the installer from sun and installed java sans-package. i'd consider simply adding a note to README.Debian/NEWS.Debian about said problem, and being done with it altogether. maybe leave the bug open at wishlist+wontfix for reference too, i guess. sean -- signature.asc Description: Digital signature
Re: Spliting packages between pkg and pkg-data
just throwing a quick $0.02 in here,
On Wed, Nov 23, 2005 at 01:51:30PM +0100, Goswin von Brederlow wrote:
> > Well, being able to read the documentation (including the man page) of a
> > binary without requiring the binary to be installed is a good thing
> > IMHO. Especially for big and complex software that is likely to be
> > split to pkg and pkg-data...
>
> I prefer to have a 1:1 correlation between binaries and manpages. But
> that is just me.
i think the idea is that if you have the package providing the binary
installed, you implicitly have the -data package installed. so, does
it matter that if you manually chose to do so, you could have manpages
for binaries not on your system, as long as you could never have
binaries on your system without their manpages?
> Other things would be cron jobs, inetd entries, init.d scripts. I'm
> not sure that putting the init.d script into foo-data is the best
> idea.
there are cases where having these files in a seperate package can
be a good thing. for example, two packages i have direct experience
with (nagios and mysql) both profit from having a single "-common"
(arch: all) package which shares init scripts, web server
configs, etc between multiple server-providing binary packages
(nagios-{text,mysql,pgsql}, mysql-server-{4.1,5.0}).
the proviso is that a little more care has to be taken to make sure that
some of these things behave in the absence of the "binary" package.
policy already states that init scripts (9.3.2) and cronjobs (9.5)
must do so, the other stuff is a little more context dependant.
sean
--
signature.asc
Description: Digital signature
Re: Alternate proposal for Declassification of debian-private archives
On Thu, Dec 01, 2005 at 09:56:48PM +, Dave Holland wrote: > On Fri, Dec 02, 2005 at 08:30:37AM +1100, Robert Collins wrote: > > I think the default behaviour should be to keep the post private, not to > > open it up. That is, if the author and other individuals do not reply, > > the message is kept hidden. > > > > The primary reason for this is that the existing messages were sent to > > debian-private with an expectation of privacy. Folk that have changed > > address or become otherwise not-immediately available may still care, > > and the principle of least surprise should apply. > > > > We can however change the expectations for new messages being sent to > > debian-private, and in 3 years *they* would become public by default. > > Seconded, on all points, for the same reasons. Thirded. sean -- signature.asc Description: Digital signature
Bug#341748: ITP: nagios2 -- A host/service/network monitoring and management system
Package: wnpp Severity: wishlist Owner: Sean Finney <[EMAIL PROTECTED]> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 (explanation for why there needs to be a nagios2 given after the blurb) Package name: nagios2 Version : 2.0 (when released) Upstream Author : Ethan Galstad URL : http://www.nagios.org/ License : GPL Description : A host/service/network monitoring and management system Nagios is a replacement of the Netsaint project. It accept and uses the previous Netsaint modules transparently. . Nagios is a host/service/network monitoring and management system. It has the following features: . o Monitoring of network services (via TCP port, SMTP, POP3, HTTP, NNTP, PING, etc.) o Plugin interface to allow for user-developed service checks o Contact notifications when problems occur and get resolved (via email, pager, or user-defined method) o Ability to define event handlers to be run during service or host events (for proactive problem resolution) o Web output (current status, notifications, problem history, log file, etc.) . Nagios was written in C and is designed to be easy to understand and modify to fit your own needs. . This package contains the next-generation version of the nagios daemon. If you want to install nagios and do not need MySQL or PostgreSQL support, you should install this package. some skeptics may be asking "why do we need a nagios2? why can't we have just one version of nagios in debian?". the answer is that we in fact already have 3 different versions of nagios, one with standard file-based support, a mysql version, and a pgsql version (which are differentiated at compile time). nagios2 does not currently have db support, but will very likely through add-on modules at a future date/time. because this would break existing installations that use the db support, there will be a certain period where nagios2 and nagios co-exist in the archives. after transitional support has been worked out, it will replace the standard file flavor of nagios, and as db support is added in the other two versions will disappear as well. In the end, i aim to have a single "nagios" package, though it will probably take a bit for this to materialize. i'll shortly be importing an initial version of nagios2 into the nagios alioth project cvs archives. if anyone is interested in helping maintain this (or other nagios related packages), please contact me privately as i can always use some assistance! sean -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFDkIWWynjLPm522B0RAgvuAJ0c9o5yL8OBkXxceebOxyydFiD0swCeO4Xr Yg1/K2tcct4wTisehqF94ow= =i3JZ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#342244: mysql-dfsg-5.0: FTBFS on hppa
hi -admin and -devel, executive summary: mysterious and unreproducible ftbfs for mysql, and perhaps other packages on the hppa architecture. a faulty buildd (sarti) is suspected, but afaict all requests for information remain unanswered. i'm suspecting hardware problems, as for mysql this is not the first such ftbfs[1]. originally, a similarly mysterious error occurred where the build didn't even start because installing tetex-bin failed. Frank Küster followed up[2] with debian-hppa as well as debian-admin about the problem, but afaik recieved no response. now, mysql is failing during the execution of debian/rules, in a chunk of code doing no more than a find/xargs/rm[3]. the buildd reports that the job failed do to a lack of activity for more than 150 minutes[4]. On Tue, Dec 06, 2005 at 04:56:58PM +0100, Frank Küster wrote: > I have asked ryan murray and the hppa list about this, but never > received an answer. I don't know whether the problem magically solved > itself (which would again point to a hardware problem) or whether some > admin acted. It would be interesting to find out why the buildd tried > again to build the package after the last one failed - maybe this gives > some insight who did what why when. it would be nice if someone could comment on the matter. looking back in the archives for the hppa list, i see at least one other unrelated post[5] indicating the same problem for multiple other packages, also unanswered so far. this mail was only sent yesterday (20051205) though. however, the poster does point out that the failing packages build just fine on other hppa machines. in the meantime, i'm forwarding this on to d-d (and cc'ing d-a, but not d-hppa as it won't do more good than what's already been done). as much as i hate to stoop to this level, i find often making a public fuss about things is the quickest way to get things going, and i don't know what else can be done. all flames/tar/feathers can be sent my way for having done so and i apologize for having done so if i am in fact totally off-base on my assumptions. sean [1] http://bugs.debian.org/340279 [2] http://lists.debian.org/debian-hppa/2005/11/msg00017.html [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=342244 [4] http://buildd.debian.org/fetch.php?&pkg=mysql-dfsg-5.0&ver=5.0.16-1&arch=hppa&stamp=1133590988&file=log&as=raw [5] http://lists.debian.org/debian-hppa/2005/12/msg00012.html signature.asc Description: Digital signature
Re: Proposal/Request for Comments: Formally extending package Descriptions to handle bulleted lists.
On Mon, Dec 12, 2005 at 03:09:52PM -0800, Daniel Burrows wrote: > The attached text is a first draft of a proposed extension to the > Description field to explicitly handle bulleted lists. The extended wow! that's quite a document. i'm glad to see that people are focusing on the Really Big problems facing debian today. okay, that was a bit punchy... sorry i couldn't help it :) seriously though, i think the proposal is quite well written. the only critique i have is that i think it's maybe going a little too far out there to talk about nested lists, as i can't imagine them being at all practical in what's supposed to be a short, informative description of a package. sean signature.asc Description: Digital signature
init scripts and the "reload" target
heyo, a while back, i noticed that there seems to be some rather inconsistent behaviour wrt doing "/etc/init.d/foo reload". typically this results in a HUP or something similar sent to the daemon in question, causing it to reload configuration, but in some cases the init script's actions are identical to what would happen with the "restart" target. as a result, there is an interesting variety of results observed when the service in question is not running. sometimes reload will fail with a non-zero value (lsb-compliant packages, i believe), sometimes it will exit normally without performing any action (apache 1.x for example), and in other cases it will start the inactive service (apache 2.x, for example). so sayeth policy 9.3.2: restart stop and restart the service if it's already running, otherwise start the service reload cause the configuration of the service to be reloaded without actually stopping and restarting the service, force-reload cause the configuration to be reloaded if the service supports this, otherwise restart the service. The start, stop, restart, and force-reload options should be supported by all scripts in /etc/init.d, the reload option is optional. my take on this is that, while optional, the reload target must not stop and start a service if implemented in an init script. it would then logically follow that reload must not start a service which is not running. is my interpretation of this correct, or am i over-analyzing things? thanks, sean -- signature.asc Description: Digital signature
Re: Andrew Suffield
On Sun, Jan 15, 2006 at 11:58:51AM +0100, Adrian von Bidder wrote: > Do you think your constant bitching is funny? Do you think it achieves > anything? > > There are other DDs who are also involved in intense debates and flamewars > very often, but you're the only one where I constantly get the impression > that you're just being childish, insulting and annoying for the sake of it. ...says someone who just publicly ostracized a fellow dd on a public mailing list. personal opinions of the matter aside, debian-devel is not the place for ridiculing other developers, no matter how justified you feel you may be. please post follow-ups to -private. sean -- signature.asc Description: Digital signature
Re: Severity of architecture-dependent bugs
hi shaun, perhaps someone else will be able to answer this more authoritatively but in the meantime... On Sat, Feb 25, 2006 at 11:30:16AM -0700, Shaun Jackman wrote: > A grave bug has been file against a package I maintain pointing out > that the package does not work on AMD64 and in fact never has, even > though it builds on AMD64. Since it turns out this package has never > worked on AMD64, this bug is not a regression, but the status-quo. > Should such a bug be grave, or merely important? assuming that the bug is in fact grave: as amd64 is currently not officially a supported arch, i would leave the bug at "important", or perhaps even lower. HOWEVER: amd64 will become a supported architecture in like what, 2 weeks? after that point, it could/should be justifiably bumped back up to grave. however "x program from your package does not work" is usually not justification for a grave status. grave is typically reserved for uninstallable packages (that is, dpkg fails), or bugs involving serious dataloss/security issues. sean -- signature.asc Description: Digital signature
Re: custom package error: dpkg -P tries to remove /opt
hi goswin, roberto, et al. On Tue, Mar 07, 2006 at 10:17:35AM +0100, Goswin von Brederlow wrote: > The bigger question is: Why is no package containing /opt? Shouldn't > that be in base-files like all the other core dirs? just a wild guess: for the same reason as /usr/local (policy/fhs) sean signature.asc Description: Digital signature
Re: versioned symbols in shared libraries (upstream != Debian)
On Tue, Mar 14, 2006 at 01:25:21AM +0100, Christian Hammers wrote: > Now MySQL finally closed my bug report to them and provides symbols > in their upstream source. Sadly they look like: > f280 gDF .text 000b libmysqlclient_15 mysql_row_tell > f4d0 gDF .text 0043 libmysqlclient_15 mysql_escape_string > da30 gDF .text 00e1 libmysqlclient_15 mysql_slave_send_query man... i'm not sure whether to laugh or scream :( *2 YEARS AGO* you open a bug report saying they should do this, and their response is "we don't plan to do this, you should only have one version of mysql installed". So then we do all the legwork to get versioned symbols working, and send them a patch. 4 months later, they accept the patch, but change it just enough to make it completely non-compatible with what we've done in the meantime. gee, thanks guys! so this means we need to coordinate another transition, new binary package names, etc, before we've even finished transitioning to the previous package. at least it happened before etch was released... sean signature.asc Description: Digital signature
Re: removing logfiles on purge
yo martin, i don't have enough time to find it, but like a couple years (or more?) ago there was a very, very long thread about logfile removal. the "should logfiles be removed on purge" question can actually be deconstructed into smaller questions: - should /var/log/foo/foo.log be removed on purge? - should (logrotated) /var/log/foo/foo.log.[0-9]*.gz be removed on purge? - should /var/log/foo be removed recursively on purge? i don't remember what the result of the thread was, sorry :( sean signature.asc Description: Digital signature
Re: PostgreSQL-Problem and Problem on Alioth
On Tue, Jan 25, 2005 at 10:38:37AM +0100, Martin Pitt wrote:
> There are two common ways to achieve that:
>
> - Connect as "www-data". For this you need an appropriate PostgreSQL
> user ("createuser www-data" as user postgres). Then you either make
> www-data the owner of the database ("createdb -O www-data mydb") or
> you set the owner to some application-specific PostgreSQL user and
> only GRANT the necessary permissions to www-data (usually you need
> table creation etc. only for package installation and can restrict
> www-data permissions to SELECT/UPDATE).
if i'm understanding correctly, a security drawback of both these
methods is that any web application would effectively have r/w privileges
to every web app's database, right?
> This solution has the advantage that you don't need to modify
> pg_hba.conf (since you can use "ident sameuser" authentication).
which is certainly not to be overlooked. i think maybe a disclaimer
like "if you run multiple applications, this may present a security
risk" might be in order, but it should definitely be an option.
> - Connect as $dbc_dbuser and use "password" authentication. ident
> makes not much sense since the database user has not necessarily
> a system user counterpart (if it has, then this would of course
> work). But if it hasn't, you need a pg_hba.conf entry.
thanks for the clarification on all this. i'm also now spending some
time reading the fine manual (online postgres docs) about
identification/authentication, which will help clarify things a bit.
> I'm open to suggestions about making modifications to pg_hba.conf
> unnecessary in the common case. (I still need some time to read this
what would be helpful here is to hear from a larger number of
debian/postgres admins about how they have things set up, to get
an idea what the most common setups actually are.
also, it looks like pg_hba.conf and pg_ident.conf both have some
kind of @include functionality, which might make messing with either
of the files moot. i'll have to look more into these details...
> unnecessary in the common case. (I still need some time to read this
> thread about the common database infrastructure *sigh*).
you can get the highlights on my p.d.o page :)
sean
--
signature.asc
Description: Digital signature
Re: eleventh-hour transition for mysql-using packages related to apache
On Fri, Jan 28, 2005 at 04:36:05PM +0100, Andreas Metzler wrote: > On Fri, Jan 28, 2005 at 05:03:26AM -0800, Steve Langasek wrote: > [...] > > Over the past six months, the situation has changed significantly. The > > mysql maintainer, mysql upstream, and others have admirably worked through > > the license issues to get a license exception that meets the needs of the > > software that Debian distributes. You can find the current version of this > > license exception at [1]. > > At a short glance this still seems to be missing a OpenSSL exception. > - Has this been resolved? no, afaik the openssl-related code in debian mysql-foo is disabled[1]. not that i wouldn't mind having it back... sean [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=291945 -- signature.asc Description: Digital signature
Re: shell script sniplets in /usr/bin?
On Sat, Jan 29, 2005 at 04:18:30PM +, Jochen Voss wrote: > In bug #292759 the maintainer of gettext-base claims, that it is also > ok to install shell script sniplets, which are not executable on > itself into /usr/bin/ > > This is not a bug. > > The file gettext.sh is meant to be sourced by shell scripts in this way: > > . gettext.sh i'd argue the file is improperly placed. if the file is sourced and not directly executed, and there's no reason why an average user or admin of the system would need to execute it as "gettext.sh", it should stay out of /usr/bin, and go in /usr/share/gettext-base/scripts or something more appropriate like that. looking at the script snippet in question, all it does is set a couple functions/variables, so it certainly should not be in /usr/bin. hell, it's not even executable. sean -- signature.asc Description: Digital signature
Re: shell script sniplets in /usr/bin?
On Sat, Jan 29, 2005 at 05:40:05PM +0100, Santiago Vila wrote:
> So I'll repeat: Please read the logs for non-bug Bug#292759, where the
> author explains the rationale for putting gettext.sh in /usr/bin.
you want ". gettext.sh" to work, which means you want it somewhere
in the default system path. you don't want to hard-code the
paths, which makes sense. however, it is shell scripts that are
to do this, not users, so why not do something like this in
any script that uses gettext:
#!/bin/sh
PATH=${PATH}:/usr/share/gettext/scripts
. gettext.sh
that way, you don't pollute /usr/bin with non-executables (which i would
argue does break policy/fhs in the sense that at least it's non
executable), you don't have to hard code the path, and the user can
override it by placing another gettext.sh in their path.
alternately, you could hard code it, but test for a user-environment
variable that could override the default location (though i think
the previous suggestion is less hackish).
sean
--
signature.asc
Description: Digital signature
question about packaging kernel module packages
hey list, i'm looking at sponsoring a particular foo-source style kernel module package, and haven't been able to find good documentation on packaging tips/practices for this kind of package. the package i'm looking at is already lintian/linda clean, and, well, it works, but there are a few unanswered questions, such as getting it working with module-assistant (which i imagine is actually in the docs for m-a), and more importantly getting it to automatically build against all the stock debian kernels. so, does anyone know of a document that covers this topic? thanks, sean -- signature.asc Description: Digital signature
Re: How to detect which user is connected to $DISPLAY
On Fri, Mar 25, 2005 at 10:08:48PM +0100, Michelle Konzack wrote:
> My Problem is, HOW to find the $USER who is connected to a $DISPLAY.
i have a small shell function that does this in a project i'm working on.
this isn't the least hackish way of doing it, but here goes:
get_desktop_owner ()
{
owner_display=$1;
w | awk '{print $1" "$2}' | grep "$owner_display$" | awk '{print $1}'
}
example:
copelandia[~]07:29:50$ get_desktop_owner :0
seanius
i invite someone to invent a better way, i'd like to hear it :)
sean
--
signature.asc
Description: Digital signature
Re: How to detect which user is connected to $DISPLAY
On Sun, Mar 27, 2005 at 10:14:03PM +0200, Vincent Zweije wrote: > As I understand it, the program that puts these entries into the whois > database is called sessreg. Have a look at it; it should be part of > the X startup/shutdown script, at least for xdm. or, if you want to take it a level of abstraction deeper, these programs are all using the utmpx library calls to register the "logins". w, who, last, and finger all use utmpx system calls to tell you about who's currently (or previously) logged in. a while back i wrote a neat little program to query the utmpx databases, called "wuzzah". while the program itself may or may not be helpful for this specific need, the source code would be helpful if you go this direction (and are using a c program). sean -- signature.asc Description: Digital signature
crediting debconf translators, revisited
hi all, some time back, i remember somebody asking what the proper way was to credit translators who provided debconf template translations. the consensus seemed to be that mentioning them in the changelog was sufficient. not being satisfied with that, however, i wrote up a small script to directly credit their work, which i redirect into a file under /usr/share/doc/$package/ during package build. if anyone's interested, it's at: http://people.debian.org/~seanius/goodies/credit-xlators/credit-xlators sean -- signature.asc Description: Digital signature
Re: Why do we still have this on the distribution?
On Tue, Apr 05, 2005 at 03:56:25PM -0700, Don Armstrong wrote: > The fact that Adam Conrad just made an upload yesterday to fix bugs in > the package seems to indicate that he at least feels that it is > useful. [Or at least, I *hope* that's why an upload was made instead > of requesting removal.] obviously adam's going to be the best judge of what's going on wrt php3, but afaict there's no need of php3 that can't be satisfied by php4 (which is completely backwards compatible with v3 in every case i know of), so i don't see why we can't just remove it and have v4 fill in the void. my worries for this are twofold: - sarge is around the corner, and keeping it in means maintaining it for possibly another 2-4 years! if it's *already* no longer maintained upstream... - php5 is also around the corner, and having versions 3, 4, and 5 all in the archive at the same time will lead to not only archive/mirror bloat (which is considerable by itself), but also probably a very complicated set of interdepenencies and very frustrating bugs resulting from said dependencies. sean -- signature.asc Description: Digital signature
Re: Bug#303366: ITP: vimcdoc -- Chinese Translation of Vim Online Help Documents
On Thu, Apr 07, 2005 at 01:39:17AM +1200, Carlos Z.F. Liu wrote: > The upstream author occasionally told me that he want to switch to > GFDL, another non-free license. :) Is there any DFSG free document > license? ... OK, I knew GPL and BSDL is, but not everyone think > docuemntation is equal to software... i'm a fan of the academic free license v2, which i think does what the gfdl meant to do. it allows modifications and redistribution, as long as the modifications from the original are clearly stated. sean -- signature.asc Description: Digital signature
p.d.o status?
hi, would anyone care to comment on the status and expected downtime remaining for gluck? i know it was taken down for emergency hardware maintainance, and appreciate that it might take a while. howeer, if it is going to be a considerable while longer, someone might want to point debian.org to a mirror (web requests for debian.org w/o the www time out). sean -- signature.asc Description: Digital signature
Re: gluck available again / filesystem shaked
On Thu, Apr 07, 2005 at 09:32:29PM -0700, Steve Langasek wrote: > The files under /home/__Corrupt-R-US belonging to me all appear to be junk, > fwiw -- or at best, files from old d-i dailies that it's not worth trying > to put back in place. :) But maybe somebody else recognizes some of them as > something worth keeping, so I suppose they might as well stay there 'til > May... heh, of all the files of mine that could disappear, the index.html for my p.d.o page vanished. i saw something in __Corrupt-R-US, but it neither belonged to me nor had the right content. thank goodness for google caching :) actually, this brings up something i've been wondering for a bit now: is there any form of backups in place for any of the debian.org machines? sean -- signature.asc Description: Digital signature
Re: Bug#304266: ITP: sdate -- never ending september date
On Tue, Apr 12, 2005 at 12:59:08PM +0200, Christoph Berg wrote: > > Is there any real-life use for this program? > > No. then please don't put it in debian. you can debianize it and host it on your web page (or send it to esr) which will still serve its novelty purpose without adding yet another useless package to rot in the archives sean -- signature.asc Description: Digital signature
Re: All GPL'ed programs have to go to non-free
On Thu, Apr 14, 2005 at 11:47:26PM +0200, Adrian Bunk wrote: > Therefore, all GPL'd programs will have to go to non-free. there's nothing that prevents us from re-distributing modified copies of the GPL, we just can't do so and claim that they are the GPL. even if you did want to nitpick that (why?), such a restriction is acceptable according to the DFSG. for example, many authors choose to license their software under a 'modified GPL' or 'GPL-with-some-exceptions'. sean -- signature.asc Description: Digital signature
Re: PHP/WebApp policy/mailing list
On Sat, Apr 30, 2005 at 05:32:35PM +0100, Neil McGovern wrote: > There's been a bit of discussion[0] recently on the debian-security list > with regards to how include()ed files should be handled. and this for the most part is a good practice. if the file does not need to be directly accessed by web clients, it should not be underneath the web accessible directories. that said, there are a lot of projects in which that distinction is blurred, and in some cases it may not be at all feasible. i think a general guideline should be that any "include" files are either impotent if fetched remotely (naming most php inlcude files to end in php can often achieve this), or better, restricted from being accessed at all via web server access controls (htaccess for apache) or placed outside of a fetchable root[1]. this is in order of least to most preference. > I think that, due to the large number of packages that are webapps, a > policy shoudl be created on how we handle these. some time ago i wrote a rough outline of a policy[2], though there remains much to be added to this. at the time i decided it was a bit too much work and too broad of a subject to be tackled at once, so i then decided to focus on the database-specific portion of it[3], thinking that the practices, trends, tools, and development methods could be extrapolated. > To do this, it would be a good idea IMO to have a maining list. This has > already been suggested[1][2], and I agree that a debian-webapp list > should be created. i also think such an idea would be very useful, and i would certainly join up in said list. sean -- [1] prepending to php_include_path in a debian-centric config file is an easy way to achieve this for php pages. [2] http://people.debian.org/~seanius/policy/webapp-policy.html [3] http://people.debian.org/~seanius/policy/dbapp-policy.html signature.asc Description: Digital signature
Re: Outrageous Maintainer
On Sat, Apr 30, 2005 at 08:30:38PM +0200, Klaus Ethgen wrote: > The according bug is #306608. having read through the bug report, it seems to me the appropriate thing to have done all along was add a Conflicts statement, which really does no harm and does resolve the issue. HOWEVER, that said, the maintainer seems set in his ways, and maybe there's something i don't know. if you really feel the maintainer should be forced to fix the problem as was proposed, there does exist a means of arbitrating this argument[1][2]. sean -- [1] http://www.nl.debian.org/doc/manuals/developers-reference/ch-pkgs.en.html#s-bug-housekeeping [2] i don't know if this applies to non-dd's, but you could find a sponsor for it if it did. signature.asc Description: Digital signature
Re: Outrageous Maintainer
On Sat, Apr 30, 2005 at 04:36:29PM -0300, Henrique de Moraes Holschuh wrote: > Wrong. The other package has a broken replaces header, without the required > conflicts header it needs to have. yeah, looks like i was. that said, the rest of my response (this should be forwarded to the tech committee if he really cares) still holds. sean -- signature.asc Description: Digital signature
Re: PHP/WebApp policy/mailing list
On Sun, May 01, 2005 at 01:33:08PM +0200, Jeroen van Wolffelaar wrote: > Eh, because you believe a new lists.d.o list could take a bit of delay, > an alioth list is better? > > Sorry, but I don't agree with the reasoning -- lists.debian.org is for > general discussion lists, while alioth is more for packaging-specific > projects or for new projects that haven't gone anywhere yet. well, given that there will most likely result a package or two from the discussion, as well as a policy (hopefully :), and both of which will need some kind of working repository to which we all have access, it would make sense to start up an alioth project anyway. and while we're waiting for the debian-webapp (or whatever name we decide on) mailing list at l.d.o, we could also have somewhere to talk. later, we could move en masse to l.d.o list when we have it and leave the project just for the packaging/policy repository. so, that said, i'm going to go ahead and apply for an alioth project for the packaging related stuff, as i was planning on doing so anyway. if folks wouldn't mind a list hosted there, i can set it up. sean -- signature.asc Description: Digital signature
Re: PHP/WebApp policy/mailing list
On Sun, May 01, 2005 at 04:34:17PM +0200, Alexis Sukrieh wrote: > I agree. That cannot hurt to have a working area. > I also vote for a SVN account. i didn't think you could do svn on alioth. can you? > >so, that said, i'm going to go ahead and apply for an alioth project > >for the packaging related stuff, as i was planning on doing so > >anyway. > >if folks wouldn't mind a list hosted there, i can set it up. > > Ok, which name will you use for the alioth project? i chose "webapps-common", in the spirit of wwwconfig-common and dbconfig-common. the former will probably be absorbed into this project (with the blessing of the maintainer, of course). sean signature.asc Description: Digital signature
Re: Sarge release for amd64 - Please help to fix the remaining bugs
On Tue, May 03, 2005 at 10:22:04AM +0200, Adrian Bunk wrote: > BTW: The interaction between the two MySQL server packages in > unstable/sarge at purge time is *ahem* interesting. > They are really time bombs ready to explode in a few days or > years. > It seems RC bugs are required for both of them... if there's a problem, please file a bug about it instead of making vague remarks like this. sean -- signature.asc Description: Digital signature
Re: apt in experimental (Re: APT 0.6 migration -- second status report)
hi, On Wed, May 04, 2005 at 12:05:26PM -0700, Matt Zimmerman wrote: > One way around this would be for all of the maintainers of packages > depending on apt to agree to a significant version number increment when > moving to apt 0.6; then such versions could remain in experimental without > being removed. or, since we're now officially in the sarge freeze(!) we could just put it into sid and not worry about the dependency issue, right? i've been using apt .6 on one of my machines, and while i haven't kept a super-close eye on it, i haven't noticed anything that would make me think it an unsuitable candidate for unstable. sean -- signature.asc Description: Digital signature
Re: apt in experimental (Re: APT 0.6 migration -- second status report)
On Wed, May 04, 2005 at 03:08:42PM -0700, Matt Zimmerman wrote: > > Which can't be done (savely) if the key is compromised or expires > > before the update (like it does every year). > > If the key is compromised, we lose, no matter what we do. > > I recommend that we create keys which will not expire before the next > release. istr discussing (or at least thinking to myself) a method of "rolling" keys, where one key was used to sign another key, which would then ideally be kept somewhere Safe for the case of unexpected expiration. this second key could then be used to sign a third key, and so-forth. i guess this wouldn't handle upgrades of apt that skipped a "key epoch", but that could probably be worked around by keeping the old keys around somewhere so that they could be used to somehow establish a chain of trust to the newest key. in the case of a compromise you'd still need an extra verification; because you'd have to assume that the compromised key could have been used by the mean people to sign phony keys. that could pretty easily be accomplished by attaching another d-d's signature to it when it was generated, right? if the key was really kept somewhere Safe, there would be no risk of the first key's compromise affecting it. sean -- signature.asc Description: Digital signature
Re: apt in experimental (Re: APT 0.6 migration -- second status report)
On Wed, May 04, 2005 at 03:33:37PM -0700, Matt Zimmerman wrote: > If you have some code which implements this, I will take a look, but this > sort of thing is very awkward to do with gpg, and I don't think that there > is much justification for this level of complexity. The existing scheme is > simple, and works. /me pretends to search through his pockets nope, no code :) i guess it all depends on how important it is to have seamless key transitions. maybe just informing the admin that the key has changed and pointing them to instructions for how they can verify its authenticity is a better approach in that case. sean -- signature.asc Description: Digital signature
Re: Location of Web Application Data, Policy 11.5.3
hi, On Mon, May 09, 2005 at 12:16:48PM +0200, Marc Haber wrote: > quoting from Policy 11.5.3: > > Web Applications should try to avoid storing files in the Web Document > Root. Instead they should use the /usr/share/doc/package directory for > documents and register the Web Application via the menu package the current web application policy is outdated and not very thorough. we've recently started a new list (mentioned in another reply) the goal of which in no small part includes developing a new web policy. i'd recommend signing up if you're interested. currently, the best place to put web documents would be a subdirectory øf /usr/share/package (not *just* /usr/share/package, because you may need to store non-web documents as part of your package too). sean -- signature.asc Description: Digital signature
way to tell when a package makes it to testing?
hey all, (this is a general, non-release related question) i was talking with another member of my local LUG, and he asked if there was a way to tell when a package was uploaded into the testing distribution. currently, the package qa pages say when a package is uploaded into unstable, and they say how long packages will probably have to wait before they make it into testing, but there's no after-the-fact mention of when a package was uploaded into testing. is there some upload log somewhere that this can be found? since i think this would be a nice feature to add into the qa infrastructure, what should i report a wishlist bug against to ask for this info on the qa page? sean -- signature.asc Description: Digital signature
RFC on mysql 4.1 in sarge
(please excuse the cross-posting, i felt it was necessary to get all affected parties' input) hi, for some time now, christian and i have been trying to build in a workaround for a rather tricky bug in the mysql-server and mysql-server-4.1 packages, and we'd like to field some comments on what other people (namely the security and release team, though others are welcome to chime in) think. so, the executive summary: - people often symlink the mysql datadir (/var/lib/mysql) and logdir (/var/log/mysql) to somewhere else, such as /usr/local - because these two directories are in the files.list of woody's mysql server, upgrading to packages in sarge leads to the symlinks being removed and replaced with empty directories. - this leads to a lot of confusion and service outages for people upgrading. worse, there are scripts that need to be run on the database during the upgrade process that could leave things in an even worse state by having a mysql 4.1 server trying to use a 3.23 database. so after a lot of teeth-gnashing and brainstorming we've come up with a way to prevent this from happening for upgrades of the "mysql-server" package (in the latest upload of mysql-server). however, the same method isn't 100% guaranteed to work for a direct mysql-server/woody -> mysql-server-4.1/sarge upgrade, depending largely on in what order the packages are processed by the package management software. the following upgrade paths work: mysql-server/woody -> mysql-server/sarge mysql-server/woody -> mysql-server/sarge -> mysql-server-4.1/sarge but this does not: mysql-server/woody -> mysql-server-4.1/sarge so at this point, we're not sure what to do to cover this last problem, as we have no guarantee the preinst of mysql-server-4.1 will even run before mysql-server/woody is removed. the only fix we can think of is to remove the two directories from the files.list of the woody package. so we've come up with three options, none of which are great: 1 the most recenty woody security update caused problems for some people, and there's a package already waiting to go in to fix this problem. we could put a fix into the woody mysql-server package into this package before the security team handles it. 2 if there's going to be a final woody point release, we could put a fixed version in there 3 give up on trying to fix it, assume that symlinks might get lost, and put something in a README file telling users what they have to do in order to fix up their database after restoring the symlinks. i don't see 1 happening, i don't know if the prerequisite (woody release update) for 2 is going to happen, and 3 doesn't make me all too happy as a "solution". so, questions, comments, suggestions all welcome, sean -- signature.asc Description: Digital signature
Re: RFC on mysql 4.1 in sarge
On Wed, May 18, 2005 at 11:00:29PM +0200, Adrian Bunk wrote: > 4 drop mysql-dfsg-4.1 from unstable/sarge not exactly an attractive option, but i guess everything is on the table at this point so it's worth bringing up... the reverse dependencies aren't nearly as severe as i had assumed, actually, but it's still a rather drastic step to take. > Other issues like #308762 are also still possible on direct > mysql-server/woody -> mysql-server-4.1/sarge upgrade paths - and > there will be users doing such upgrade paths. i'm going to call you out on this again. if there are problems, please stop making vague asides report the bugs. sean -- signature.asc Description: Digital signature
Re: RFC on mysql 4.1 in sarge
hey, On Thu, May 19, 2005 at 08:35:03AM -0700, Steve Langasek wrote: > > > 3 does not sound so bad to me; it's arguably user error anyway to replace > > > a > > > package-provided directory with a symlink in this manner > > > If you consider this an user error, then what is the officially blessed > > way of relocating a package-prodived directory to a different (already > > mounted) file system? > > currently, that would be bind mounts. policy could definitely be more clear on this. specifically, 6.5.4 is somewhat misleading in that case: A directory will never be replaced by a symbolic link to a directory or vice versa; instead, the existing state (symlink or not) will be left alone and dpkg will follow the symlink if there is one. and i had never really heard that symlinking was to be frowned upon. i do like your suggestion of bind mounts though, and will probably do that myself in the future. sean -- signature.asc Description: Digital signature
Re: RFC on mysql 4.1 in sarge
hey, On Thu, May 19, 2005 at 02:49:13AM -0700, Steve Langasek wrote: > I see the same three options. Joey has said he is working on a final woody > point release for the last weekend in May; you'll probably need to > coordinate with him and get something uploaded soon if you want to try for > this option. okay, i'm going to make an upload to stable-proposed-updates at some point this weekend, after i've verified that i can make such a fix. i'll then leave it joey to decide whether or not it warrants being included. > 3 does not sound so bad to me; it's arguably user error anyway to replace a > package-provided directory with a symlink in this manner, so having a corner > case of "partially upgraded woody system and installing mysql-server-4.1 and > messed with a package directory" is not the end of the world... that's my thoughts. anyone who jumps from mysql-server in woody to mysql-server-4.1 in a completely new release of debian without dist-upgrading their system first should *expect* for there to be a problem, and at the very least we've gone out of our way to identify it and tell them what they have to do to fix it :) sean -- signature.asc Description: Digital signature
Re: bts ldap interface: future developments ...
hi andreas, On Tue, May 24, 2005 at 05:14:50PM +0200, Andreas Barth wrote: > For that reason, I consider to drop the old entries from the main file, > and stick them to a text file so that searches in the archived bugs take > even longer than today, but all others would be really fast. The problem > with that is of course that bugs change their DN on archiving. i'm not convinced that changing the DN's for archived bugs is necessarily a bad thing (i know it usually is frowned upon) though if that were to happen, couldn't it be offloaded into a different base DN but still kept within the gateway? for example, say you have ou=bugs,dc=debian,dc=org adding a ou=archived,ou=bugs,dc=debian,dc=org and then changing the dn of bugs to point there would keep them out of the main bugs bucket, which would get the speed boost for people properly doing scope=one searches, and people who wanted to search everything could do a scope=sub on the base dn. > Opinions, further suggestions? - what are you currently doing wrt indexing? - what underlying db format are you using? sean -- signature.asc Description: Digital signature
Re: ITP: sid - Run commands in your /sid chroot
On Fri, May 27, 2005 at 01:46:25PM +0100, Brett Parker wrote: > > I imagine that's a pretty simple change I should just do myself. > > Erm, dchroot already does this. likewise, i'm not sure what this sid package would do that dchroot does not. > (I've got an amd64 with bind mounted home, an i386 chroot, an i386 > testing chroot and an ubuntu hoary chroot, I've also got pbuilder setup > to build for i386, which is much nicer than building in a (potentially) > unclean chroot). i've been very happy with dchroot, i have a whole farm of chroots under /srv that i use frequently for building on combinations of architectures and releases. i even have a chroot to play my favorite 32-bit windows games via cedega. sean -- signature.asc Description: Digital signature
Re: Shell variable
hi, On Sat, May 28, 2005 at 01:19:05AM +0100, Adrian Mastronardi wrote: > I need to setup an shell variable: > ENFDATA=/usr/share/rnamotif/enfdata/ according to debian policy, programs must not have to rely on the existence of environment variables. what you should probably do is hard-code into the applications that need this variable a default location of /usr/share/rnamotif/enfdata/, and then allow the user to override this value via the same environment variable. sean -- signature.asc Description: Digital signature
Re: Release update: minor delay; no non-RC fixes; upgrade reports
hi, On Mon, May 30, 2005 at 04:07:50PM +0100, Roger Leigh wrote: > The BTS does not currently support this. For example, if I upload a > fix to unstable, I have to manually reopen it and tag it sarge. or, you could always not close it in your changelog, and update the bug accordingly. sean -- signature.asc Description: Digital signature
