Re: removing conffiles
[EMAIL PROTECTED] (Martin Bialasinski) writes: > >> "MS" == Martin Schulze <[EMAIL PROTECTED]> writes: > > MS> Martin Bialasinski wrote: > > >> will dpkg remove a conffile on a upgrade, if I remove it from the > >> package? > > MS> I guess so. Why don't you try it on your system? Make a backup > MS> before. > > I tried, and it didn't. I don't know if this is intentional or because > I altered the conffile, so I asked. See what I do in fvwm95 with regard to changing conffiles. Basically, all this is done in the preinst, with a little check to see if the user has modified the conffile. If they have, then the conffile is not removed and a message is printed telling the sysadmin to do some cleanup work (but installation continues). If they haven't modified it, the file is then moved to a directory which is cleaned up in the postinst. (This is so an abort-upgrade can recover the old configuration). I stole this idea (and most of the code) from the fvwm2 maintainer, who does something similar to deal with this situation.
Re: rescue-disk kernel
[EMAIL PROTECTED] (Greg Norris) writes: > I was wondering if anyone can point me to some information on what > drivers are compiled-in (i.e. not modules) to the kernel on hamm's > rescue-disk image? I'm trying to generate an alternate rescue-disk > containing the latest version of the aic7xxx SCSI driver, and I'd prefer > to otherwise mimic the "normal" kernel as closely as possible. I was > able to find out what was compiled as modules by looking at the > drivers-disk, but haven't been able to determine the full list of > compiled-in options. > > The intent is to get this alternate disk-image added to the aic7xxx site > at ftp://ftp.redhat.com/pub/aic/, alongside the Red Hat and S.u.S.E. > bootdisk images. I believe that if you install the debian kernel-source package, it comes configured with the configuration used in the the kernel-image packages, which is the configuration used on the boot disks.
Re: automatic password generation
[EMAIL PROTECTED] writes: > Chrony (essentially an xntp3 clone) includes two binaries: a daemon that > runs as root and a control program that runs in user space. To perform > certain operations the user running the control program must provide a > password which is stored in a file readable only by root. I want the > chrony package to install in a configuration that will "just work" on most > systems. To do that I must put a password in that file. I don't want to > put in a default password as most users will not change it, but I don't > want to go to an interactive postinst either. A solution I came up with is > to generate and install a unique random password in the postinst. > > IS this ok with policy? Am I missing any obvious problems? I'm just curious - how are you going to do this? The best way I came up with was: PASS=`head --bytes=16 /dev/urandom | md5sum` I'm certain you could use od instead of md5sum, but I doubt it looks as simple as this. (Oh and I suppose people can argue about /dev/random vs. /dev/urandom, but for your purposes /dev/urandom should be fine - also note that /dev/random might cause the process to freeze temporarily if the entropy pool has been depleted).
Re: images in diff files ?!
Christian Hammers <[EMAIL PROTECTED]> writes: > But now: How do I put the additional Debian-Logo (only 2k) into the > diff file ??? Can I rely on the sharutils package though it is only > "standard" and not "essential" ? Well, since the sharutils won't be used for installing the package, but only for building it, then you may. At the moment there's no well-defined way to specify what packages are needed to build a given package (Source-Depends not withstanding). Another possibility is to rely on the libjpeg-progs package and store the image as a text-format ppm file. I'm glad the only images I have deal with are in xpm format (which workd just fine with dpkg-source)...
Re: "install" running recursively..?
Julian Gilbey <[EMAIL PROTECTED]> writes: > > Alexander Koch wrote: > > > I have a source which has "samples/admin/" as a dir. > > > Now I want to have a simple > > > install -m 644 samples/* $(tmp)/usr/doc/$(pkg)/examples > > > without touching the admin/ subdir at all. > > > > > Assuming that this is in a Makefile (as hinted by $(pkg), you want > this to read (remembering initial tabs): > > for file in `find samples -type f`; do \ > install -m 644 $$file $(tmp)/usr/doc/$(pkg)/examples; \ > done > > with a *double* dollar before file. Of course, if you don't actually want to recurse, but just want the files in the top level of the samples directory (I'm assuming you want to preserve the structure there): for file in `find samples/* -type f -print -type d -prune`; do \ install -m 644 $$file $(tmp)/usr/doc/$(pkg)/examples; \ done Or even: for dir in `find samples -type d -print`; do install -d -m 755 $(tmp)/usr/doc/$(pkg)/examples/`echo $$dir | sed 's/^samples\///'`; \ done for file in `find samples -type f -print`; do \ install -m 644 $$file $(tmp)/usr/doc/$(pkg)/examples/`echo $$file | sed 's/^samples\///'`; \ done Which preserves the directory structure. Of course if there are only a few directories, it's simpler to do install -d -m 755 $(tmp)/usr/doc/$(pkg)/examples/admin install -d -m 755 $(tmp)/usr/doc/$(pkg)/examples/otherdir And then: for file in `find samples/* -type f -print -type d -prune`; do \ install -m 644 $$file $(tmp)/usr/doc/$(pkg)/examples; \ done for file in `find samples/admin/* -type f -print -type d -prune`; do \ install -m 644 $$file $(tmp)/usr/doc/$(pkg)/examples/admin; \ done for file in `find samples/otherdir/* -type f -print -type d -prune`; do \ install -m 644 $$file $(tmp)/usr/doc/$(pkg)/examples/otherdir; \ done
The proper locations of .xbm icons
What, exactly, is the proper location for .xbm and .xpm icons?
I ask because I had just been putting the fvwm95 icons in
/usr/X11R6/include/X11/pixmaps - but I notice that other packages
place icons in a variety of places:
usr/X11R6/icons
usr/X11R6/include/X11/pixmap (Almost certainly a typo by someone)
usr/X11R6/include/X11/pixmaps (Where fvwm95 puts them)
usr/X11R6/include/pixmaps
usr/X11R6/lib/X11/${package}
usr/X11R6/lib/${package}
usr/lib/games/${package}
usr/lib/picon/*/*/*/*
usr/lib/${package}
usr/share/${package}
usr/share/icons
usr/share/icons/mini
And certainly other places I've left out.
Now, I don't like this somewhat random state of affairs, where any
package stores icons in any of the above places. So what's correct?
I'm torn between a standard place for all icons (like usr/share/icons)
and a directory that includes the package name (like
usr/share/$package/icons or usr/share/icons/${package}) - there are
advantages and disadvantages to both. (The disadvantage to the common
directory is that it'll be easy to generate conflicting icon names -
especially with names like xcopilot's 'icon.xpm'; I had a disadvantage
to the per-package directory scheme, but can't think of it at the
moment - it's too late for my brain to work well).
In any case, thoughts on this? Last time I read the FSSTD I don't
remember this being discussed, but I may be mis-remembering, and I
haven't yet read fully the FHS.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
the dists/stable-updates directory
So I screwed up in packaging, and going directly from bo my fvwm95 for hamm won't upgrade. Ooops; I made a mistake - this happens. (People upgrading from a previous hamm version did fine - I really thought I'd tested this, but apparently not thoroughly enough) Ok, so after the hamm release I get a bug report about the problems upgrading from bo, investigate them, and fix them. I submit a new fvwm95 for stable and it gets put into stable-updates. Fair enough. My question is now: is the stuff in stable-updates ever going to be integrated into the stable distribution? If so, what's the timescale on that? Also, are those in charge of the official CD images going to be putting the stuff in stable-updates into the directories on the CD? I'm expecting a series of reports like this when the CDs finally begin to ship... Failing that, is there a way to point apt at a directory that just contains a bunch of .deb files? I'd like to be able to tell people that they can get the latest stable stuff just by adding a particular line to /etc/apt/sources.list, but the sources.list manpage only describes the "deb" type, which can't cope with a completely flattened directory sturcture like that. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
What exactly is the order of steps to becoming a new maintainer?
After looking at the most recent WNPP list, I decided that there were packages (specifically, fvwm95 and tkdesk) that I would be willing to maintain, so I then read the documentation on www.debian.org on applying to become a maintainer. However, after reading that documentation and what the WNPP has to say about what to do in the event one wants to take over a package, I'm a bit confused about what I should do next. (I've already gotten the sources for fvwm95 and made it compile nicely; tkdesk sources seem harder to come by, as tkdesk appears to have vanished from hamm). Should I: a) post my intent to take over these packages to debian-devel b) inform [EMAIL PROTECTED] and the package maintainers of my desire to take over these packages. c) send in my application to become a debian maintainer, complete with signed scan of my passport d) make non-maintainer versions of these packages so that when I apply to be a maintainer I can point to these .debs to say "see, I know how to make packages" Any guidance appreciated. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
How should I deal with config. file moves?
I have just been approved as a Debian maintainer (as in, I've been told I'll get my master account and subscription to debian-private tomorrow) and I've gotten fvwm95. Now, whether you may know it or not, fvwm95 has had a truly ugly configuration up untill now, because of a bug in FvwmTaskBar. (Well, that's where I chopped at code and got it to work; whether the bug was there or in some other fvwm95 code may be debateable). Anyway, the old style of configuration had one configuration file (aside from menu stuff) - /etc/X11/fvwm95/system.fvwm95rc-menu. This was used by the menu file to generate /etc/X11/fvwm95/system.fvwm95rc - if a user wanted to customize their own look, they had to copy the system rcfile into their own .fvwm95rc and ... Anyway, trust me - it was ugly. Now, what happens is roughly what happens in fvwm2. There are a bunch of *.hook files in /etc/X11/fvwm95/ which get incorporated into the fvwm95 startup through "Read" statements. Each of these hook files is listed as a conffile; further, /etc/X11/fvwm95/system.fvwm95rc is also listed as a conffile. The file /etc/X11/fvwm95/system.fvwm95rc-menu is thankfully gone. Now my question is: how should I handle the transition for people who have modified their /etc/X11/fvwm95/system.fvwm95rc-menu? What I'm planning to do (I got this idea from fvwm2) is in the preinst check whether the system.fvwm95rc-menu has been modified from the version from the previous install, and if so print a warning message saying something like: You've modified you /etc/X11/fvwm95/system.fvwm95rc-menu, which is no longer used. You should edit the /etc/X11/fvwm95/system.fvwm95rc or the new '.hook' files to incorporate your edits. You should then delete /etc/X11/fvwm95/system.fvwm95rc-menu as subsequent fvwm95 installs won't work with it on your system. Also in the preinst I check to see if /etc/X11/fvwm95/system.fvwm95rc-menu is on the system but wasn't part of the previous fvwm95 install. If so I print a message saying "/etc/X11/fvwm95/system.fvwm95rc-menu is on your system but the version of fvwm95 being replaced didn't use it. You should delete and/or move this file before proceeding." - I then have the preinst exit with status 1, causing the install to be aborted. That is, the first install of the "new configuration style" fvwm95 will just print a long error message, but subsequent installs will fail unless /etc/X11/fvwm95/system.fvwm95rc-menu is deleted. This should hopefully force people to clean up obsolete configuration files. Here's my question: should I be forcing people to update their systems like this? Should I just print a warning message and continue in both cases? Should I, as the fvwm2 preinst script does, issue a "press RETURN to continue" prompt in the preinst, or should I obey policy and not prompt the user in the preinst? Should I check for other obsolete configuration file names? (since the names of all fvwm95 config. files changed from *.fvwm2rc95 in bo to *.fvwm95rc in hamm.) Also, what are the guidelines for whether a new package version should go into frozen (hamm) or into unstable (slink)? On the one hand, this package incorporates previously untested code, and should probably go into unstable. On the other hand, I could see that an easily configurable fvwm95 might be an important thing to have in Debian 2.0 - who decides questions like this? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How should I deal with config. file moves?
Anand Kumria <[EMAIL PROTECTED]> writes: > With your proposed scheme: warn on fvwm95-n and fail on fvwm95-(n+1); it > means if I never install fvwm95-n but instead skip straight to > fvwm95-(n+1) I miss out on the warning and am told that the installation > isn't possible until I delete the old system.fvwm95rc-menu No, you miss how I'm doing it - the preinst gives the long warning if and only if the -menu file was one of the config. files of the previously installed fvwm95; otherwise, yes, there would be the problem you refer to. Another way to put it is that the type of warnings you get depend not on what version you're upgrading TO, but what version you're upgrading FROM. This doesn't mean that it still might not be better to simply issue warnings and never do the 'exit 1' in the preinst. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ssh (again)
Zed Pobre <[EMAIL PROTECTED]> writes: > Okay, I've checked the archives, followed the instructions, and I > still can't get it working. What I did (as best I can remember): > > On my local machine, did ssh-keygen, stored the files in > .ssh/identity and .ssh/identity.pub. > > Telnetted to master. Created ~/.ssh. chmod 700 .ssh > cd .ssh > FTP back to my local machine, set binary mode, get identity.pub out > of the .ssh directory. > mv identity.pub authorized_keys > chmod 600 authorized_keys > > > ssh -v master from the local machine results in this: > > moebius: Trying RSA authentication with key '[EMAIL PROTECTED]' > moebius: Received RSA challenge from server. > Enter passphrase for RSA key '[EMAIL PROTECTED]': > > where as you can see it ends up asking me for my passphrase (which I > gather it isn't supposed to do). There's no difference if I use slogin > master instead of ssh master. Did I miss a step somewhere? Here's the deal - when you generated the public/private keypair with ssh-keygen you had the option of giving a passphrase required to unlock the secret key half of that keypair. If you were so certain of your own system's security that you didn't add a passphrase to that public/private keypair, then you wouldn't get asked here. (the prompt here is for the passphrase created with ssh-keygen, not for some password on master) In that case, however, someone who stole your secret key file could access your account on master - not a desireable thing. So, ok, you've decided that your secret key file has to be protected with a passphrase so that if you get hacked the hacker doesn't automatically have access to your account on master. But isn't it possible to just enter the passphrase once and be done with it? Yes, it is. The answer lies in the programs ssh-agent and ssh-add. The idea is that ssh-agent is run as a background process and stores the identies (i.e. the secret keys) of a user in an unencrypted fashion; secret keys are added by the user with ssh-add (which does prompt for a passphrase), and ssh (and scp, etc.) will then use these secret keys, never prompting the user for a passphrase. The end result is that the user need enter the passphrase for a given secret key only once. The best way to run ssh-agent is probably something like this: In your .xsession, assuming that you just have a line which says exec whateverwm replace it with: exec ssh-agent whateverwm (If you don't have a .xsession, you should make one) This will then make it so that any processes started by your window manager (which, unless you use something like tkdesk and start it from your .xsession, should be every X app you run). Now, you still need to run ssh-add at some point - I suggest either get used to typing it in every time you log back in to X, or put ssh-add in your window managers init function. (This is easy to do with fvwm2, and will be just as easy to with fvwm95 once I get my new version released; I can't speak for other window managers). Setting up ssh-agent and an automatic ssh-add for telnet and console logins is left as an exercise for the reader. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Where is the order of versions specified?
I know I read this at one point, and I _think_ I remember most of it correctly, but which doc. describes how dpkg compares version numbers? I think that in the case of tkdesk I may have to use epochs (the upstream authors have 1.0-beta-1 through 1.0-beta-5 coming before 1.0-pre-1, which comes before 1.0 - am I correct in assuming dpkg will think people are downgrading if I just call the package 1.0?) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
How do I move things around?
What's the procedure for moving something that's been uploaded into unstable into frozen? Whom do I contact and what information do I need to give them? Do I then send out a debian-*-changes message? I uploaded something into unstable but have been convinced that it belongs in frozen. Should I just change the Distribution: header, remake the package, and upload again? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Where do orphaned packages go when you pick them up?
I am the (new) maintainer of tkdesk and am (finally) getting around to packaging it up (blame my end of term exams). My question is: where should this go? It'd be a shame for hamm not to have tkdesk; however, at the time hamm was declared "frozen", tkdesk was not in it, but in project/orphaned. Should it go into unstable only? Does it matter that the version I will be packaging is a new upstream release from the version that was in bo and in project/orphaned? Once I do upload this (to frozen or to unstable), how do I get rid of the tkdesk that is in project/orphaned? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Where do orphaned packages go when you pick them up?
Matthias Klose <[EMAIL PROTECTED]> writes: > tkdesk requires BLT. in frozen, only BLT2.3 exists, which is > compatible to tcl7.6/tk4.2 only. Last weekend I uploaded blt8.0-unoff, a > BLT version compatible to tcl8.0/tk8.0 to unstable (not frozen). Since > tkdesk seems to profit from the byte compiled tcl code, it would be > nice to have this in hamm as well (but would require blt8.0-unoff in > frozen). > > Matthias Um... tkdesk's upstream source comes with its own version of blt, and that's what I'll use - tkdesk can't use tcl/tk 8.0 for other reasons (mostly because itcl doesn't exist for 8.0 yet and because the tkdesk doesn't work with the newer versions of itcl in any case). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Advice on whether/how to close a bug
There's an annoying bug in fvwm95 that I'd like to close (actually, there are several, but the rest are for another day). Here's the bug - if one installs fvwm95 but does not install the "menu" package, then fvwm95 uses the menu derived from the example fvwm95rc provided in the upstream source (rather than leave the user high and dry without anything in the menu). So far so good. Now, the example fvwm95rc includes references to programs that don't exist on any debian system (or exist under a different name). Specifically, the upstream example refers several times to "color_xterm". So here's the bug (#13653) report (yes, it's basically this short): Subject: fvwm95: fvwm95 tries to use color_xterm However, there is no binary named color_xterm on my system. The apparent cause is that the user didn't have the menu package installed and was using the upstream example fvwm95rc. So I have a few options: make fvwm95 depend on menu (it currently Recommends: menu, but only Suggested it at the time of the bug report); modify the default menu to not include color_xterm (note that it may still include programs which aren't installed/aren't in debian); close the bug because anyone who ignores a Recommends should expect some decrease in functionality; (Before you dismiss that option outright as developer arrogance, consider that any bug to xbase that says "I installed xbase (but no xserver) and nothing graphical happens" will be closed with a polite note saying that the user should satisfy xbase's Recommends: field and install an xserver); or rewrite the menu used in the default case so that the only programs appearing in it are those in standard (or essential) Debian packages, or in the packages fvwm95 depends on. So how should I clear out this old bug? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
