Re: Debian 10 "buster" moved to archive.debian.org
Hello Ansgar, Am Sat, Mar 23, 2024 at 09:30:49AM +0100 schrieb Ansgar 🙀: > Debian 10 "buster" has moved to archive.debian.org in order to free > space on the main mirror network. We plan to start removing files for > non-LTS architectures in about two weeks; the existing Release files > will then refer to no longer existing files on the main mirror network. > > An exception is the security archive (which already has no non-LTS > architectures): we will only archive it after LTS support ended. > > For LTS users this does not require any changes. I'd like to understand the process a little better: 1. First *non*-LTS architectures (mips,ppc,s390,…) have been moved 2024-03 2. LTS for Buster ended recently 2024-06-30 ¹ 3. Debian 13 Trixie release is expected in 2025 4. ELTS for Buster is probably until 2029-06 ² When will *LTS* architectures (x86,arm,…) also be removed? My guess would be between 2. and either when more free space is needed anytime in the future, or latest 3. Thank you for your excellent work and hopefully an answer. Philipp 1: https://wiki.debian.org/LTS 2: https://wiki.debian.org/LTS/Extended
Re: systemd's journal
Hello, On Sun, Feb 16, 2014 at 09:17:46AM +0100, Helmut Grohne wrote: > Heh. Maybe we can turn this into a useful question: ... > There is no journalctl on that system. So what do I do now? The same you do when your log file has those .Z, .gz, .bz2, .lzma, .xz, .pgp, "your compresion program of the decade" extensions: You install the missing software and life goes on. "But those are installed by default!" you might say, for which I'll just answer: "wait for Jessie: then systemd will be installed by default, too." ;-) BYtE Philipp -- Philipp Matthias Hahn GPG/PGP: 9A540E39 @ keyrings.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140216150008.ga23...@pmhahn.de
Re: [PATCH] netplug - Allow to specify custom script file via param '-s'
Hello Raphael, On Fri, Mar 22, 2013 at 07:55:56AM +0100, Raphael Hertzog wrote: > There is: you can use experimental to continue working on the package > until the wheezy release. Or you can accumulate stuff in the VCS. I know. > > So your patch will just stay in the BTS until I find some time to work > > the netplug again, which is very low on my current priority list. > > It's not a very rewarding answer to someone who invested time in your > package... > > When I am in a similar situation, I tend to offer the person to join as > co-maintainer. The patch is not very long and it should not be too hard > to review. Or you can redirect him towards upstream if that's better. Upstream is dead: <http://hg.serpentine.com/netplug> 2010-06-26 So basically I would need to maintain that patch ad infinitum. And currently I don't have the time to become a new upstream, so my rather harsh reply. Sincerely Philipp -- Philipp Matthias Hahn GPG/PGP: 9A540E39 @ keyrings.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130323075820.ga29...@pmhahn.de
Re: [PATCH] netplug - Allow to specify custom script file via param '-s'
Hello, On Thu, Mar 21, 2013 at 06:06:57PM +0100, Pali Rohár wrote: > On Thursday 07 March 2013 12:33:10 Pali Rohár wrote: ... > > Done, now patch is visible here: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702495 > > Patch is there for two weeks but without response? Any problem? Debian is currently in the freeze period to get the next Debian release released. As your enhancement patch is not release critical for Debian, there is no chance to get a patched package included. So your patch will just stay in the BTS until I find some time to work the netplug again, which is very low on my current priority list. Sincerely Philipp -- Philipp Matthias Hahn GPG/PGP: 9A540E39 @ keyrings.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130321215046.ga11...@pmhahn.de
Re: RFC: usb-modeswitch 1.2.0 release embedding jimtcl
Hello, On Wed, Oct 19, 2011 at 01:48:17PM +0100, Ben Hutchings wrote: > Virtual machine networking works just fine for me with virt-manager and > network-manager. As far as I know not (fully) for the bridged setup [0]: NM recognized the bridge, but since it doesn't have a "link status" [1], VPNs are disabled. Background: I have one desktop PC which is my main work station at home, which alse can run several VMs. Since I also own other mobile devices, I like to connect from them to the VMs. ut I also use OpenVPN to open tunnels to other sides on demand. [0] A dedicated bridge for all VMs works fine, as then the ethernet interface is fully handled by NM itself. [1] Only the physical ethernet card has a link status, which is part of the bridge, but NM doesn't handle this. BYtE Philipp -- Philipp Matthias Hahn GPG/PGP: 9A540E39 @ keyrings.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111020052733.ga4...@pmhahn.de
/lib32 -> emul/ia32-linux/lib ?
Hello, I'm running "Debian sid" on "x86_64" and tried to build a "google-earth" package today, which failed with dpkg-shlibdeps: error: no dependency information found for /emul/ia32-linux/lib/libm.so.6 (used by ../usr/lib/googleearth/liblayer.so). After some investigation into bi-arch and multi-arch I discovered that I have the following directory structure: /emul/ia32-linux/lib /emul/ia32-linux/usr/lib /lib /lib32 -> emul/ia32-linux/lib /lib64 -> lib /usr/lib /usr/lib32 /usr/lib64 -> lib Looking at "/var/lib/dpkg/info/libc6-i386.preinst" I found the following fishy line: if [ "$(readlink /lib32)" = "/emul/ia32-linux/lib" ]; then ^ notice that my symlink does not have the leading slash! rm /lib32 Since I don't remeber ever creating that symlink myself and also found no definite answer to my question on how a "right" directory layout should look like, I'd like to ask first before filing a possible bug on "libc6-i386" because of that to restrictive test. Sincerely Philipp Hahn -- Philipp Matthias Hahn GPG/PGP: 9A540E39 @ keyrings.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
RFC: Security permissions for /var/log/audit/* and */bin/* files
Hello! While working on a new version of the audit-package, I stumbled upon the problem that /sbin/auditd explicitely checks several files and directories for file-permissions, which are less than Debians standard 0755 and 0644. Here a list of those 6 files and the corresponding description from the manual page auditd.conf(5): log_file /var/log/audit/audit.log 0640 This keyword specifies the full path name to the log file where audit records will be stored. It must be a regular file. dispatcher /sbin/audispd 0750 The dispatcher is a program that is started by the audit daemon when it starts up. It will pass a copy of all audit events to that application's stdin. Make sure you trust the application that you add to this line since it runs with root privileges. space_left_action /some/executable 0750 This parameter tells the system what action to take when the system has detected that it is starting to get low on disk space. Valid values are ignore, syslog, email, exec, suspend, single, and halt. If set to ignore, the audit daemon does nothing. syslog means that it will issue a warning to syslog. Email means that it will send a warning to the email account specified in action_mail_acct as well as sending the message to syslog. exec /path-to-script will execute the script. You can- not pass parameters to the script. suspend will cause the audit daemon to stop writing records to the disk. The daemon will still be alive. The single option will cause the audit daemon to put the computer system in single user mode. halt option will cause the audit daemon to shutdown the computer system. admin_space_left_action /some/executable 0750 This parameter tells the system what action to take when the system has detected that it is low on disk space. Valid values are ignore, syslog, email, exec, suspend, single, and halt. If set to ignore, the audit daemon does nothing. Syslog means that it will issue a warning to syslog. Email means that it will send a warning to the email account specified in action_mail_acct as well as sending the message to syslog. exec /path-to-script will execute the script. You cannot pass parame- ters to the script. Suspend will cause the audit daemon to stop writing records to the disk. The daemon will still be alive. The single option will cause the audit daemon to put the computer system in single user mode. halt disk_full_action /some/executable 0750 This parameter tells the system what action to take when the system has detected that the partition to which log files are written has become full. Valid values are ignore, syslog, exec, suspend, single, and halt. If set to ignore, the audit daemon does nothing. Syslog means that it will issue a warning to sys- log. exec /path-to-script will execute the script. You cannot pass parameters to the script. Suspend will cause the audit daemon to stop writing records to the disk. The daemon will still be alive. The single option will cause the audit daemon to put the computer system in single user mode. halt option will cause the audit daemon to shutdown the computer system. disk_error_action /some/executable 0750 This parameter tells the system what action to take whenever there is an error detected when writing audit events to disk or rotating logs. Valid values are ignore, syslog, exec, suspend, single, and halt. If set to ignore, the audit daemon does noth- ing. Syslog means that it will issue a warning to syslog. exec /path-to-script will execute the script. You cannot pass parame- ters to the script. Suspend will cause the audit daemon to stop writing records to the disk. The daemon will still be alive. The single option will cause the audit daemon to put the computer system in single user mode. halt option will cause the audit daemon to shutdown the computer system. I thinks the Log-file is very critial and important, so reducing the permissions to 640 is probabpy okay. The parent-directory will be 0750. All other permissions for the executables are IMHO to restrictive. I'd like to remove the check either completely or at lease change it to non-world-writable. Any opinions on that? BYtE Philipp -- Philipp Matthias Hahn <[EMAIL PROTECTED]> GPG/PGP: 9A540E39 @ keyrings.debian.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFH: automake, library and sub-automake using rpath
Hi! I have a problem with the audit-package [1]: 1. it uses autoconf/automake 2. it builds a shared library 3. it aggregates a copy of a python sub-package named "system-config-audit", which uses a _seperate_ autoconf/automake. The parent-autoconf calls it using AC_CONFIG_SUBDIRS([system-config-audit]) 4. the sub-package uses the shared library. Since the library is only installed in a temporary location, and the sub-automake doesn't know anything about the _temporary_ installation, the sub-package links to that library using a rpath. Lintian sais: W: system-config-audit: binary-or-shlib-defines-rpath ./lib/system-config-audit-server /media/storage/debian/pool/main/a/audit/audit-1.7.5/lib/.libs Does some autoconf/automake/python-guru know how I can fix this dilemma? I would like to use the included system-config-audit, since it's better tested, but if that doesn't work, I could also ignore the included version and create a completely separate package from the original author [2]. BYtE Philipp [1] http://people.redhat.com/sgrubb/audit/ [2] https://fedorahosted.org/system-config-audit/ -- Philipp Matthias Hahn <[EMAIL PROTECTED]> GPG/PGP: 9A540E39 @ keyrings.debian.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: For Those Who Care About X (Bits from the X Strike Force)
Hello! On Sun, Aug 17, 2008 at 11:21:45PM +0200, Julien Cristau wrote: ... > Next steps > -- ... > At around the same time, we'd like to enable hotplugging of input > devices, and their configuration through hal. This means using the > "evdev" driver for mice and keyboards instead of the traditional "mouse" > and "keyboard" drivers, which will for example use of different keymaps > for different keyboards, per-device configuration (not only statically, > but also at runtime), etc. > /usr/share/doc/hal/examples/10-x11-input.fdi and > /usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi in the hal package > contain an example config, which you can modify to suit your needs and > install in /etc/hal/fdi/policy/ to get a feel for this. No bug filed yet, just FYI: "evdev" currently has a problem with suspend/undock: I have an external mouse and keyboard connected to the docking station of a Lenovo R61, the keyboard configured for evddev. On suspend/undock, the X-server doesn't release the device node /dev/input/event?. The Linux kernel forcefully unpluggs all devices on suspend/undock and re-pluggs them on resume/dock. Since the old device-node is still open (and thus used), a new device-node with a new number is created. The external keyboard is thus dead, until I restart the server. "lsof -p `pidof X`" shows the node as still be opened, but deleted. The mouse uses /dev/input/mice and thus doesn't have the problem. Switching to console before suspending/undocking doesn't help either. This basically happens because xserver-xorg-input-evdev-2.0.3/src/evdev.c:EvdevProc(DeviceIntPtr device, int what) doesn't release the node on DEVICE_OFF and re-opens it on DEVICE_ON, but opens it in EvdevPreInit() and closes it in DEVICE_CLOSE. But according to http://www.x.org/wiki/XOrgInputDriverSpec that should actually what should be done. Googling for this shows that others have this problem, too. I currently don't have time to fix it myself, but others should know and perhaps have time and more experience with writing XOrg input drivers to fix this properly. BYtE Philipp -- Philipp Matthias Hahn <[EMAIL PROTECTED]> GPG/PGP: 9A540E39 @ keyrings.debian.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: quiltrc
Hello!
On Sun, May 04, 2008 at 03:13:31AM +0200, Marco d'Itri wrote:
> ~/.quiltrc:
>
> for where in ./ ../ ../../ ../../../ ../../../../ ../../../../../; do
> if [ -e ${where}debian/rules -a -d ${where}debian/patches ]; then
> export QUILT_PATCHES=debian/patches
"${PWD}/${where}debian/patches" ?
> fi
> done
I think I want the above.
BYtE
Philipp
--
Philipp Matthias Hahn <[EMAIL PROTECTED]>
GPG/PGP: 9A540E39 @ keyrings.debian.org
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: tool to turn redundant files into symlinks
On Sun, May 20, 2007 at 07:42:56PM -0600, Wesley J. Landaker wrote: > For a package problem I'm trying to solve (#414422), it would be nice to > have a tool that could find duplicate files (ala fslint[1] or fdupes[2]) > and turn them into symlinks. If hardlinks are okay too, see the "perforate" package (I find this package hard to find, since the name is somewhat misleading). It's written in Perl. $ dlocate /usr/bin/finddup perforate: /usr/bin/finddup $ whatis finddup finddup (1) - Find identical files and do something with them $ finddup --help Usage: finddup [options...] --man the manpage -h, --help a short help --version the version (CVS) of the program -n, --noaction do just nothing, just print out (implies -v) -v, --verbose just what the name says -q, --quietbe quiet -l, --link link the identical files together -o, --oldresultUse the old output of this script -i, --ignore-perms Don't check that file owner and permissions match -d, --dir Define the dir to check (you may specify more than one) BYtE Philipp -- Philipp Matthias Hahn <[EMAIL PROTECTED]> GPG/PGP: 9A540E39 @ keyrings.debian.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#423911: ITP: citadel -- Citadel.org is an highly integrated Groupware Platform with a Web 2.0 enabled Webinterface, but also providing SMTP, IMAP, POP3 and GroupDAV access to its content.
Hello! On Tue, May 15, 2007 at 12:09:30AM +0100, Stephen Gran wrote: > This one time, at band camp, Wilfried Goesgens said: > > > > * Package name: citadel ... > However, I have one question that has made me leery of it > so far: does it really need it's own implementation of all of those > protocols? AFAIK yes, since that is Citatels benefit: It gives access to the same data by different protocols; no nightmare because of inconsistent data between all those parts. > Can't it use existing, well tested, pop/imap/smtp servers? No. And that's why I didn't pick it for production, since I didn't want to replace my working Postfix + Cyrus-IMAP setup. BYtE Philipp -- Philipp Matthias Hahn <[EMAIL PROTECTED]> GPG/PGP: 9A540E39 @ keyrings.debian.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: auditd -- User space tools for 2.6 kernel SELinux auditing
Hello Thomas! On Sat, May 05, 2007 at 11:30:55AM +0200, Thomas Girard wrote: > I have been able to build a preliminary frysk package using these audit > packages. I agree with Manoj and Russell, we should probably follow > upstream location. Yes, I already changed it. > Could you please upload it when you think it's ready? I'm currently building and testing 1.5.3. Should be ready on monday. BYtE Philipp -- Philipp Matthias Hahn <[EMAIL PROTECTED]> GPG/PGP: 9A540E39 @ keyrings.debian.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
auditd -- User space tools for 2.6 kernel SELinux auditing
Hello! I've put some work into creating a first version of a Debian package of audit-1.5.1 for private use, which you can get from http://pint.pmhahn.de/pmhahn/debian/etch/a/audit/ Perhaps you can take a look at it and provide some feedback to get it into shape for official upload to Debian. One major chanhe compared to the Red-Hat package is, that all binaries live under /usr/sbin and not under /sbin. If auditing is required to start as early as possible, than I might have to move it from /usr to /. Any comments on this issue? Sincerely Philipp -- Philipp Matthias Hahn <[EMAIL PROTECTED]> GPG/PGP: 9A540E39 @ keyrings.debian.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is inability to operate with root read-only (and separate /etc, /dev, etc) a bug or design decision?
Hi!
On Sat, Aug 12, 2006 at 09:34:52PM +0200, Goswin von Brederlow wrote:
> Peter Samuelson <[EMAIL PROTECTED]> writes:
>
> > [Goswin von Brederlow]
> >> Instead move the things in etc that need writing to other places:
> >>
> >> 1) link /etc/mtab to /proc/mounts and create a dummy /proc/mounts on /
> >>for when /proc isn't mounted (works with quota in current kernels).
> >
> > Does the wrong thing with (a) user and (b) loop mounts. [I just tested
> > 2.6.16-1-k7.] /etc/mtab needs to keep enough state for umount to know
> > (a) who mounted something, so the same user can unmount it, and (b)
> > that a loop device was set up automatically via 'mount -o loop', rather
> > than done separately, so that umount can 'losetup -d /dev/loopN'. This
> > is information which cannot, at present, be put in /proc/mounts.
>
> Yes. If you need that feature help patching the kernel (like the new
> quota support in /proc/mounts) or link it to somewhere else.
Which doesn't work because of linux-utils-2.12r/mount/fstab.c:55
int
mtab_is_writable() {
static int ret = -1;
/* Should we write to /etc/mtab upon an update?
Probably not if it is a symlink to /proc/mounts, since that
would create a file /proc/mounts in case the proc filesystem
is not mounted. */
if (mtab_is_a_symlink())
return 0;
...
The path to mtab is also hardcoded in
/usr/include/paths.h:54:#define _PATH_MOUNTED "/etc/mtab"
which is no fun to change "on-the-fly".
BYtE
Philipp
--
Philipp Matthias Hahn <[EMAIL PROTECTED]>
GPG/PGP: 9A540E39 @ keyrings.debian.org
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Philipp Matthias Hahn <[EMAIL PROTECTED]> MIA?
Hi! On Wed, Apr 19, 2006 at 02:57:14PM +0200, Christoph Berg wrote: > Philipp, are you around? xosd as a (fairly new) RC bug, do you think > you'll be able to address that in the near future? Yes, I'm still around, but I'm currently busy with other things. Regarding xosd: I'm not the main upstream developer too, which is why I haven't uploaded any new version recently, because I'd like to make some changes first. As of why I haven't uploaded any new packages: I consider most bugs as minor and I didn't want to waste my time while other major transitions are in progress. I hope for next weekend. BYtE Philipp -- Philipp Matthias Hahn <[EMAIL PROTECTED]> GPG/PGP: 9A540E39 @ keyrings.debian.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: removing logfiles on purge
Hi1 On Thu, Mar 16, 2006 at 01:46:40AM -0500, sean finney wrote: > 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: What about providing some dpkg-purge / dh_purge which basically does the following: - on remove/purge register those files/directories related to the package which some admins like to keep, for example logfiles, database content, web sites and other files not included in the package itself, but which can't be regenerated when deleted. - optional mail the newly added entries to the admin - provide a small tool to list the still remaining files This might me something as simple as a directory in /var/lib/dpkg-purge with symlinks to files left behind by packages, for example /var/lib/dpkg-purge apache2 log -> /var/log/apache2/ inn2 news-spool -> /var/spool/news/ log -> /var/log/inn2/ postgresql db -> /var/lib/postgresql/ So you can later look around and remove the files you really don't want to keep any longer. You could extend that with automatic purge, for example provide regexps of files/directories you want/don't want to keep and which get deleted as soon as you register them. BYtE Philipp -- Philipp Matthias Hahn <[EMAIL PROTECTED]> GPG/PGP: 9A540E39 @ keyrings.debian.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: applet showing the current XkbLayout
Hello! On Thu, Oct 06, 2005 at 04:00:41PM +0300, gustavo halperin wrote: > I'm using enlightenment without KDE and without Gnome. My XFree86 is > configured with three keyboard layout: > Option "XkbLayout" "es,il,us" > Option "XkbOptions" "grp:shift_toggle" > My question is how I can cache when ever the keyboard Layout change and > which one is the current, this in order > to write an applet for enlightenment and X showing an ensign of the current > country Layout. Take a look at "xkbwatch", available for example from http://www.x.org/pub/unsupported/test/Xkb/programs/xkbwatch.c: $ gcc -L /usr/X11R6/lib -lX11 xkbwatch.c $ ./a.out Watching the keyboard state... --- group --- modifiers - id key event eff base latch lock eff base latch lock compat 1 50down0 0 0 0 0x01* 0x01* 0x00 0x000x01* 1 62down1*0 0 1* 0x01 0x01 0x00 0x000x81* 1 50 up1 0 0 1 0x00* 0x00* 0x00 0x000x80* 1 50down1 0 0 1 0x01* 0x01* 0x00 0x000x81* 1 62down2*0 0 2* 0x01 0x01 0x00 0x000x81 1 50 up2 0 0 2 0x00* 0x00* 0x00 0x000x80* 1 50down2 0 0 2 0x01* 0x01* 0x00 0x000x81* 1 62down0*0 0 0* 0x01 0x01 0x00 0x000x01* 1 50 up0 0 0 0 0x00* 0x00* 0x00 0x000x00* BYtE Philipp -- Philipp Matthias Hahn <[EMAIL PROTECTED]> GPG/PGP: 9A540E39 @ keyrings.debian.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: what is /.udev for ?
Hello! On Wed, Feb 09, 2005 at 10:30:12AM -0400, Maykel Moya wrote: > I recently realized that I had /.dev, after that, I rm -fr it what > rendered my system unbootabled. udev mounts a tmpfs over /dev to not disturb your (old) static /dev. To make your old /dev available, udev bind-mounts it to /.dev, if that mount-point exists. BYtE Philipp -- Philipp Matthias Hahn <[EMAIL PROTECTED]> GPG/PGP: 9A540E39 @ keyrings.debian.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFC: best practice creating database
Hello! What is consideres best practice when a package uses a SQL database (mysql, postgresql) and needs to create its own catalog and/or tables? [ ] Disable the package until someone has manually setup the database? [ ] Ask a lot of questions via debconf and try to setup in postconf? I ask because bacula-director-pgsql is currently broken and I'm trying to help the maintainer fix it. What irks me is * need to ask for hostname of remote or local DBMS. * if its remote, the DBA might have to change "pg_hba.conf" by hand. * need to ask for user/password of DBA, so new catalog can be created * password is cleared after use for security reason * will a paranoid DBA tell me his password? * need to ask for user/password for bacula-user If the automation fails (and it does for my setup), bacula-dir-pgsql is left unconfigured and I have to deeply dig in its postconf script to fix it my hand. What I ask myself at this point, is it worth to try to automatically setup these things at all or wouldn't it be better to just document the needed steps and let the user do them by hand? BYtE Philipp -- Philipp Matthias Hahn <[EMAIL PROTECTED]> GPG/PGP: 9A540E39 @ keyrings.debian.org
Re: Bug#190302: Misusage of changelog!
Hi! On Mon, May 26, 2003 at 08:12:51AM -0500, Luca - De Whiskey's - De Vitis wrote: > On Mon, May 26, 2003 at 02:45:16PM +0200, Josip Rodin wrote: > > Yes, but there's still no bloody point in making the submitter hunt around > > for information that the maintainer already knows and for which it takes > > them full 10 seconds per bug to list (15 if they type very slowly). > > Submitter receive a mail from bts which include the message that opened the > bug: what should he hunt for exactly? There are people other than submitter, maintainer and upstream ... Example: 1. detect bug 2. run reportbug 3. sees, other person was faster and reported bug 42. 4. wait for new version 5. read changlog 6. what the heck was bug 42, was it mine ? Or do you expect everbody to file duplicate bugs or subscribe to existing bugs ? BYtE Philipp -- Philipp Matthias Hahn <[EMAIL PROTECTED]> GPG/PGP: 9A540E39 @ keyrings.debian.org
