Re: Available papersizes vs. default papersizes
Johannes Wiedersich [EMAIL PROTECTED] wrote: Some argued that every paper which can be fed to a printer on the market might be used as default size on a particular system. If you'd like to use a different default, how difficult is the implementation for the user/administrator of the box in question? It's quite straightforward to add new sizes to the configuration files by hand, and also to make the the default size. Therefore it doesn't do much harm when this has to be done by the local admin. And from the point of view of writing packaging scripts it isn't hard, either: I can simply ignore sizes not available in the upstream scripts (should I give a warning on stdout?). Do you have any suggestions? I forwarded your question to d-u. Maybe some 'users' over there have some suggestions of what they use/require... [3] Thank you, good idea! Regards, Frank -- Frank Küster Debian Developer (TeXLive) ADFC Miltenberg B90/Grüne KV Miltenberg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#496967: general: System completely blocks any input
Package: general Severity: grave Since late last week, my system completely hangs - it stops accepting any input from keyboard or mouse - after 3 to 5 minutes after booting. This happens both in a text console and when running X. Of course I suspected a hardware problem first, but the manufacturers test program (a version of PC doctor for IBM Thinkpads) gives no errors at all, and does not result in hanging even after more than an hour. Similarly, I can boot from a Knoppix CD and run it happily for hours. Therefore, it seems to me that it is a problem with the Debian installation, a quite up-to-date testing. There were no log messages at all in syslog, messages, or kern.log which point to a cause. I tried with the current lenny kernel (2.6.26, I think) and the previous one (2.6.25), and there was no difference - so it is probably not the kernel. I have no idea how I can access the LVM volumes on the harddrive, therefore I have a hard time presenting details from logs. I will try to copy interesting things (like dpkg.log) to /boot which is not on LVM. Don't delay lenny's release because of this - but in case this is actually a grave bug, I think I'd rather report it now than complain later... Regards, Frank -- System Information: Debian Release: 4.0 Architecture: i386 (i686) Shell: /bin/sh linked to /UNIONFS/bin/bash Kernel: Linux 2.6.19 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) (ignored: LC_ALL set to [EMAIL PROTECTED]) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#496967: general: System completely blocks any input
Hi, Am 28.08.2008 um 22:41 schrieb Frank Küster: Package: general Severity: grave Since late last week, my system completely hangs - it stops accepting any input from keyboard or mouse - after 3 to 5 minutes after booting. This happens both in a text console and when running X. I should have been more specific here. It's not only the input, it's the output as well. For example, if aptitude is downloading packages in an rxvt window, the percent count stops changing as well, the display is also frozen. Any (ethernet) network also seems to stop: It no longer answers to pings, and a remote ssh login stops working, too. Any ideas how I can start debugging this? Regards, Frank -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#496967: general: System completely blocks any input
Hi, Am 29.08.2008 um 20:20 schrieb Lars Wirzenius: pe, 2008-08-29 kello 19:51 +0200, Frank Küster kirjoitti: Any ideas how I can start debugging this? My first suspicion would be about the hardware. Mine too. You could run memtest86+ for at least 12 hours or until the first error. Can I download an iso image of a boot CD with memtest86+ somewhere? I have only this single Linux machine at the moment, and there's no chance at all that the machine works long enough that I am able to install the package and understand how to create an image. Another idea: you could test the system with another version of Debian, or with Ubuntu, Knoppix, or another live CD, and see if you can reproduce the problem with that. That's exactly what I did and why I am reporting this as a Debian bug: It never occurred when booting from a Knoppix CD, even after hours. The only thing that is different hardware-wise is that the harddisk is mostly inactive in Knoppix. Is there any live system available which can handle lvm volumes? I think I even have some free disk space for an additional partition to install the live system on harddisk. But I cannot access it from Knoppix, and didn't find information on lvm in the Knoppix FAQ. TIA, Frank -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#496967: general: System completely blocks any input
Hi, Am 29.08.2008 um 23:44 schrieb J.A. Bezemer: Boot with init=/bin/sh and wait. Still hangs? - kernel or hardware problem. It didn't hang for nearly an hour, and now again with the first couple of scripts in /etc/rcS.d executed it is running for 20 minutes. I'll give it 15 minutes after each change and then try the next couple of scripts. By the way, is there a possibility to stop a process in /bin/sh? I executed while true; do uptime; sleep 10; done and couldn't stop it with Ctrl+c. I invoked bash as a workaround. Open case and put a big fan in front. Replace power supply. It's a laptop, and the sensors didn't report anything suspicious. It hangs with battery only and with external power only, that doesn't matter. Thanks for the hints (strange how one is completely devoid of ideas when it's one's one machine...) Regards, Frank -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#496967: general: System completely blocks any input
reassign 496967 linux-2.6 forcemerge 479709 496967 thanks Stepan Golosunov [EMAIL PROTECTED] wrote: Looks similar to #479709, which happens with linux 2.6.25/2.6.26 but not 2.6.24 and seems to be provoked by chrony. Bingo, thanks. Although I personally feal the bug is super-duper-hyper-grave, I leave the judgement to the linux maintainers. Regards, Frank -- Frank Küster Debian Developer (TeXLive) ADFC Miltenberg B90/Grüne KV Miltenberg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Directories named after packages
Osamu Aoki os...@debian.org wrote: 3. Historic/Upstream choice (?): /usr/share/doc/texmf (Several TeX packages uses this.) That's old-fashioned (or, well, obsolete). I think (without looking at code or our sub-policy) this should be a symlink to /usr/share/texmf/doc - and TeX packages should make sure their documentation is findable both in /usr/share/doc/package (for Debian Policy) and /usr/share/texmf/doc (for the TeX tools). If one package installs it as a directory, might files from other packages also be installed there? Regards, Frank -- Dr. Frank Küster VCD Miltenberg, ADFC Aschaffenburg-Miltenberg B90/Grüne KV Miltenberg Debian Developer (TeXLive) -- 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/87wrmcpgsu@alhambra.kuesterei.ch
Re: Writing to /etc/ from a privileged UI
Jan Hauke Rahm j...@debian.org wrote: On Mon, May 09, 2011 at 04:59:39PM +0200, David Paleino wrote: On Mon, 9 May 2011 09:45:41 -0400, Marvin Renich wrote: Actually, one normal user should not be able to override the admin defaults for another user, so if there is already an entry in /etc, wicd should place any user change to that entry in ~user, but new, non-conflicting entries should go in /var/lib. Then, the order of preference should be ~user, /etc, /var/lib. I can't understand all this. Network connections are system-wide by their own nature -- or do you know cases where there could be different concurrent connections used by different users? No. Not at the same time, but someone might allow a user of a laptop to access their WLAN, but neither accept that an other user of the laptop should be able to use the same network without asking, nor that the keys be written in a system-wide configuration file. Regards, Frank -- Frank Küster Vorstand B90/Grüne OV Miltenberg und Umgebung VCD Miltenberg, ADFC Aschaffenburg-Miltenberg Debian Developer (TeXLive) -- 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/87ei456m0b@alhambra.kuesterei.ch
Re: Writing to /etc/ from a privileged UI
Adam Borowski kilob...@angband.pl wrote: On Wed, May 11, 2011 at 10:05:40PM +0200, Frank Küster wrote: Not at the same time, but someone might allow a user of a laptop to access their WLAN, but neither accept that an other user of the laptop should be able to use the same network without asking, nor that the keys be written in a system-wide configuration file. Sorry but if you alternate physical possession of a laptop with someone whom you suspect of being hostile, no files are secure as long as they're stored on that laptop. In addition to the remarks of the others: It's not just about me as the laptop user trusting or not trusting other laptop users. I was rather thinking about a network owner allowing a particular person to use their access point, after being trained in the local policy and - what is more important to a certain type of staff - having signed and accepted that policy. The policy will probably contain a may not give a third party access to the information... Regards, Frank -- Frank Küster Vorstand B90/Grüne OV Miltenberg und Umgebung VCD Miltenberg, ADFC Aschaffenburg-Miltenberg Debian Developer (TeXLive) -- 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/87k4dv66t8@alhambra.kuesterei.ch
Re: Auto Backporting
Andreas Tille andr...@an3as.eu wrote: IMHO this problem is not really Debian Science or Blends related and the idea to handle backports analog to non-free autobuilds sounds quite reasonable - but in this case we *really* make it analog tp non-free which works with a debian/control field XS-Autobuild: yes So why not using a similar field XS-Autobackport: yes For some teTeX (or older TeXLive?) packages, I've used a sarge-backport (or whatever the stable version was) target in debian/rules. It added a changelog entry with backport version number, and it switched some patches and build-deps (in particular, poppler wasn't available in stable, and we resorted to build with the embedded copy of xpdf code). Maybe that could help with some other packages, too - then the target should be standardized for those autobuilders. Regards, Frank -- Dr. Frank Küster Debian Developer (TeXLive) VCD Aschaffenburg-Miltenberg, ADFC Miltenberg B90/Grüne KV Miltenberg -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: What is this rule for?
Russ Allbery r...@debian.org wrote: Andreas Tscharner starf...@sunrise.ch writes: This is true for Unix/Posix systems, but unfortunately not for Windows systems. And if the maintainer of a great Perl script wants his script to work on both platforms, he'll probably will name it GreatPerlScript.pl If the extension .pl is linked with a Perl interpreter in Windows, he'll be able to run it on both systems without a prepending perl If he names it GreatPerlScript on Unix and GreatPerlScript.pl on Windows, he'll be able to run it on both systems as GreatPerlScript. Yes. And those scripts that would run on Windows and expect GreatPerlScript.pl, but do not run on Unix *only* because the pl is missing - those script probably don't exist. Regards, Frank -- Dr. Frank Küster Debian Developer (TeXLive) VCD Aschaffenburg-Miltenberg, ADFC Miltenberg B90/Grüne KV Miltenberg -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Policy §10.4 as a divergence from usptream (renamings to remove extensions like .pl and .sh).
David Goodenough david.goodeno...@btconnect.com wrote: I am a newcommer to this particular bit of policy, but it occurs to me that the answer is to add links to the original commands to conform to Debian standards while leaving the upstream commands intact. That would horribly clutter the bin directories. I think the approach with a /usr/share/$packagename/bin/ that contains the old names as links, and can be added to PATH, is the best we can do for supporting scripts that assume extensions. Regards, Frank -- Dr. Frank Küster Debian Developer (TeXLive) VCD Aschaffenburg-Miltenberg, ADFC Miltenberg B90/Grüne KV Miltenberg -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Moving binary packages between source packages, and closing bugs
Hi, assume a binary package A has been built from source package X, but a new upload of source packages X and Y moves it, and it is now built from Y. Now, will the changes file of Y properly close the bug in A? In other words, will the BTS be aware of the change in source package before the changes file is processed? To make things even more complicated, the first upload of the new packages would be to experimental... TIA, Frank -- Dr. Frank Küster Debian Developer (TeXLive) VCD Aschaffenburg-Miltenberg, ADFC Miltenberg B90/Grüne KV Miltenberg -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Moving binary packages between source packages, and closing bugs
Roberto C. Sánchez robe...@connexer.com wrote: On Sat, Oct 03, 2009 at 04:54:54PM +0200, Frank Küster wrote: Hi, assume a binary package A has been built from source package X, but a new upload of source packages X and Y moves it, and it is now built from Y. Now, will the changes file of Y properly close the bug in A? In other words, will the BTS be aware of the change in source package before the changes file is processed? In my experience, the answer to this is yes. Thanks, fine! (also to Don) Frank -- Dr. Frank Küster Debian Developer (TeXLive) VCD Aschaffenburg-Miltenberg, ADFC Miltenberg B90/Grüne KV Miltenberg -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
Stefano Zacchiroli z...@debian.org wrote: On a second read of the proposal, it occurred to me (and a handful of other DDs in private communications agreed) that the above naming choice of warning and error can be a bit unfortunate. In fact, lintian already has its own notion of warning/error and having the naming overloaded by dak messages that are based on lintian outcome can be quite confusing. ACK -- Dr. Frank Küster Debian Developer (TeXLive) VCD Aschaffenburg-Miltenberg, ADFC Miltenberg B90/Grüne KV Miltenberg -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Policy conformant conffile handling...
Hi, I had thought that I had understood it. But somehow I'm again running into problems when it comes to manipulating configuration files with maintainer scripts. TeXLive contains many binaries that change output depending on the papersize used. Each of them has a configuration file which - among other settings - defines the default papersize (it can and should be overwritten in the TeX input file). Now I want to integrate this with libpaper: The default papersize for each binary should be the system paper as given by libpaper. TeXLive upstream even ships a configuration program, texconfig, that allows to set the papersize for all binaries to the same value. However, and here's the policy-related problem: Of course the admin might have changed the default paper for one particular binary manually. What should I do in this case? Here are some options I considered: - let libpaper's setting overwrite everything: Probably not intended; not policy-compliant - patch the upstream texconfig tool to check for a string like % Debian-manually-changed-configuration=NO and only propagate the libpaper setting if this is unchanged. This is, IMO, a) ugly b) error prone, since people tend to overlook they need to make two changes - add some complex script logic that tries to detect whether a configuration file has been changed by checking * whether the setting is still as shipped, or * still the same as set by the last invocation of texconfig, to be recorded somehow if one of the questions is answered no, don't change anything. At the moment, I think the last option seems to be the only really policy-compliant way. On the other hand, it is ugly hacking, requires a rather complicated patch to texconfig that might be hard to maintain, and if we ever were to change the default as shipped (e.g. because we overlook an upstream change), the patch would get even messier. Are there any other options? Currently, the configuration files in question are all conffiles; we'd have to change that, too, I guess. I have not followed this field in the last years; I guess ucf is still the method of choice if a maintainer script needs to do a specific manipulation in an otherwise not-generated configuration file? TIA, Frank -- Dr. Frank Küster Debian Developer (TeXLive) VCD Aschaffenburg-Miltenberg, ADFC Miltenberg B90/Grüne KV Miltenberg -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Policy conformant conffile handling...
Steve Langasek vor...@debian.org wrote: On Thu, Dec 03, 2009 at 11:40:06AM +0100, Frank Küster wrote: However, and here's the policy-related problem: Of course the admin might have changed the default paper for one particular binary manually. What should I do in this case? [...] - let libpaper's setting overwrite everything: Probably not intended; not policy-compliant Is texconfig being called from maintainer scripts? In this case, at least indirectly; since I would drop a script into /etc/libpaper.d/ that calls texconfig paper $(paperconf -n -d) Using the 'include' capabilities for anything that supports it would surely still be better, though. That's not possible for many of the binaries involved. @ the TeX list mainly There's only one use case where *not* setting the paper according to the system paper actually causes problems, and that is when directly printing from the command line. Once a PDF is generated, the PDF viewer will usually be used for printing, and will have options to deal with paper mismatches. In other words, it's mainly dvips that's we need to cater for. Is there an include mechanism for dvips, or a way to override settings in config.ps for all printers? Regards, Frank -- Dr. Frank Küster Debian Developer (TeXLive) VCD Aschaffenburg-Miltenberg, ADFC Miltenberg B90/Grüne KV Miltenberg -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Policy conformant conffile handling...
Frank Küster fr...@debian.org wrote: Steve Langasek vor...@debian.org wrote: On Thu, Dec 03, 2009 at 11:40:06AM +0100, Frank Küster wrote: However, and here's the policy-related problem: Of course the admin might have changed the default paper for one particular binary manually. What should I do in this case? [...] - let libpaper's setting overwrite everything: Probably not intended; not policy-compliant Is texconfig being called from maintainer scripts? In this case, at least indirectly; since I would drop a script into /etc/libpaper.d/ that calls texconfig paper $(paperconf -n -d) It would be okay to ask debconf questions here, wouldn't it? Then I'll let texconfig analyse the settings in all involved config files, and if they differ, ask the admin to which the libpaper setting should be applied. Regards, Frank -- Dr. Frank Küster Debian Developer (TeXLive) VCD Aschaffenburg-Miltenberg, ADFC Miltenberg B90/Grüne KV Miltenberg -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Using ucf other than from maintainer scripts
Hi, I am wondering whether it is possible to use ucf from a script that is provided by a package to simplify local changes to a configuration file. The case I'm thinking of is texconfig, a script in texlive-binaries that (among other things) allows to set the default paper size for a couple of applications. The files that are changed to accomplish that are currently conffiles. I want to use a hook in /etc/libpaper.d/ to set the correct default paper, but that would mean to change conffiles in maintainer scripts (maybe not by the letter of the rule, since a hook is not a maintainer script, but by its meaning, and by dpkg's annyoing questions). The obvious way out is to use ucf to handle the changes - but of course the texconfig script can also be invoked manually by the admin. Is it okay to use ucf in this case? The script would always take the existing version, apply its changes to the papersize setting, and commit it with ucf - hence no three-way-merge situation is possible here. When other settings in that files, besides papersize, change in an upload, that would be handled the usual ucf way by texlive-binaries' postinst script. Would that work? TIA, Frank P.S. In that case, can I pass --debconf-ok to ucf even for the case where it is invoked manually by the admin with no debconf already running; I mean, will debconf still *check* whether there's a debconf instance running? -- Dr. Frank Küster Debian Developer (TeXLive) VCD Aschaffenburg-Miltenberg, ADFC Miltenberg B90/Grüne KV Miltenberg -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: New Menu category Applictions/Multimedia
Andreas Marschke xxtj...@googlemail.com wrote: Personally I think we should have gotten rid of the Debian menu years ago, I don't think my opinion is shared by many people in Debian though. It is truely kind of doubled effort to have the debian menu extra to the actual menu. The question is who will step forward and propose the removal? We can make a new thread for this. Please read the archives. That has been discussed over and over. By the way, one thing you'll learn is to use terms that everyone understands without problems, and that not everyone is using a Desktop envirnoment. In my window manager, there's only one menu, and that's the Debian one. Regards, Frank -- Dr. Frank Küster Debian Developer (TeXLive) VCD Aschaffenburg-Miltenberg, ADFC Miltenberg B90/Grüne KV Miltenberg -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: German Debian
I'm a bit late but... Marc Haber mh+debian-de...@zugschlus.de wrote: Unfortunately, all of Debian. Translating technical texts from English to German is controversial at its best, and the Debian translators have taken my least favorite approach of eliminating all English, leading to barbarities like SMTP-Sendezentrale or Sicherheitsgutachten. Debian's German translations feel to me (a native speaker of German) as babelfished from English. ACK I used to take a look at Debian's translations of my own package's Debconf templates, but nowadays I just treat them as just another language that I don't speak. This approach saves me a lot of grief. Same here. Sounds like Debian has QA issues wrt the website translations. I assume that you reported that to the German website l10n folks, debian-i18n and debian-www? They are resistant to advice and think their way is the correct way. They work with a word list, so it must be correct. I found the same. They seem to want to invent a new german IT-lingo, which simply isn't accepted by the majority who just talk german grammar with english vocabulary. I don't care anymore for german translations. May the ones who cannot read the english original *and* have trouble with the german text discuss with them. Regards, Frank -- Dr. Frank Küster Debian Developer (TeXLive) VCD Aschaffenburg-Miltenberg, ADFC Miltenberg B90/Grüne KV Miltenberg -- 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/871vf1d1lc@alhambra.kuesterei.ch
Re: new passwd
Raphael Hertzog [EMAIL PROTECTED] wrote: On Thu, 07 Sep 2006, Atsuhito Kohda wrote: So I tried to get a new passwd following the instruction of http://db.debian.org/password.html at about 12am JST (3am UTC) but I've gotten nothing yet (after one day already). Does the procedure echo Please change my Debian password | gpg --clearsign \ | mail [EMAIL PROTECTED] work yet? I get nothing even now. Are you sure that the GPG key is still in the Debian keyring? gpg --no-default-keyring --keyring /usr/share/keyrings/debian-keyring.gpg --list-keys kohda pub 1024D/5BFA90EC 2000-04-28 uid Atsuhito KOHDA [EMAIL PROTECTED] uid Atsuhito Kohda [EMAIL PROTECTED] uid Atsuhito Kohda [EMAIL PROTECTED] sub 1024g/7E522785 2000-04-28 Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
whitelisting @*.debian.org (was: Request to mailing list Pkg-qof-maintainers rejected)
Pierre Habouzit [EMAIL PROTECTED] wrote: it's not the first time such a question is raised, I did that recently enough, for a foo-package I don't even remember (some python messages that bounced to me). that is completely inadequate, and whitelisting any @bugs.debian.org From address is trivial. Might be, but it's not trivial to find out how to do it. Can you tell me how to whitelist mail from foo.debian.org, or from certain senders to an alioth mailing list? Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Why udev does not use update-rc.d in its postinst
George Danchev [EMAIL PROTECTED] wrote: Hello, There is a /etc/init.d/udev script provided by the udev package, but as it seems no entity cares to start it at boot time to populate the /dev directory. Are there any good reasons for udev not to call update-rc.d from its postinst to install the necessary symlinks in place ? Next, there might be a udev entry in /etc/default/ to control start-on-boot behaviour of that init.d script. tail /var/lib/dpkg/info/udev.postinst # Automatically added by dh_installinit if [ -x /etc/init.d/udev ]; then update-rc.d udev start 03 S . /dev/null || exit 0 fi # End automatically added section # Automatically added by dh_installinit if [ -x /etc/init.d/udev-mtab ]; then update-rc.d udev-mtab start 36 S . /dev/null || exit 0 fi # End automatically added section That's the version in testing, but the source package in sid also has all that's needed to get it in again, unless there's a hard-to-see subtle error. Maybe you have some link to /etc/init.d/udev left in a runlevel you don't use, or only a kill link? Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Why udev does not use update-rc.d in its postinst
[EMAIL PROTECTED] (Marco d'Itri) wrote: On Sep 11, Frank Küster [EMAIL PROTECTED] wrote: That's the version in testing, but the source package in sid also has all that's needed to get it in again, unless there's a hard-to-see subtle error. Like the update-rc.d bug discussed here in the last few days. Which wouldn't result in the udev binary package's postinst missing the update-rc.d call, as George asserted. And this bug probably would disable more init scripts than this one (I didn't read it in detail, since by chance I didn't upgrade to any problematic version). Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Why not only support Sid and Testing?
Gabriel Puliatti [EMAIL PROTECTED] wrote: Also, maintainers _need_ to run unstable. No, I don't agree here. How else would they test the latest package that has been uploaded and see if any bugs need to be fixed before it moves into testing? I'm running unstable in a chroot, but I hardly work there. I'm working with the current sid packages backported to my sarge box. After all, I'm using it not only for maintaining Debian packages, but also for doing unrelated paid work, and I couldn't afford to have fun and unpredictible effects. Whether there are bugs that need to be fixed before it moves into testing, this has to be done by the community. After all, even RC bugs, let alone normal and important ones, often need some tweaking and adjustment before I can reproduce them on my system. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: transitioning config files between two packages
sean finney [EMAIL PROTECTED] wrote: so the question is: what am i forgetting to do? i'm guessing that the problem has something to do with the original package still being present (as a metapackage)? No, it's a general problem: dpkg won't notice that a conffile has been moved from one package to the other, no matter whether it declares Replaces or whatever. There's simply no solution within dpkg at the moment. The only way I know of to get rid of the bogus questions is to put the files under ucf control. In the long run, it would be nice if dpkg got ucf's nice features. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: transitioning config files between two packages
James Vega [EMAIL PROTECTED] wrote:
It should just be a matter of removing the files from the old package
and letting the new ones take their place (with a backup if there are
any user changes). A little grepping around in /var/lib/dpkg/info
turned up this snippet for removing conffiles.
nagios-plugins.preinst:
rm_conffile() {
CONFFILE=$1
if [ -e $CONFFILE ]; then
md5sum=`md5sum \$CONFFILE\ | sed -e \s/ .*//\`
old_md5sum=`sed -n -e \/^Conffiles:/,/^[^ ]/{' $CONFFILE'{s/.*
//;p}}\ /var/lib/dpkg/status`
if [ $md5sum != $old_md5sum ]; then
echo conffile $CONFFILE has been modified by you.
echo Saving as $CONFFILE.dpkg-bak ...
mv -f $CONFFILE $CONFFILE.dpkg-bak
This violates the spirit of Policy 10.7.3:
local changes must be preserved during a package upgrade, and
and, I think, the word of the next sentence:
configuration files must be preserved when the package is removed, and
only deleted when the package is purged.
Regards, Frank
--
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)
Re: transitioning config files between two packages
Steve Langasek [EMAIL PROTECTED] wrote: On Tue, Sep 12, 2006 at 01:28:34PM +0200, Frank Küster wrote: sean finney [EMAIL PROTECTED] wrote: so the question is: what am i forgetting to do? i'm guessing that the problem has something to do with the original package still being present (as a metapackage)? No, it's a general problem: dpkg won't notice that a conffile has been moved from one package to the other, no matter whether it declares Replaces or whatever. There's simply no solution within dpkg at the moment. Where do you get this? Conflicts:/Replaces: has been used quite successfully to transfer ownership of conffiles for, e.g., the Xorg packages, without spurious prompts. Hm, I did get this from the fact that I got lots of spurious prompts, both with my own and with others' packages. However, in all cases I remember there was either only a versioned Conflicts, or no Conflicts at all. I also don't see anything in the policy that indicates that Conflicts has an effect on things that should be covered by Replaces; and I think that it shouldn't. If dpkg already has the means to cleanly take over conffiles from an other package, why not just do this when the taking-over package declares Replaces? Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: transitioning config files between two packages
sean finney [EMAIL PROTECTED] wrote:
if anyone here has some dpkg-fu handy off the top of their heads that i
could use to further deduce what's going on i'd be happy to hear it.
DPKg
{
options --debug=221
}
in a file in /etc/apt/conf.d/ should do (this is untested, please check
the details).
I do know also that beginning with the dpkg version in etch, the Conflicts:
is no longer required when moving conffiles, it's possible to use Replaces:
by itself.
okay. the conflict is there for other reasons as well but i'll keep
that in mind for other packages.
But then you should make sure that dpkg is updated first:
apt-get update
apt-get install dpkg apt #and aptitude, if you like
apt-get dist-upgrade # or aptitude
Regards, Frank
--
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)
Re: transitioning config files between two packages
Steve Langasek [EMAIL PROTECTED] wrote: So to fix this within your preinst, you could check whether each file's md5sum matches the known md5sum from sarge, and if so remove the file. If the md5sum /doesn't/ match, the conffile prompt should happen as normal. The conffile present might also be yet a different one, from a version earlier in etch's release cycle. At least if the package splitting has just been done in the last version in unstable, it's likely that there are machines around with such versions installed. Of course it's much more important to not give dpkg prompts on dist-upgrades from stable to new stable, but IMHO it should also be avoided during a development cycle: Many people use sid or testing for their workstations, although they don't know much about internals and what triggers bogus prompts. Ah, and I forgot: Even oldstable deserves its md5sums to be recorded. This has bitten us with tetex-extra: People had tetex-extra installed when the machine was woody, then removed it but did not purge - so the conffiles were still there. Only after switching to etch did they reinstall the package, and... The result can be admired in /var/lib/dpkg/info/tetex-extra.preinst, look for .*_md5sum_list. We didn't use ucf because these files all disappeared. It's up to you whether you think ucf is a better way to handle this. At least it is able to record a set of md5sums for a given file. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: transitioning config files between two packages
Steve Langasek [EMAIL PROTECTED] wrote: On Thu, Sep 14, 2006 at 01:32:43AM +0200, Javier Fernández-Sanguino Peña wrote: On Tue, Sep 12, 2006 at 05:21:50PM -0700, Steve Langasek wrote: After an upgrade and answering all of the conffile prompts, does /var/lib/dpkg/info/nagios-plugins.conffiles still exist and reference these files? Depending on what dpkg is really doing here, it may well be possible to handle the conffile transfer in maintainer scripts. (And I thought dpkg.org once had recipes for exactly this, but unfortunately the site has been down for some time now. :/) Are you looking for http://wiki.debian.org/DpkgConffileHandling ? (just found it googling). I guess this information (if current) should be moved over to the developer's reference. That seems to be the one. It also doesn't seem to address changing the owner of a conffile.. ohwell. :) Maybe I'm dumb, but this code doesn't seem correct to me, in the sense that it doesn't do the right thing. Let's consider a couple of possible cases: 1. The conffile at the old place (or package) is the same as the one in the new place In this case the code in the wiki does the right thing. 2. At the same time as the move is done, the contents of the file do also change. And here same time doesn't necessarily mean same upload, it can as well be same run of dist-upgrade, which often skips intermediate versions, especially when upgrading from stable to new stable. In this case the user should get a conffile prompt during upgrade, to be able to consider the changes made in the package. But that won't happen with the code in the wiki; instead the old, locally changed version will be used unconditionally. There might be ways to do it right with dpkg only, but ucf is probably easier. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: transitioning config files between two packages
Bill Allombert [EMAIL PROTECTED] wrote: On Tue, Sep 12, 2006 at 05:21:50PM -0700, Steve Langasek wrote: I do know also that beginning with the dpkg version in etch, the Conflicts: is no longer required when moving conffiles, it's possible to use Replaces: by itself. I wonder if a versioned depend on dpkg can ensure the new dpkg is used to handle the package ? (the idea is to make sure to use the improved dpkg for package rename). Don't the release notes suggest to upgrade apt, dpkg and aptitude first, anyway, as they usually did? Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: lilypond and thanks to Rob Browning
Thomas Bushnell BSG [EMAIL PROTECTED] wrote: It is my hope that #359855 will not exist in the new lilypond. However, this is just a hope. If ghostscript continues to have such a bug, then solving it will become of critical priority for getting lilypond into the release. Are your preliminary packages of 2.8 avaiable anywhere, as well as the guile-1.8 packages? I wanted to try, but got more problems with 2.6 which probably aren't worth reporting when we're trying to get 2.8 in. TIA, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: lilypond and thanks to Rob Browning
Thomas Bushnell BSG [EMAIL PROTECTED] wrote: But Bill Allombert has helpfully provided a hint about what will solve the bug; if that works, I'll upload 2.6 now with the RC bugs fixed, and 2.8 as soon as feasible. I tried to look at the bug Bill has solved by installing ttf packages, because I wanted to understand the problem; but I didn't even get that far, the build failed even earlier. I'll try to reproduce that and report it. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: transitioning config files between two packages
Steve Langasek [EMAIL PROTECTED] wrote: Yes, you're right that this code unconditionally uses the user's version of the conffile when moving it, instead of allowing the conffile question to happen. The way to get the conffile prompt for a user-modified file is Someone should correct this in the wiki. I wanted to do this, but won't have time to start yet an other Debian work. TIA, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: transitioning config files between two packages
Frank Küster [EMAIL PROTECTED] wrote:
Steve Langasek [EMAIL PROTECTED] wrote:
Yes, you're right that this code unconditionally uses the user's version of
the conffile when moving it, instead of allowing the conffile question to
happen.
The way to get the conffile prompt for a user-modified file is
Hm, I've tried to write that up in the Wiki, but I found that I don't
completely understand what you wanted. You wrote:
,
| The way to get the conffile prompt for a user-modified file is to move the
| old version of the conffile to the new location in the preinst if the old
| conffile md5sum doesn't match the current conffile md5sum for the package.
| Since the earlier preinst code has already removed any old versions of the
| file that are known to be unmodified, this won't give any undesirable
| conffile prompts.
`
Thus far, it seems clear to me. We just need to change the preinst code
from the Wiki:
prep_mv_conffile() {
CONFFILE=$1
+ NEWCONFFILE=$2
if [ -e $CONFFILE ]; then
md5sum=`md5sum \$CONFFILE\ | sed -e \s/ .*//\`
old_md5sum=`sed -n -e \/^Conffiles:/,/^[^ ]/{' $CONFFILE'{s/.*
//;p}}\ /var/lib/dpkg/status`
if [ $md5sum = $old_md5sum ]; then
rm -f $CONFFILE
+ else
+ mv $CONFFILE $NEWCONFFILE
fi
fi
}
Now I thought that is all that needs to be done: Simply ship the
conffile, and now dpkg will
- simply install it if prep_mv_conffile has found the old one unchanged
and removed it
- ask the desired conffile prompt if prep_mv_conffile has found it
changed and already moved to the new place.
Now all that's missing is that dpkg probably still things that the old
package is in state rc, with the conffile at the old place
registered. But that's nothing a maintainer script can solve[1].
However, you (Steve) continued:
,
| Then, if dpkg's stored md5sum for the old conffile *does*
| match that of the current shipped conffile (which you'll know because you
| still have the conffile present in the old location in the postinst), you
| would go ahead with this same code in the postinst to move it into place
| silently.
`
As explained above, I don't understand why any more code is needed at
all. Second, all this has been done in preinst already: compare md5sums
(although not with the current shipped one), move into place.
What am I missing?
Regards, Frank
[1] manually calling aptitude purge or dpkg --purge on packages in
rc is something that helps here. But this possibility means that it is
in fact desirable to rename conffiles when they are taken over by other
packages. Otherwise you can't write Transitional package. This can
savely be removed..., since people will probably understand that as or
purged.
--
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)
Possible regression in teTeX due to license problems: Please check whether your package is affected
Zacchiroli [EMAIL PROTECTED] advi (U) bibtex2html (U) hevea (U) ocamlweb (U) Anton Zinoviev [EMAIL PROTECTED] scalable-cyrfonts Bas Zoetekouw [EMAIL PROTECTED] mp Michael K. Edwards (in Debian context) [EMAIL PROTECTED] advi (U) Sam Hocevar (Debian packages) [EMAIL PROTECTED] tmview -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Possible regression in teTeX due to license problems: Please check whether your package is affected
Frank Küster [EMAIL PROTECTED] wrote: Summary: We will probably have to remove files from teTeX due to license problems: Please check whether your package is affected! ... and tell us. Note that we have tried to contact as many upstream authors as possible, and we will probably not need to remove all of them. Some, however, will surely have to go, and we need to be prepared. ... Therefore, we would like to collect the information on debian-tex-maint and coordinate there what we need to do. Sorry for being short, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Possible regression in teTeX due to license problems: Please check whether your package is affected
] gretl gsl octave2.1-forge (U) r-base rpy Peter Eisentraut [EMAIL PROTECTED] cdbs (U) ggz-docs (U) Rene Engelhard [EMAIL PROTECTED] texpower Baruch Even [EMAIL PROTECTED] chktex ivritex Peter Van Eynde [EMAIL PROTECTED] cl-asdf cmucl sbcl slime Fabian Fagerholm [EMAIL PROTECTED] albatross Sean Finney [EMAIL PROTECTED] mysql-dfsg-5.0 (U) Anthony Fok [EMAIL PROTECTED] hbf-cns40-1 hbf-cns40-2 hbf-cns40-3 hbf-cns40-4 hbf-cns40-5 hbf-cns40-6 hbf-cns40-7 hbf-cns40-b5 hbf-jfs56 hbf-kanji48 iterm tfm-arphic tochnog Arnaud Fontaine [EMAIL PROTECTED] glosstex tagcoll (U) Gustavo Franco [EMAIL PROTECTED] apt-howto (U) Romain Francoise [EMAIL PROTECTED] tramp David Frey [EMAIL PROTECTED] magicfilter Mike Furr [EMAIL PROTECTED] numerix (U) Brian R Furry [EMAIL PROTECTED] cassbeam dvipng Peter S Galbraith [EMAIL PROTECTED] gri mh-e Sylvain Le Gall [EMAIL PROTECTED] advi (U) numerix (U) RISKO Gergely [EMAIL PROTECTED] sbm Julian Gilbey [EMAIL PROTECTED] cwebx debian-policy (U) epix1 sgb tetex-src (U) Kevin Glynn [EMAIL PROTECTED] mozart John Goerzen [EMAIL PROTECTED] bacula-doc gpsbabel lhs2tex Federico Di Gregorio [EMAIL PROTECTED] noweb Debian QA Group [EMAIL PROTECTED] aleph autobook cfi cl-tclink ilisp malaga Yu Guanghui [EMAIL PROTECTED] debian-zh-faq dvipdfmx Pierre Habouzit [EMAIL PROTECTED] kdegraphics (U) Pascal Hakim [EMAIL PROTECTED] snort (U) Christian Hammers [EMAIL PROTECTED] mysql-dfsg-5.0 quagga Chris Hanson [EMAIL PROTECTED] mit-scheme-doc r5rs-doc uudeview Sam Hartman [EMAIL PROTECTED] pam psp Tollef Fog Heen [EMAIL PROTECTED] cfengine Eric Heintzmann [EMAIL PROTECTED] gnustep-base (U) gnustep-gui (U) gnustep-make (U) gorm.app (U) Raphael Hertzog [EMAIL PROTECTED] logidee-tools Benjamin Mako Hill [EMAIL PROTECTED] mairix Sven Hoexter [EMAIL PROTECTED] lyx (U) Gregor Hoffleit [EMAIL PROTECTED] python2.3-doc (U) Mark Howard [EMAIL PROTECTED] gjdoc (U) Adam C. Powell, IV [EMAIL PROTECTED] illuminator Ian Jackson [EMAIL PROTECTED] userv Daniel Jacobowitz [EMAIL PROTECTED] dejagnu gdb gdb-doc Aurelien Jarno [EMAIL PROTECTED] pyfits (U) sane-backends (U) sdcc Isaac Jones [EMAIL PROTECTED] darcs Robert Jordens [EMAIL PROTECTED] gnuift Guillem Jover [EMAIL PROTECTED] gpm (U) Atsuhito KOHDA [EMAIL PROTECTED] foiltex tetex-src (U) Theppitak Karoonboonyanan [EMAIL PROTECTED] thailatex Georges Khaznadar [EMAIL PROTECTED] collatinus wims David Kimdon [EMAIL PROTECTED] boot-floppies (U) Bastian Kleineidam [EMAIL PROTECTED] fiaif Matthias Klose [EMAIL PROTECTED] bash doxygen gcc-3.4 (U) gcc-snapshot (U) gnat-glade-doc (U) gnat-gps (U) libaws (U) python2.3-doc python2.4 python2.4-doc python2.5 python2.5-doc Daniel Kobras [EMAIL PROTECTED] glame Michael Koch [EMAIL PROTECTED] gjdoc (U) Matt Kraai [EMAIL PROTECTED] autogen Kilian Krause [EMAIL PROTECTED] speex (U) Frank Küster [EMAIL PROTECTED] tetex-src (U) Rafael Laboissiere [EMAIL PROTECTED] latex-mk octave2.1 (U) octave2.1-forge (U) octave2.9 (U) octave2.9-forge (U) tipa Mario Lang [EMAIL PROTECTED] flite Steve Langasek [EMAIL PROTECTED] pam (U) Thomas Lange [EMAIL PROTECTED] fai Carlos Laviola [EMAIL PROTECTED] fpc Simon Law [EMAIL PROTECTED] circ-tex gnu-standards pbox-tex Chris Lawrence [EMAIL PROTECTED] latex2rtf Robert Lemmen [EMAIL PROTECTED] ragel Chuan-kai Lin [EMAIL PROTECTED] bison-1.35 bison-doc Sven Luther [EMAIL PROTECTED] advi (U) numerix (U) Ramakrishnan M [EMAIL PROTECTED] debian-reference (U) Eduardo Marcel Macan [EMAIL PROTECTED] apt-howto (U) Pierre Machard [EMAIL PROTECTED] doc-debian (U) mozart (U) Marcelo E. Magallon [EMAIL PROTECTED] wmaker-usersguide Camm Maguire [EMAIL PROTECTED] acl2 axiom cxref ess gcl gclcvs maxima refblas3 Henning Makholm [EMAIL PROTECTED] bibtool OHURA Makoto [EMAIL PROTECTED] auctex (U) jadetex latex-xcolor okumura-clsfiles preview-latex xemacs21-packages Jerome Marant [EMAIL PROTECTED] advi (U) Konstantinos Margaritis [EMAIL PROTECTED] blitz++ Christoph Martin [EMAIL PROTECTED] tetex-src (U) Christopher Martin [EMAIL PROTECTED] kdegraphics (U) Brian Mays [EMAIL PROTECTED] netcdf-doc Kevin B. McCarty [EMAIL PROTECTED] feynmf mclibs mn-fit A Mennucc1 [EMAIL PROTECTED] waili Andreas Metzler [EMAIL PROTECTED] libgcrypt11 (U) Josh Metzler [EMAIL PROTECTED] kdegraphics (U) Samuel Mimram [EMAIL PROTECTED] advi (U) numerix (U) Steffen Moeller [EMAIL PROTECTED] textopo Hamish Moffatt [EMAIL PROTECTED] gnucap Tommaso Moroni [EMAIL PROTECTED] opensched
Re: gfdl gcc documentation packages for non-free: update
[EMAIL PROTECTED] (Marco d'Itri) wrote: On Sep 23, Matthias Klose [EMAIL PROTECTED] wrote: As long as the source is available in the package this is not a bug at all. - even if the build infrastructure is missing how to build the manpages, it's no bug? If they can be manually built only using software in Debian then it's not a bug. I'd say it's still a wishlist bug. Something to remember, for example, in case you're talking to upstream about documentation issues. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: transitioning config files between two packages
Hi Steve,
maybe you've missed that question to you in a conversation we had on
-devel. Can you please have a look?
Regards, Fr'Fullquote follows'ank
Frank Küster [EMAIL PROTECTED] wrote:
Frank Küster [EMAIL PROTECTED] wrote:
Steve Langasek [EMAIL PROTECTED] wrote:
Yes, you're right that this code unconditionally uses the user's version of
the conffile when moving it, instead of allowing the conffile question to
happen.
The way to get the conffile prompt for a user-modified file is
Hm, I've tried to write that up in the Wiki, but I found that I don't
completely understand what you wanted. You wrote:
,
| The way to get the conffile prompt for a user-modified file is to move the
| old version of the conffile to the new location in the preinst if the old
| conffile md5sum doesn't match the current conffile md5sum for the package.
| Since the earlier preinst code has already removed any old versions of the
| file that are known to be unmodified, this won't give any undesirable
| conffile prompts.
`
Thus far, it seems clear to me. We just need to change the preinst code
from the Wiki:
prep_mv_conffile() {
CONFFILE=$1
+ NEWCONFFILE=$2
if [ -e $CONFFILE ]; then
md5sum=`md5sum \$CONFFILE\ | sed -e \s/ .*//\`
old_md5sum=`sed -n -e \/^Conffiles:/,/^[^ ]/{' $CONFFILE'{s/.*
//;p}}\ /var/lib/dpkg/status`
if [ $md5sum = $old_md5sum ]; then
rm -f $CONFFILE
+ else
+ mv $CONFFILE $NEWCONFFILE
fi
fi
}
Now I thought that is all that needs to be done: Simply ship the
conffile, and now dpkg will
- simply install it if prep_mv_conffile has found the old one unchanged
and removed it
- ask the desired conffile prompt if prep_mv_conffile has found it
changed and already moved to the new place.
Now all that's missing is that dpkg probably still things that the old
package is in state rc, with the conffile at the old place
registered. But that's nothing a maintainer script can solve[1].
However, you (Steve) continued:
,
| Then, if dpkg's stored md5sum for the old conffile *does*
| match that of the current shipped conffile (which you'll know because you
| still have the conffile present in the old location in the postinst), you
| would go ahead with this same code in the postinst to move it into place
| silently.
`
As explained above, I don't understand why any more code is needed at
all. Second, all this has been done in preinst already: compare md5sums
(although not with the current shipped one), move into place.
What am I missing?
Regards, Frank
[1] manually calling aptitude purge or dpkg --purge on packages in
rc is something that helps here. But this possibility means that it is
in fact desirable to rename conffiles when they are taken over by other
packages. Otherwise you can't write Transitional package. This can
savely be removed..., since people will probably understand that as or
purged.
--
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)
Bug#389394: O: netenv -- Configure your system for different network environments
Package: wnpp Severity: normal I hereby orphan netenv. I do no longer use it, and my limited time does not allow properly maintaining it. It's unique feature, compared to other packages for managing a laptop in different network enviroments, is that it does not at all try to detect anything automatically: All is in the hands of the person sitting at the keyboard while booting. Because of this unique feature, I think it deserves being maintained. It's completely written in shell (bash, actually). Upstream exists and responds to e-mail (with long delays), but upstream development is very slow - there are simply not many improvements to make. Some Debian-specific improvements I made, however, where rejected upstream, so there are some differences in how the script acts. The new maintainer should be willing to maintain these parts, too. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: non-free artwork in main
Bastian Venthur [EMAIL PROTECTED] wrote: How can I make sure that my packages are really clean? Is there a best-practice solution for situations like this? Should artwork be generally considered non-free to avoid violations (even when it contains free stuff)? I think in order to have artwork in main, you have to trust upstream to properly care about their licensing. So if there's a package that contains 5 or 50 icons for itself, created by the upstream authors' team, I see no problem including it (for example, the icons in GNU Emacs, Gnus, etc.). With a collection of literally thousands of icons, I think it would be really hard. Except maybe if the upstream distributor requires the people who provide artwork to agree to a free licensing before they are allowed to upload. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Bug#389598: ITP: xpbiff -- animated mail monitor on X with popup notification
James Vega [EMAIL PROTECTED] wrote: On Tue, Sep 26, 2006 at 07:29:05PM +0200, Gernot Salzer wrote: Copyright: * xpbiff - popup biff for X * * Author: Kazuhiko Shutoh, 1993 * * Permission to use, copy, modify and distribute without charge this software, Doesn't the 'without charge' bit violate DFSG #1? If it is meant as it is written, yes. Often sentences like this can also be read as Permission, without charge, to use, copy, But in this particular case the without charge seems to be quite clearly associated with distribute. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Debian Women Wiki
Marc Haber [EMAIL PROTECTED] wrote: On Fri, 29 Sep 2006 00:52:05 +0200, [EMAIL PROTECTED] wrote: http://women.debian.org/wiki/English/MaintainerScripts states, while discussing the purging of a fully installed package (Removing and Purging, Removal+Purge of foo (Installed)), that This is important information I would never have found due to the lack of knowledge that the Debian Women project has her own wiki. May I ask why information this important is not on the main Debian wiki, wiki.debian.org? Or why it is in a Wiki at all? A wiki is fine for collecting information with input from many people. But once it's settled, and this one mainly seems to be, I think it should be integrated in the existing infrastructure, e.g. the developers' reference. At the very least, there should be a very restricted set of entry points (like http://www.debian.org/devel/, the developers' reference, maybe one or two more) which allows to find relevant information. With Wikis, it's soon getting very hard to search or keep an overview of what exists. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: ITP: adun.app -- a Molecular Simulator
Gurkan Sengun [EMAIL PROTECTED] wrote: On 2006-08-31 13:24:21 +0200 Steffen Joeris [EMAIL PROTECTED] wrote: Hi On Thursday 31 August 2006 01:58, Gürkan Sengün wrote: Package: wnpp Severity: wishlist * Package name: adun.app Maybe I miss some essential parts, but I always wonder why some people add a .app to the software name? Can you please give me a short explanation or point me to a previous thread? they don't. it's just the debian packages that do. to not rape the debian package name space. That's a worthwile goal. please check the mailing list archive for details. why, are you having a problem with the names? I think this is also already in the archives: To the knowing, the .app suffix indicates that it is a Gnustep application. To everyone else, .app is pretty much meaningless. Therefore I'd prefer if you'd use a suffix with a less arcane meaning, like -gnustep. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: ITP: adun.app -- a Molecular Simulator
Miles Bader [EMAIL PROTECTED] wrote: Frank Küster [EMAIL PROTECTED] writes: .app is pretty much meaningless. Therefore I'd prefer if you'd use a suffix with a less arcane meaning, like -gnustep. Does anyone truly care? Is it worth any effort to rename? It's an ITP, why not do it better with new packages? Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: [EMAIL PROTECTED]
Maarten Verwijs [EMAIL PROTECTED] wrote: Since this is an ongoing problem, how about the following: [EMAIL PROTECTED] We already have the users lists. What could be possible if Debian had an official Helpdesk Department? * End-Users could ask *any* question and actually get a nice answer. * End-Users can report bugs, but these are first checked by helpdeskers, before they are commited. * Bugreports would end up more specific and detailed * Developers would only have to communicate with Knowledgeable Helpdesk Users. Also developers are only users of packages if they have no idea of the internals. The degree of specificity and detail in bugreports to the TeX package that we get does not at all seem to depend on developer status, but rather on whether the person has knowledge about TeX and its internals (e.g. what generating a format means, a frequent problem when a postinst fails). And I guess the bug reports I make against firefox or that I would make against mysql (never found one so far) aren't or wouldn't be any better. What might a good helpdesk need? * Good software (Request Tracker anyone?) So we get a BTS and a first-level-Request Tracker? Tis just an idea, and it may have it's do's and don't's, so please: what are the general thoughts on this? I guess what we should do is rather improve the users' lists. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Public discussion time for Creative Commons 3.0 license draft coming to a close
Evan Prodromou [EMAIL PROTECTED] wrote: So, for those of you who want to see Creative Commons licenses that meet our standard of Freedom, this is the time to act. Please, if you haven't already, take a few minutes to send an email message to the Creative Commons public review mailing list [6] letting CC know that you support a Debian-compatible version of the license. I want a Debian-compatible Creative Commons license, signed John Q. Hacker is probably plenty. It seems too many have tried this. I just got this answer: You are not allowed to post to this mailing list, and your message has been automatically rejected. If you think that your messages are being rejected in error, contact the mailing list owner at [EMAIL PROTECTED] Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: [EMAIL PROTECTED]
Maarten Verwijs [EMAIL PROTECTED] wrote: Hi Frank, First off: Thanks for thinking this through and answering. On Tue, Oct 03, 2006 at 09:33:52AM +0200, Frank K?ster wrote: Maarten Verwijs [EMAIL PROTECTED] wrote: Since this is an ongoing problem, how about the following: [EMAIL PROTECTED] We already have the users lists. The users-lists do provide a lot of the functions of a helpdesk. They also miss a few things a good helpdesk has: * Prioritization: Important issues will get addressed first. Unimportant issues will still get addressed, only later. This is a problem, but it's generally hard to solve with volunteers, since everybody does what pleases them most. If you care for a particular package, that's a reason to prioritize even unattractive tasks, but at a help desk? And to the extent that such a thing could be done at a helpdesk, I'd suspect that it's also possible on user lists, if we try to put some structure on them (like setting a topic, identifying people who are specifically entitled to request a subject change or do other meta-things). * Commitment to report bugs after prying the end user for all the information he has available. At least in the german users' list which I often read, there's quite a hard pressure to report bugs. And if people claim to not be able to write english well enough, someone else often steps in. * Status within the official Debian hierarchy (status is a reward. Rewards generate motivation). That could also be done if people fulfill their role on the lists. * A single point of entry for questions. Ubuntu (and others) have official forums. We'll have an official mailbox. So you want to force the people to contact the english helpdesk? No localization? Or instead, where's the difference here between a helpdesk per (active) language and a user list per (active) language? What could be possible if Debian had an official Helpdesk Department? * End-Users could ask *any* question and actually get a nice answer. You are dreaming. Or do you have funds to spend^W^Wfor corrupting the project? ;-) * End-Users can report bugs, but these are first checked by helpdeskers, before they are commited. * Bugreports would end up more specific and detailed * Developers would only have to communicate with Knowledgeable Helpdesk Users. Also developers are only users of packages if they have no idea of the internals. I don't see the problem in this. Questions the helpdesk can't answer, they'll pass onto the developer. Questions the developer can't answer, they'll pass onto upstream. If they do not have the time, they could ask the Helpdesk to do this for them. So the developer is going to see most bug reports, anyway, and we're just have one more place for friction and creation of heat. On my packages, the number of bad bug reports is really small. And even these give an opportunity to learn. After all, most packages are supposed to work for newbies, too, so their input is valuable for improving error messages and procedures. Tis just an idea, and it may have it's do's and don't's, so please: what are the general thoughts on this? I guess what we should do is rather improve the users' lists. Possible improvements: * Moderation on the lists * Give moderators a status within debian as an insentive. * Management: if someone is offensive (destructive), take away moderation status. There are things in between not caring at all and moderation. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: [EMAIL PROTECTED]
Bernhard R. Link [EMAIL PROTECTED] wrote: * Maarten Verwijs [EMAIL PROTECTED] [061003 12:32]: * Prioritization: Important issues will get addressed first. Unimportant issues will still get addressed, only later. If someone implement some kind of help-desk, please implement a hook for maintainers to subscribe for problems with their packages. I'd rather have a dozen stupid and/or pointless bug-reports more per week than having any problems of my packages hidden from me in some help-desk tracker because someone deems them not important enough to bring them in a nice form to be submitted to me. (Bonus points for something pts like that also allows upstream maintainers to hook in) Seconded. -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: local copies of libs
Hendrik Sattler [EMAIL PROTECTED] wrote: For some, the reason is acceptable, for some it isn't? So what makes it candidate for a bug report with a severity greater than wishlist? What is the main opinion among Debian maintainers? If there's ever been a security update for the library, or it's likely that a buffer overflow or similar would have security implications, then I think it's definitely more than just wishlist. For example, it's a pain to patch all those (subtly different) versions of xpdf code dispersed throughout Debian on every security update of xpdf. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Troubles with Debconf
Hi, Ps : i know this message has come to debian-mentors, but there, I'm not help. Which for sure does not mean that no one there knows debconf well enough. Rather it seems that you are not able to properly phrase your questions, or maybe not to understand the answers. Please don't bother us, there's a purpose behind separating the lists. Ah, and, btw, *none* of the things you describe is a bug. The first isn't supposed to work without prior usage of debconf-loadtemplates, the second is a typo by you, the third is missing a command on stdin (and tells you that). Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Bug#391246: general: Buildds should consider changing $HOME
Package: general Severity: wishlist general is not the best package to report this to, but since there's no buildd package, and I don't want it to be completely forgotten, I'll report it here. I'm quoting from a bugreport where we came across this, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=388399;msg=123: Steve Langasek [EMAIL PROTECTED] wrote: On Wed, Oct 04, 2006 at 09:32:16AM +0200, Frank Küster wrote: However, I'd like to point out that this problem is not special to TeX. Many programs create ~/.progname directories when run for the first time - and these directories contain configuration options which might cause trouble, since they are not updated or subject to dpkg conffile questions when the package changes configuration options. It might be a good thing to require such tools to have a commandline switch or obey a commandline variable that prevents this. Alternatively, HOME could be set to the temporary build directory, so that everything happens there. Yes, that's true. Setting $HOME to something explicitly nuked by the clean target might be a good general solution. In practice, there are few tools that have broken buildd chroots in the manner that tex seems to have here. Regards, Frank -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (99, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.17-2-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Bug#391342: ITP: jsmath -- TeX equations in HTML documents
Yaroslav Halchenko [EMAIL PROTECTED] wrote: Package: wnpp Owner: Yaroslav Halchenko [EMAIL PROTECTED] Severity: wishlist * Package name: jsmath Version : 3.3e Upstream Author : Davide P. Cervone * URL or Web page : http://www.math.union.edu/~dpvc/jsMath * License : Apache License 2.0 Description : TeX equations in HTML documents The jsMath package provides a method of including mathematics in HTML pages that works across multiple browsers under Windows, Macintosh OS X, Linux and other flavors of Unix. It overcomes a number of the shortcomings of the traditional method of using images to represent mathematics: jsMath uses native fonts, so they resize when you change the size of the text in your browser, they print at the full resolution of your printer, and you don't have to wait for dozens of images to be downloaded in order to see the mathematics in a web page. If you have any problems getting it to work with the TeX fonts already packaged, feel free to ask at [EMAIL PROTECTED] You probably have noticed that the TrueType Fonts they suggest to use are non-free, but the very same fonts are available as MetaFont and Type1 in Debian. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Call for votes for GR: Re-affirm support to the Debian Project Leader
Debian Project Secretary [EMAIL PROTECTED] wrote: - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- a65763d3-b1e2-4530-8ff8-aa5915274eb4 [ 1 ] Choice 1: Re-affirm DPL, wish success to unofficial Dunc Tank [ 1 ] Choice 2: Re-affirm DPL, do not endorse nor support his other projects [ 1 ] Choice 3: Further discussion - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive) pgpJXSfTunveR.pgp Description: PGP signature
Re: Help with menu
Andreas Tille [EMAIL PROTECTED] wrote: On Fri, 29 Sep 2006, Bill Allombert wrote: I suggest a simpler route (untested): command=x-terminal-emulator -e /bin/sh -c \gnumed;echo press any key to continue;read foo\ Note that it does not really solve the dependency on xterm: it merely replaces it on a depdendency on any terminal-emulator. The solution that was suggested by you and Philipp Benner seems to be not aware to lintian W: gnumed-client-debug: menu-command-not-in-package /usr/share/menu/gnumed-client-debug:5 x-terminal-emulator Shouldn't a Depends: xterm | x-terminal-emulator be enough here? I admit that it might be hard to define a lintian rule to verify the contents of dependant packages but I wonder whether I should simply go with a lintian override or file either a wishlist bug against lintian or perhaps menu-policy? I think it wouldn't be too much to hope that lintian knows about the main executables that are provided by virtual packages, so I'd suggest a lintian bug. Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: how to tell people to dpkg-reconfigure exim4-_CONFIG_?
Don Armstrong [EMAIL PROTECTED] wrote: On Tue, 10 Oct 2006, Reinhard Tartler wrote: Cons: Untranslated message Pros: less annoying by not interrupting installs and upgrades, easy to implement Cons: Can't be easily seen in non-console frontends, dissapears off of the screen rapidly, etc. Using echo to inform the user of things is really not ideal. README.Debian, NEWS.Debian, and low priority debconf notes when appropriate are much, much better. In that case, where the problem is that people do *not* read these files, and dpkg-reconfigure exim4 exits silently without doing anything, it seems to be ideal. Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Bug#391246: general: Buildds should consider changing $HOME
Ian Jackson [EMAIL PROTECTED] wrote: On Wed, OcFt 04, 2006 at 09:32:16AM +0200, Frank Küster wrote: However, I'd like to point out that this problem is not special to TeX. Many programs create ~/.progname directories when run for the first time - and these directories contain configuration options which might cause trouble, since they are not updated or subject to dpkg conffile questions when the package changes configuration options. It might be a good thing to require such tools to have a commandline switch or obey a commandline variable that prevents this. Alternatively, HOME could be set to the temporary build directory, so that everything happens there. It seems to me that a package build should not * depend on $HOME not containing reasonable settings * change anything in $HOME If the package runs some program which spews droppings all over $HOME, or which might malfunction if the user has an unusual personal configuration, then it should set $HOME itself. Yes, that's the ideal solution. In the real world, my suggestion may improve the situation faster. Just got an other idea, slower too, but makes the ideal solution more realistic: Someone writes a tool analogous to piuparts, but not for install/upgrade, but for package building. This tool would check whether any tool used in the build process does nasty things, like accessing $HOME, communicating over the network, assuming existence of particular files in /sys or /proc, and the like. (No, I'm not qualified to write such a tool) Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Bug#391246: general: Buildds should consider changing $HOME
Mike Hommey [EMAIL PROTECTED] wrote: On Wed, Oct 11, 2006 at 07:55:54AM +0200, Frank Küster [EMAIL PROTECTED] wrote: Yes, that's the ideal solution. In the real world, my suggestion may improve the situation faster. Just got an other idea, slower too, but makes the ideal solution more realistic: Someone writes a tool analogous to piuparts, but not for install/upgrade, but for package building. This tool would check whether any tool used in the build process does nasty things, like accessing $HOME, communicating over the network, assuming existence of particular files in /sys or /proc, and the like. Something similar should be done with package installations... I hate that my /root is cluttered with .gconf, .anthy, .gnome, .gnupg, .qt ... while I never run that kind of software as root... This could be done inside piuparts, couldn't it? Or isn't that kind of behavior already checked, since piuparts complains about all leftover files on the system? Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Bug#391246: general: Buildds should consider changing $HOME
Wouter Verhelst [EMAIL PROTECTED] wrote: Steve Langasek [EMAIL PROTECTED] wrote: On Wed, Oct 04, 2006 at 09:32:16AM +0200, Frank Küster wrote: However, I'd like to point out that this problem is not special to TeX. Many programs create ~/.progname directories when run for the first time - and these directories contain configuration options which might cause trouble, since they are not updated or subject to dpkg conffile questions when the package changes configuration options. It might be a good thing to require such tools to have a commandline switch or obey a commandline variable that prevents this. Alternatively, HOME could be set to the temporary build directory, so that everything happens there. Even more alternatively, these tools should not fail horribly when writing to directories in $HOME seems impossible for some reason. That falls under 'standard good programming practices'. This misses the point. Of course no build process may fail if writing to $HOME is impossible, and if they do they have a RC bug. There's a different issue, though: Many tools create a user-specific configuration or preferences directory in $HOME when they are first used. The problem with that is that these files override the configuration in /etc/, but are not subject to dpkg conffile handling. As a result, a tool on a buildd might use settings that were the default in a previous version, but are now suboptimal. Of course the clean solution would be to signal to the tools not to look and write into HOME, but it's hardly realistic to assume that all tools used (an ever increasing and changing set) will always follow such a rule. Therefore the idea to change HOME to something in the build directory. Maybe just unsetting it might do as well. Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Bug#391246: general: Buildds should consider changing $HOME
Wouter Verhelst [EMAIL PROTECTED] wrote: On Wed, Oct 11, 2006 at 07:40:42AM +0200, Frank Küster wrote: Of course the clean solution would be to signal to the tools not to look and write into HOME, but it's hardly realistic to assume that all tools used (an ever increasing and changing set) will always follow such a rule. Therefore the idea to change HOME to something in the build directory. Maybe just unsetting it might do as well. The default configuration on buildd is to set $HOME to a directory that does not exist... Not on the alpha, mips and mipsel buildds that revealed our bug, http://bugs.debian.org/388399. If the buildds consequently set HOME to a nonexistent directory, this would solve this bug as well, but they don't currently. That's why this bug is open. Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: how to tell people to dpkg-reconfigure exim4-_CONFIG_?
Marc Haber [EMAIL PROTECTED] wrote: On Tue, 10 Oct 2006 22:05:07 +0200, Frank Küster [EMAIL PROTECTED] wrote: In that case, where the problem is that people do *not* read these files, and dpkg-reconfigure exim4 exits silently without doing anything, it seems to be ideal. Explain that please. I just imagined someone doing # dpkg-reconfigure exim4 # compared to # dpkg-reconfigure exim4 Please use dpkg-reconfigure exim4-config instead! # However, although this looks simple and short, it doesn't take into account the various possible ways to access debconf, and it won't work at all if a package manager has a reconfigure this package button. Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: delay of the full etch freeze
Steve Langasek [EMAIL PROTECTED] wrote: According to http://ftp-master.debian.org/new.html, the oldest package in NEW is 3 weeks old. 3 weeks ago was more than a full month after the original proposed base freeze date for etch[1]. That might be misleading, because the date is reset when you do a new upload. The two packages that were oldest for a while (latex-cjk and friends, now they are processed) have been in there for nearly a month, but then we made an upload that only changed the maintainer e-mail address, and they suddenly looked young... Sorry, no, I'm not going to lose any sleep over such packages not making it into etch before the freeze. I agree. Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: mucking with dpkg control files in maintainer scripts?
Goswin von Brederlow [EMAIL PROTECTED] wrote:
Tollef Fog Heen [EMAIL PROTECTED] writes:
* sean finney
| is this even remotely acceptable? i had the impressions that packages
| must not assume the inner workings of dpkg. but, i can't back this up
| with anything in policy from what i can tell, hence the posting of
| this question.
Before responding, please read the bug report (390823) mentioned in
the changelog. Oh, and if we deem this unacceptable, please do
suggest a different way and file bugs on a lot of the archive,
including all doing stuff like:
[...]
old_md5sum=`sed -n -e \/^Conffiles:/,/^[^ ]/{' $CONFFILE'{s/.*
//;p}}\ /var/lib/dpkg/status`
[...]
I think this is different from messing with the maintainer
scripts. But none the less I think a better way for this would be to
call 'dpkg -s package'.
I think the main reason why this is not being done is that there's a
general fear that calling dpkg -s from a script that has been called
by dpkg might give unpredictable, or at least not the desired results.
If it were documented how dpkg behaves under such circumstances (same
for dpkg -l), people might be willing to change this.
Regards, Frank
--
Dr. Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)
Re: Bug#393317: ITP: teamspeak-client -- Very good Voice Chat
Ron Johnson [EMAIL PROTECTED] wrote: On 10/15/06 22:01, Adam Cécile (Le_Vert) wrote: Package: wnpp Severity: wishlist Owner: Adam Cécile (Le_Vert) [EMAIL PROTECTED] * Package name: teamspeak-client Version : 2.0.32 Upstream Author : TeamSpeak Systems [EMAIL PROTECTED] * URL : http://www.goteamspeak.com/ * License : non-free Description : Very good Voice Chat [...] This software is not free at all. Binaries will works on i386 and seems to work fine on amd64 with ia32-libs. From the EULA: You will not, and will not permit others to: (i) reverse engineer, decompile, disassemble, derive the source code of, modify, or create derivative works from the Software; or (ii) use, copy, modify, alter, or transfer, electronically or otherwise, the Software or any of the accompanying documentation except as expressly permitted in this Agreement; or (iii) redistribute, sell, rent, lease, sublicense, or otherwise transfer rights to the Software whether in a stand-alone configuration or as incorporated with other software code written by any party except as expressly permitted in this Agreement. Isn't this against everything the DFSG stands for? That's irrelevent: If you read the ITP, it's clear that Adam is already aware of this, and wants to package it for non-free, to which the DFSG, naturally, does not apply. However, the text of the EULA sounds as if we are not even allowed to redistribute it in non-free, and that's the important point. Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Lack of transparency of automatic actions
Hendrik Sattler [EMAIL PROTECTED] wrote: Even worse, you again have to use KDE or Gnome to take advantage of network-manager. Why are we leaving CLI users out in the cold? Good question. The concept for a cli like this would need many thoughts, though. A GUI makes that a bit easier. It's not (KDE or GNOME) vs. CLI. I usually work under X, but I don't use a Desktop Environment. I use some of the GUI tools they offer, but it's always unclear to me to what extent this is expected to work at all, and which side effects it may have (like creation of stuff called icons on my desktop background, if I use the wrong WindowManager, or useful subdirectories below $HOME). Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
building non-free packages on debian.org machines? (was: [Help] Please compile clustalw on architectures ia64, mips, mipsel, s390 and m68k)
Petter Reinholdtsen [EMAIL PROTECTED] wrote: [Charles Plessy] Clustal W and Clustal X are the most popular software for multiple alignment of biological sequences. Their source package was NMUed during the lesstif transition, but not built on enough architectures, and was therefore removed from testing. http://packages.qa.debian.org/c/clustalw.html Ah, the pain with no autobuilders for non-free packages. You will have to find a developer with access to all of the architectures ia64, mips, mipsel and s390 (m68k is ignored), and get them to build binaries of the package. Am I correct that it's not appreciated to build the package on the debian.org machines? Unfortunately, this is kind of unclear in the Machine Usage Policy. The only thing that comes near is , | Avoid running processes that are abusive in CPU or memory. If | necessary the DSA's will reap up such processes without warning. ` Of course in many cases it would be needed to ask the DSA people to install the required build-deps, but before I ask I'd rather know whether it's allowed at all. Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: [Help] Please compile clustalw on architectures ia64, mips, mipsel, s390 and m68k
Petter Reinholdtsen [EMAIL PROTECTED] wrote: What about convincing the upstream developers to change the license to one of the free software licenses? It would solve the problem for good. Judging from the mail recorded in its copyright file, this isn't likely to happen. Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: [Help] Please compile clustalw on architectures ia64, mips, mipsel, s390 and m68k
Wouter Verhelst [EMAIL PROTECTED] wrote: On Tue, Oct 17, 2006 at 02:38:49PM +0200, Andreas Tille wrote: [...] Just read the mails of these both threads and learn why we have not yet autobuilders for non-free. IMHO the main issue is that nobody really _did_ it. There are two issues at hand that explain why there is no non-free autobuilder: * Most people who could set up one (because they have the hardware and the skillz) do not want to [...] * Packages in main are required to be DFSG-free [...] Therefore, anyone interested in building non-free would need to maintain a list of packages that do not have such problematic restrictions. TTBOMK, this has not happened. This is nothing new, it has already been discussed in the thread Andreas referenced. Something new would be an answer to my question whether it's acceptable to build non-free packages on the Debian machines. Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Looking for Debian Packaging expert
Kevin Mark [EMAIL PROTECTED] wrote: On Tue, Oct 17, 2006 at 04:26:04PM -0700, Mahmood Sheikh wrote: Hi all, I work for ACCESS, Inc. here in Sunnyvale, California. We are looking for someone who is adept in Debian Packaging. This person would deliver 3 or 4 hourly sessions to our employees just to educate them on benefits of using Debian Packaging and answer any questions that our employees (internal developers) might have. It would not be training sessions but it would be semi technical talks on how to use and deploy Debian packages mechanism and discussing the advantages of using Debian packages for distribution of software internally. Regards, Hi Mahmood, thanks for considering Debian! your employees can browser the Debian.org web site for information about packaging. I don't think that this will help Mahmood very much. But nobody so far has pointed out two interesting points of information: - There's a debian-jobs mailing list which has been created specifically for such offers. Mahmood, you should probably resend your request to that list - I think there used to be a list of companies that provide Debian support and training, but I can't find it - can somebody help? Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Looking for Debian Packaging expert
Bas Zoetekouw [EMAIL PROTECTED] wrote: Hi Frank! You wrote: - I think there used to be a list of companies that provide Debian support and training, but I can't find it - can somebody help? Did you mean this list? http://www.us.debian.org/consultants/ Yes - yow do I get to it from the main page? TIA, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Looking for Debian Packaging expert
Martin Michlmayr [EMAIL PROTECTED] wrote: * Frank Küster [EMAIL PROTECTED] [2006-10-18 13:03]: Did you mean this list? http://www.us.debian.org/consultants/ Yes - yow do I get to it from the main page? debian.org - Support - Consultants - Consultants Ah. I find it misleading that it looks as if the items below Support on the main page are a submenu, while in fact they are just a subset of the things you can find when you klick on support. Well, what's the opposite of once upon a time, in the future? Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: gcc-4.2 build-depends?
Jiri Palecek [EMAIL PROTECTED] wrote: Hello, can anyone explain why gcc-4.2 build-depends on libgconf2-dev, libxul-dev, libart-2.0-dev, libgtk2.0-dev, lib32asound2-dev, libcairo2-dev, libqt4-dev and several others? It seems quite strange (well, even more) to me. Well, it builds a couple of binary packages that might well need such libraries. Without looking at the source, names like gappletviewer-4.2 Standalone application to execute Java (tm) applets gcjwebplugin-4.2 Web browser plugin to execute Java (tm) applets sound like good candidates. Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Bug mass filling
Mike Hommey [EMAIL PROTECTED] wrote: On Thu, Oct 19, 2006 at 10:20:46PM +0200, Andreas Barth [EMAIL PROTECTED] wrote: * Mike Hommey ([EMAIL PROTECTED]) [061019 22:09]: Where does it say the scope for 4. Autobuilding is buildds must not fail ? There are always bugs in any document. Be aware that, even if you don't like it, this looks like you bend the rules so that it doesn't alter the release plan. Be also aware that too much bending the rules makes them useless. What about your proposing a GR to recall the Release Managers? Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: gcc-4.2 build-depends?
[EMAIL PROTECTED] wrote: Hello, Frank Küster napsal: Jiri Palecek [EMAIL PROTECTED] wrote: Hello, can anyone explain why gcc-4.2 build-depends on libgconf2-dev, libxul-dev, libart-2.0-dev, libgtk2.0-dev, lib32asound2-dev, libcairo2-dev, libqt4-dev and several others? It seems quite strange (well, even more) to me. Well, it builds a couple of binary packages that might well need such libraries. Without looking at the source, names like gappletviewer-4.2 Standalone application to execute Java (tm) applets gcjwebplugin-4.2 Web browser plugin to execute Java (tm) applets sound like good candidates. I don't think this is, er... wise. This means if I want to make a (cross-)compiler, I have to install Qt, GNOME, XUL (which conflicts: mozilla-browser) even if I'll never want to use java. No, you haven't. The Build-Depends of a Debian package are not meant to be used for bootstrapping. You could just disable the respective stanzas in the control file, build your cross-compiler or compiler for a new architecture, and once you managed to build Qt and Gnome, you can enable them again. Also, any RC-bug in these will make gcc not suitable for testing. I think the same arguments as in Bug#360881 apply here. Also, the same solution should be used (eg. split the package). This, however, is a strong argument. Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: mucking with dpkg control files in maintainer scripts?
Ian Jackson [EMAIL PROTECTED] wrote: Frank Küster writes (Re: mucking with dpkg control files in maintainer scripts?): I think the main reason why this is not being done is that there's a general fear that calling dpkg -s from a script that has been called by dpkg might give unpredictable, or at least not the desired results. If you need this information, dpkg -s is a better way to get it than messing around with /var/lib/dpkg - but see my earlier message. Messing with conffiles is _very complicated_ and doing so by hand in maintscripts is likely to produce more subtle and complicated bugs rather than fewer bugs. If it were documented how dpkg behaves under such circumstances (same for dpkg -l), people might be willing to change this. Where is this documentation you refer to ? It is nowhere AFAIK, and this is the problem. dpkg -s and dpkg -l are equally reliable in this respect. In other words, commits to the dpkg database are atomic, and if dpkg is called from a script started by dpkg, it will report all packages in the correct, current and maybe partial state, including the package processed so far? Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Getting rid of circular dependencies, stage 6
Don Armstrong [EMAIL PROTECTED] wrote: On Tue, 24 Oct 2006, Petter Reinholdtsen wrote: [Ian Jackson] The only argument I've heard against circular dependencies as a general rule is that they can trigger a particularly stupid (and probably not very hard to fix) bug in apt, You seem to have missed the argument that packages with circular dependencies are impossible to install and configure in the correct (dependency) order, and thus will end up being installed and configured in a nondeterministic order instead. It is documented that dpkg try its best to find a sensible order for the packages, but it is bound to fail one way or another if two packages really do need each other to be configured before they are configured. Packages which have circular dependencies and depend on the other package being configured are buggy; at most they can depend on the other package being unpacked. Since there is no way to specify this kind of dependency, Depends: is as close as you can get. It seems to me that the solution in such situation shouldn't be a circular dependency with its nondeterministic behavior, but instead to separate one of the packages into two. For example if package b needs package a unpacked, but not configured, separate package a in a-data and a-therest, where a-data provides all that package b needs: Now b can depend on a-data, and a-therest can depend on b. Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
should, ought, must (was: Bug mass filling)
Manoj Srivastava [EMAIL PROTECTED] wrote: On Tue, 24 Oct 2006 17:15:55 -0700, Steve Langasek [EMAIL PROTECTED] said: Is the word generally here an error? I read this as implying the normal meaning of should -- that not everything which violates a should mandate is a bug. I am of the opinion that it is. We can replace non-buggy instances of should by 'ought to be', if needed. But please don't forget a legal definition of those terms. For me, as a non-native speaker, I have no idea whether ought to is weaker or stronger than should, or just something different (and what). Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Bug mass filling
Manoj Srivastava [EMAIL PROTECTED] wrote: On Tue, 24 Oct 2006 16:04:54 -0700, Steve Langasek [EMAIL PROTECTED] said: Because your choice of mapping blurs the distinction between one-time exceptions for RCness (e.g., due to GRs for DFSG issues), vs. policy violations that the release team does not believe should be promoted to RC status at any time in the foreseeable future. etch-ignore is most useful as a tag if its use is restricted to those bugs whose *non*-release-criticality is transient in nature -- the alternative is that the release team is stuck going through the BTS after each release and re-adding new tags to those bugs about policy violations whose severity does not justify exclusion from the release. That does not make sense. After etch is released, etch-ignore tags are no-ops -- so there is no need to go back and untag anything. The work would be to change the tag to whatever-ignore. And if there are anyissues that are policy must directives that the release team has take upon itself to say are policy directives it is not worth following, then they should file important bugs against polocuy to either have the requirements removed, or the issue resovled by the tech ctte. I don't like your wording of not worth following. A policy dictum might well be important to follow, but non-conformance may still (always or in particular cases) not be a reason to exclude it from the release. But you're of course right that Policy and the release-policy should be synchronized... Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: First draft of review of policy must usage
Raphael Hertzog [EMAIL PROTECTED] wrote: I understand we need to make concessions towards a release (like concentrating on fixing bugs instead of introducing new major upstream changes) but it shouldn't block Debian's progress in all areas. You must understand that if Manoj is not fixing the policy, he probably won't use that time to fix RC bugs. That's quite correct, but it seems strange that resynchronizing of two documents takes place while the group who authored one of them is too busy to take part in that process. I would hope that in this process, not only policy is improved, but also the release-policy (if not in meaning then at least in wording and clearness), but we can't expect this to happen right now. Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: First draft of review of policy must usage
Manoj Srivastava [EMAIL PROTECTED] wrote: Is there any harm in refining the changes and building consensus over time? The change document can exist as a talking point, and you can still come in and provide us your input when you have time (post etch). Personally, I would see it as a waste of time to take part in a discussion in which one of the involved parties is not involved (due to time constraints). And that's going to be my last public mail about this topic... Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Bug#403770: ITP: context -- A powerful TeX format
Norbert Preining [EMAIL PROTECTED] wrote: Package: wnpp Severity: wishlist Owner: Norbert Preining [EMAIL PROTECTED] * Package name: context Version : 2006.12.17 Upstream Author : Hans Hagen * URL : http://www.pragme-ade.com * License : GPLv2 Programming Lang: TeX Description : A powerful TeX format Fine :-) ConTeXt is a typographical engine written in the typographical computer language TeX. ConTeXt provides you with a convenient way to encode documents in a structured way and to typeset these documents in various ways on paper, computer screen or web site. Use ConTeXt to create simple documents and complex layouts. To me this long description sounds too much like marketing blurb and has little information content. The most important question that it should answer is what's the difference to the more known LaTeX? Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Upgrade Experiences (27 Sarges - Etch, and counting)
Maarten Verwijs mverwijs at farwise.org writes: A small list of software installed (before upgrade): [...] - Tetex You could give texlive a try. It's more up-to-date than teTeX, it's more comprehensive, and it's going to be the default for lenny, anyway. Unfortunately, there are still a couple of packages that only depend on teTeX and cannot be installed with TeXLive - in most cases, there are updated packages available at tug.org, please read http://www.tug.org/texlive/debian.html Regards, Frank -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#584013: hyperlatex: Security bugs in ghostscript
Romain Beauxis romain.beau...@gmail.com wrote: Le mardi 1 juin 2010 12:12:23, Romain Beauxis a écrit : I am not closing but downgrading for mediawiki, unless you prove that there is a real security issue. Ok, I have looked at the source code. We use dvips to generate the postscript file. Does the issue happen for dvips ? dvips does not use gs - it creates input for gs. Regards, Frank -- Dr. Frank Küster Debian Developer (TeXLive) VCD Aschaffenburg-Miltenberg, ADFC Miltenberg B90/Grüne KV Miltenberg -- 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/87631zdej2@alhambra.kuesterei.ch
Re: svn.debian.org ???
Norbert Preining prein...@logic.at wrote: Aehmm, did I miss something ...? $ svn commit ... Transmitting file data .svn: Commit failed (details follow): svn: Can't create directory '/svn/debian-tex/db/transactions/4856-1.txn': Read-only file system svn: Your commit message was left in a temporary file: svn:'/src/TeX/debian/svn/context/svn-commit.tmp' $ I am connecting via ssh with my DD user id to svn.debian.org??? Maybe it has something to do with the changes to alioth? Here it works with k$ svn info Path: . URL: svn+ssh://fr...@svn.debian.org/svn/debian-tex/texlive2009/trunk Repository Root: svn+ssh://fr...@svn.debian.org/svn/debian-tex Repository UUID: c7d1d271-d7fa-0310-821e-d5ace5ea27af Revision: 4853 Node Kind: directory Schedule: normal Last Changed Author: hilmar-guest Last Changed Rev: 4841 Last Changed Date: 2011-05-10 18:09:45 +0200 (Di, 10 Mai 2011) Regards, Frank -- Frank Küster Sprecher B90/Grüne OV Miltenberg und Umgebung VCD Miltenberg, ADFC Aschaffenburg-Miltenberg Debian Developer (TeXLive) -- 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/87oc1weu6k@alhambra.kuesterei.ch
Debconf syntax error message that I don't understand
Hi,
I am at a loss with shell script that uses debconf. The script itself
is in /etc/libpaper/, but since it is often called from maintainer
scripts, it uses debconf.
The problem is that debconf says it didn't get the right number of
arguments, but I think it did. This is the relevant line of code:
db_subst texlive-base/texconfig_ignorant binary $binary
and this is what debconf says:
+ db_subst texlive-base/texconfig_ignorant binary dvipdfmx
+ _db_cmd SUBST texlive-base/texconfig_ignorant binary dvipdfmx
+ IFS= printf %s\n SUBST texlive-base/texconfig_ignorant,binary,dvipdfmx
+ IFS=
read -r _db_internal_line
debconf (developer): -- SUBST texlive-base/texconfig_ignorant,binary,dvipdfmx
debconf (developer): -- 20 Incorrect number of arguments
+ RET=20 Incorrect number of arguments
+ return 20
The check in ConfModule looks like this:
sub command_subst {
my $this = shift;
return $codes{syntaxerror}, Incorrect number of arguments if @_ 2;
So why does it think it has less than two arguments when what it gets is
texlive-base/texconfig_ignorant,binary,dvipdfmx
I even tried to feed it an additional foo at the end, but that doesn't
change anything. Probably I'm missing something trivial...
Regards, Frank
P.S. Script at
http://anonscm.debian.org/viewvc/debian-tex/texlive2009/trunk/texlive-base/debian/texlive-base.libpaper?view=log
--
Frank Küster
Sprecher B90/Grüne OV Miltenberg und Umgebung
VCD Miltenberg, ADFC Aschaffenburg-Miltenberg
Debian Developer (TeXLive)
--
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/87pqlgv4wt@alhambra.kuesterei.ch
Re: Debconf syntax error message that I don't understand
Joey Hess jo...@debian.org wrote: Your script is setting IFS=, Yes, indeed. All you need to do to fix it in your script though is to restore IFS before you start talking to debconf. Doesn't work, unfortunately: # now get rid of the commas by assigning to the positional parameters set -x OLD_IFS=$IFS IFS=', ' set $ListOfBinariesToUseLibpaper IFS=$OLDIFS for binary in $@; do if texconfig-sys $binary paper $LibpaperPaper; then # all is well : else db_subst texlive-base/texconfig_ignorant binary $binary Results in + OLD_IFS= + IFS=, + set pdftex dvips dvipdfmx xdvi + IFS= + texconfig-sys pdftex paper Monarch debconf (developer): -- X_LOADTEMPLATEFILE /var/lib/dpkg/info/ucf.templates ucf debconf (developer): -- 0 debconf (developer): -- X_LOADTEMPLATEFILE /var/lib/dpkg/info/ucf.templates ucf debconf (developer): -- 0 + : + texconfig-sys dvips paper Monarch debconf (developer): -- X_LOADTEMPLATEFILE /var/lib/dpkg/info/ucf.templates ucf debconf (developer): -- 0 + : + texconfig-sys dvipdfmx paper Monarch texconfig: unknown PAPER `Monarch' given as argument for `texconfig dvipdfmx paper' texconfig: try `texconfig dvipdfmx paper' for help + db_subst texlive-base/texconfig_ignorant binary dvipdfmx + _db_cmd SUBST texlive-base/texconfig_ignorant binary dvipdfmx + IFS= printf %s\n SUBST texlive-base/texconfig_ignorantbinarydvipdfmx + IFS= read -r _db_internal_line debconf (developer): -- SUBST texlive-base/texconfig_ignorantbinarydvipdfmx debconf (developer): -- 20 Incorrect number of arguments + RET=20 Incorrect number of arguments + return 20 dpkg: error processing texlive-base (--configure): subprocess installed post-installation script returned error exit status 20 Errors were encountered while processing: texlive-base With IFS=' ' it works, but that doesn't look right? Regards, Frank -- Frank Küster Sprecher B90/Grüne OV Miltenberg und Umgebung VCD Miltenberg, ADFC Aschaffenburg-Miltenberg Debian Developer (TeXLive) -- 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/87r55vtgh2@alhambra.kuesterei.ch
Re: Debconf syntax error message that I don't understand
Joey Hess jo...@debian.org wrote: Frank Küster wrote: OLD_IFS=$IFS IFS=$OLDIFS s/_// :-( -- Frank Küster Sprecher B90/Grüne OV Miltenberg und Umgebung VCD Miltenberg, ADFC Aschaffenburg-Miltenberg Debian Developer (TeXLive) -- 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/87vcv5syn0@alhambra.kuesterei.ch
Re: Sharing data between maintainer scripts and debian/rules
Neil Williams codeh...@debian.org wrote:
Other than using sed and awk during the build on a package-specific
basis with all the potential for typos, is there a wider use case for
dissemination of variables from debian/rules into maintainer scripts?
In tex-common and texlive-{base,extra,lang,doc}, we use eperl.
debian/rules has a section like this:
# create maintainer scripts etc.
EPERL_FILES := debian/common.functions debian/postinst debian/postrm
debian/config debian/preinst
eperl_sourcefiles=debian/variables debian/COPYRIGHT.scripts
debian/postinst.functions \
debian/common.variables debian/common.functions debian/postrm.functions
# Eperl is simply great: thanks, Davide!
% :: %.in $(eperl_sourcefiles)
eperl -k -P -o $@ $
Then you edit postinst.in, postrm.in and they eperl'ishly include
common.functions, common.variables
You can even have rules.in like this.
The original idea is from Davide Salvetti in his auctex package, but I
wouldn't recommend this any more - the packaging may be aesthetic, but
it is overcomplicated. In particular, newer upstream versions probably
don't need much more than ./configure; make; make install.
Regards, Frank
--
Frank Küster
Sprecher B90/Grüne OV Miltenberg und Umgebung
VCD Miltenberg, ADFC Aschaffenburg-Miltenberg
Debian Developer (TeXLive)
--
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/874nyi5mx5@alhambra.kuesterei.ch
Accepted texlive-bin 2009-11 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Mon, 15 Aug 2011 21:48:13 +0200 Source: texlive-bin Binary: texlive-binaries libkpathsea5 libkpathsea-dev Architecture: source i386 Version: 2009-11 Distribution: unstable Urgency: low Maintainer: Debian TeX Maintainers debian-tex-ma...@lists.debian.org Changed-By: Frank Küster fr...@debian.org Description: libkpathsea-dev - TeX Live: path search library for TeX (development part) libkpathsea5 - TeX Live: path search library for TeX (runtime part) texlive-binaries - Binaries for TeX Live Closes: 637667 637720 Changes: texlive-bin (2009-11) unstable; urgency=low . [ Hilmar Preuße ] * disable the LFS support provided by upstream again, it is really broken (Reopens: #618033). It: - breaks pdflatex on big endian platforms (Closes: #637667) - introduced an ABI change on 32-bit platforms (Closes: #637720) Checksums-Sha1: 47207fd19a887a1132cdf152e7202b713f560554 1391 texlive-bin_2009-11.dsc 1b1f982bf269776ffbbebf9af6c717c244144d95 91228 texlive-bin_2009-11.diff.gz 4970f9d679ee804e930bc78ff23ad8928a8b54ad 7680546 texlive-binaries_2009-11_i386.deb d18eae1892d84efc122bc40ce46220f0fa0c617f 134918 libkpathsea5_2009-11_i386.deb d839b885f1a7fb21dece9323742418cb6a25d7d2 173886 libkpathsea-dev_2009-11_i386.deb Checksums-Sha256: 2c62c5e6fd2a4339961907601254a35986932b32af00c8ee954d551beb6a677d 1391 texlive-bin_2009-11.dsc 59762914e72821ff1eac37672d73af3a488dd3c53f29aa961a94ac7c27f1a81f 91228 texlive-bin_2009-11.diff.gz 9bba0d64a03eafa4f0fd04688f34dd7a4ce65e07679218cda625008a84a75a82 7680546 texlive-binaries_2009-11_i386.deb 87a7bacef9460179345a2a711e42639e5f6b1b0392c6ad3ba93395d076dfa4d4 134918 libkpathsea5_2009-11_i386.deb 91a54015eaf82e045bab8c38a7c871f1819e2adcbfe9f17611a14f23b17e84db 173886 libkpathsea-dev_2009-11_i386.deb Files: d4aa97b75f24ff7b247032f744b53622 1391 tex optional texlive-bin_2009-11.dsc 0af97ce9042b42804b7554b74c1aec69 91228 tex optional texlive-bin_2009-11.diff.gz 271d617e2a12462d69d525eb0715efae 7680546 tex optional texlive-binaries_2009-11_i386.deb 582326ebe9b13a6c70494fe51ff458c7 134918 libs optional libkpathsea5_2009-11_i386.deb 0a089e96a675f75f47fbd7011db8bb44 173886 libdevel optional libkpathsea-dev_2009-11_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk5Jg4cACgkQ+xs9YyJS+hpgKACgmMjW8ZrLI7GOrWEUTNQaEZ1X IZcAnRDlaXjzAKREJl5GpuAsuunN8Ck9 =XDaJ -END PGP SIGNATURE- Accepted: libkpathsea-dev_2009-11_i386.deb to main/t/texlive-bin/libkpathsea-dev_2009-11_i386.deb libkpathsea5_2009-11_i386.deb to main/t/texlive-bin/libkpathsea5_2009-11_i386.deb texlive-bin_2009-11.diff.gz to main/t/texlive-bin/texlive-bin_2009-11.diff.gz texlive-bin_2009-11.dsc to main/t/texlive-bin/texlive-bin_2009-11.dsc texlive-binaries_2009-11_i386.deb to main/t/texlive-bin/texlive-binaries_2009-11_i386.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1qt4mw-00046f...@franck.debian.org
Accepted texlive-bin 2009-10 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 28 Jul 2011 21:54:49 +0200 Source: texlive-bin Binary: texlive-binaries libkpathsea5 libkpathsea-dev Architecture: source i386 Version: 2009-10 Distribution: unstable Urgency: low Maintainer: Debian TeX Maintainers debian-tex-ma...@lists.debian.org Changed-By: Frank Küster fr...@debian.org Description: libkpathsea-dev - TeX Live: path search library for TeX (development part) libkpathsea5 - TeX Live: path search library for TeX (runtime part) texlive-binaries - Binaries for TeX Live Closes: 136051 593782 614257 618033 Changes: texlive-bin (2009-10) unstable; urgency=low . [ Hilmar Preusse ] * xdvik compilation error with glibc-2.10 and gcc-4.4: xdvik-22.84.16-open-mode.patch (Closes: #614257) * comment the --disable-largefile switch in upstream build script (partial_lfs_support.diff). This hopefully (Closes: #618033). dvips still can't write files 2GB (see #383781). * we can use gcc-4.5 on armel too . [ Frank Küster ] * Indicate in the description that this package needs a real TeX package to function, and add a Recommends on texlive-base (closes: #593782) * Make various upstream-provided scripts set -e. This closes: #136051 and is needed by the planned papersize patch to texconfig. * The binaries pdftex, dvips, xdvi and dvipdfmx now respect the system-wide paper setting as their default if there is no papersize information in the input file (see #49149). It is still highly recommended to specify such information explicitly, e.g. using hyperref.sty with LaTeX. Checksums-Sha1: 05a821fab11c05eee03d68712231e94008cbfe31 1391 texlive-bin_2009-10.dsc 400d173f5bbcece9c91c2683322513b20f7b9632 91107 texlive-bin_2009-10.diff.gz de626f870a5f6f7e990afbe9038dc8ff10c2bc4a 7684754 texlive-binaries_2009-10_i386.deb 8d5ff314a96f2166bac0b0ab8eda6bb74be8f475 134884 libkpathsea5_2009-10_i386.deb b22df29ac07f67c50191b8f49109c757643518a4 173934 libkpathsea-dev_2009-10_i386.deb Checksums-Sha256: 90da4f31a16f179548e156d092776c7ef81c8b53988eb304d4d6be3049d2e1f2 1391 texlive-bin_2009-10.dsc 82833e243935392f18eaebcbcd557eb1a64ea36703fa489b8d2366ae5db911c0 91107 texlive-bin_2009-10.diff.gz 39a7c954f4890a38406c69813c0fed1052c333bf9aab01f93614dedc3849f46d 7684754 texlive-binaries_2009-10_i386.deb 149fc450be78e4f8780db604c6be87d05371cb1f2f3ce6e9ad8a2380fe359a5d 134884 libkpathsea5_2009-10_i386.deb 3147d3d04c4416f429054bb0826545d18afecc5a553fa7b43ead44bc1a4fc5cb 173934 libkpathsea-dev_2009-10_i386.deb Files: 1fb5cb3c43dbc0f71a92bc48f6fc519c 1391 tex optional texlive-bin_2009-10.dsc 3f4fc7e694afdff5a29b724882b9a958 91107 tex optional texlive-bin_2009-10.diff.gz 809c32c470792626e4eead3c55054d3e 7684754 tex optional texlive-binaries_2009-10_i386.deb a3efa4e46ee5d4b5e0eda294f08eec65 134884 libs optional libkpathsea5_2009-10_i386.deb b7e09c806be66f80b5117a949511843b 173934 libdevel optional libkpathsea-dev_2009-10_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk43F3cACgkQ+xs9YyJS+hqk2ACeMuvBswqGTp+werbUJtDCaJDJ 7GEAoIRz4v8sBEG6ud0odYqTD7qrz8bt =WDre -END PGP SIGNATURE- Accepted: libkpathsea-dev_2009-10_i386.deb to main/t/texlive-bin/libkpathsea-dev_2009-10_i386.deb libkpathsea5_2009-10_i386.deb to main/t/texlive-bin/libkpathsea5_2009-10_i386.deb texlive-bin_2009-10.diff.gz to main/t/texlive-bin/texlive-bin_2009-10.diff.gz texlive-bin_2009-10.dsc to main/t/texlive-bin/texlive-bin_2009-10.dsc texlive-binaries_2009-10_i386.deb to main/t/texlive-bin/texlive-binaries_2009-10_i386.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1qo08i-0004wh...@franck.debian.org
Accepted texlive-base 2009-12 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 28 Jul 2011 22:03:55 +0200 Source: texlive-base Binary: texlive-base texlive-generic-recommended texlive-latex-base texlive-latex-recommended texlive-fonts-recommended texlive-pictures texlive-luatex texlive-metapost texlive-omega texlive-xetex texlive texlive-full texlive-common texlive-fonts-recommended-doc texlive-latex-base-doc texlive-latex-recommended-doc texlive-metapost-doc texlive-pictures-doc Architecture: source all Version: 2009-12 Distribution: unstable Urgency: low Maintainer: Debian TeX Maintainers debian-tex-ma...@lists.debian.org Changed-By: Frank Küster fr...@debian.org Description: texlive- TeX Live: A decent selection of the TeX Live packages texlive-base - TeX Live: Essential programs and files texlive-common - TeX Live: Base component texlive-fonts-recommended - TeX Live: Recommended fonts texlive-fonts-recommended-doc - TeX Live: Documentation files for texlive-fonts-recommended texlive-full - TeX Live: metapackage pulling in all components of TeX Live texlive-generic-recommended - TeX Live: Recommended generic packages texlive-latex-base - TeX Live: Basic LaTeX packages texlive-latex-base-doc - TeX Live: Documentation files for texlive-latex-base texlive-latex-recommended - TeX Live: LaTeX recommended packages texlive-latex-recommended-doc - TeX Live: Documentation files for texlive-latex-recommended texlive-luatex - TeX Live: LuaTeX packages texlive-metapost - TeX Live: MetaPost (and Metafont) drawing packages texlive-metapost-doc - TeX Live: Documentation files for texlive-metapost texlive-omega - TeX Live: Omega texlive-pictures - TeX Live: Graphics packages and programs texlive-pictures-doc - TeX Live: Documentation files for texlive-pictures texlive-xetex - TeX Live: XeTeX packages Closes: 49149 589205 606039 613690 Changes: texlive-base (2009-12) unstable; urgency=low . [ Norbert Preining ] * texlive-base conflict with texlive-base-bin-doc to get it removed (Closes: #589205) . [ Hilmar Preusse ] * texlive-pictures suggests dot2tex (Closes: #613690) * tighten BD-Indep of texlive-base to tex-common (= 2.10) and rebuild (Closes: #606039) . [ Frank Küster ] * Install a hook in libpaper.d and let our postinst call it for new installations. This means that the default paper size for dvips, pdfTeX, dvipdfmx and XDvi will now be the one given by libpaper, and closes: #49149. Yes, the bug number has 5 digits. * Manage the following configuration files with ucf to achieve this: pdftexconfig.tex, config.ps, dvipdfmx.cfg and XDvi Checksums-Sha1: c17fad50bf56a1e5b74ad5b4294165ea38bf3336 1584 texlive-base_2009-12.dsc aabf325de54661d17bd639e1b5e2ab65757b44c5 695220 texlive-base_2009-12.diff.gz 45b404f271b6937a3c747d1c53cf910ee6eb5efa 14740438 texlive-base_2009-12_all.deb 080b14222618af0f577117a27da34f8695ff9e05 1725516 texlive-generic-recommended_2009-12_all.deb d7663e6f7844278b1d1694fa748eea294d7ade26 1423138 texlive-latex-base_2009-12_all.deb f13c446343aee6ed0dfac5420543934ed43c61bf 6776082 texlive-latex-recommended_2009-12_all.deb d6bde4a44c55ce8a9bf3420a647c34140de4de01 7263386 texlive-fonts-recommended_2009-12_all.deb 8d7f263fa3fd8b3728879ce57edc927be1556b62 868014 texlive-pictures_2009-12_all.deb f4997ed8b79d3ca40a30e3766735d5e3d558d1cf 984920 texlive-luatex_2009-12_all.deb 0f8d09a9fcf78d2b53da6ff40642639998331fef 440942 texlive-metapost_2009-12_all.deb d33a28296f9fb6d78c00911f77224a4439f935b3 2271332 texlive-omega_2009-12_all.deb 43170baeea9720aa7c5eeb8c1cb12d3f203c85c6 5734450 texlive-xetex_2009-12_all.deb 209d7ac69f7c5433411025cea648fcdda7d18db6 28346 texlive_2009-12_all.deb 1ae62d433d1fa12598e6120cc631b593baa91aa0 28722 texlive-full_2009-12_all.deb b693cbd8cc5b14a7fa956f63dd4d2a1b31f7e380 100926 texlive-common_2009-12_all.deb 1b39df18d7dc2c778feea4f09268aa406c83243b 2411784 texlive-fonts-recommended-doc_2009-12_all.deb fcff72c2a6662e9efff028cf26278b4b9842b8fb 40768470 texlive-latex-base-doc_2009-12_all.deb 3a41b5c0bd25c4fb32b40c7e2b22a22233fe3338 15448234 texlive-latex-recommended-doc_2009-12_all.deb 303a78f001cfae42a22400f0cb5347f0546c94b7 9330892 texlive-metapost-doc_2009-12_all.deb 67e29b0384890479894a789b5227c40b172b9fb5 11890238 texlive-pictures-doc_2009-12_all.deb Checksums-Sha256: 1ed8b98e03b316100527cc82069c6cfbc1062d3b2ab8b9f05c8f43c933076f29 1584 texlive-base_2009-12.dsc de6852550a9dc578e8183416cd1c838f2e9f5c80986b8a5326635f24a35f0a39 695220 texlive-base_2009-12.diff.gz 3b6da1dc06dc1ef8474c745c557decfd829716e1d79d8c89b8e87fb0c6f4b0cf 14740438 texlive-base_2009-12_all.deb 76150a4c9f01a8d4e28383b1af8f2f87e5b60c382ce86f5dad67584af1086da0 1725516 texlive-generic-recommended_2009-12_all.deb f09d63b71de93ee6f13135fb1ab93c7bb32b58cd79cb1688e3b95ac25faedf9d 1423138 texlive-latex-base_2009-12_all.deb 17d65dd04472249f433f92a9762faf69ba0e61711e381e99e94cd4647dd3d285 6776082
Accepted texlive-base 2009-13 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 02 Aug 2011 21:12:16 +0200 Source: texlive-base Binary: texlive-base texlive-generic-recommended texlive-latex-base texlive-latex-recommended texlive-fonts-recommended texlive-pictures texlive-luatex texlive-metapost texlive-omega texlive-xetex texlive texlive-full texlive-common texlive-fonts-recommended-doc texlive-latex-base-doc texlive-latex-recommended-doc texlive-metapost-doc texlive-pictures-doc Architecture: source all Version: 2009-13 Distribution: unstable Urgency: low Maintainer: Debian TeX Maintainers debian-tex-ma...@lists.debian.org Changed-By: Frank Küster fr...@debian.org Description: texlive- TeX Live: A decent selection of the TeX Live packages texlive-base - TeX Live: Essential programs and files texlive-common - TeX Live: Base component texlive-fonts-recommended - TeX Live: Recommended fonts texlive-fonts-recommended-doc - TeX Live: Documentation files for texlive-fonts-recommended texlive-full - TeX Live: metapackage pulling in all components of TeX Live texlive-generic-recommended - TeX Live: Recommended generic packages texlive-latex-base - TeX Live: Basic LaTeX packages texlive-latex-base-doc - TeX Live: Documentation files for texlive-latex-base texlive-latex-recommended - TeX Live: LaTeX recommended packages texlive-latex-recommended-doc - TeX Live: Documentation files for texlive-latex-recommended texlive-luatex - TeX Live: LuaTeX packages texlive-metapost - TeX Live: MetaPost (and Metafont) drawing packages texlive-metapost-doc - TeX Live: Documentation files for texlive-metapost texlive-omega - TeX Live: Omega texlive-pictures - TeX Live: Graphics packages and programs texlive-pictures-doc - TeX Live: Documentation files for texlive-pictures texlive-xetex - TeX Live: XeTeX packages Closes: 636304 Changes: texlive-base (2009-13) unstable; urgency=low . * Fix shell syntax in the libpaper script (closes: #636304) Checksums-Sha1: d64faded29bc837cd6739e29da08b2366795527d 1584 texlive-base_2009-13.dsc 7106442e909c8be8f74be2c2753727f426d54ddc 695331 texlive-base_2009-13.diff.gz f79246568af4119e6c0a312273f4b0b5798321a6 14740390 texlive-base_2009-13_all.deb 47be4c12f2d1db6279893f028544bee3aa1f2011 1725544 texlive-generic-recommended_2009-13_all.deb 231d0c7754e2bc7574e1b6a73a16b9a39cc52173 1423196 texlive-latex-base_2009-13_all.deb e94aa2205159521a03787ad8d82a2119a0e3a0b6 6776152 texlive-latex-recommended_2009-13_all.deb 42a55ad1d7f573250c62e649556e1208df2a7f91 7263370 texlive-fonts-recommended_2009-13_all.deb 0df32901193e9de1d16a2f6cde4362bec2c327c3 868070 texlive-pictures_2009-13_all.deb 30338c3f78741713b2ce0d9d158c18511316989b 985004 texlive-luatex_2009-13_all.deb edfcc3890b4a81379e5f4772b21089619bf2b8fb 440968 texlive-metapost_2009-13_all.deb ab0fd72fa4c2e2d5e44f90fc35aa577e6c7bf88c 2271354 texlive-omega_2009-13_all.deb 02966e45e6eaf047bc1b08df6a2978437c0512df 5734420 texlive-xetex_2009-13_all.deb 031f702b6ebe239931d8ec398d5b476fa4913031 28398 texlive_2009-13_all.deb dac31c01f72ba83173e128abe2152824d3bae7db 28816 texlive-full_2009-13_all.deb ed4f51a8732d39693d6612f633e1343d4b9c6d31 101048 texlive-common_2009-13_all.deb 2d48233f2d3ae40da9bdab87460d9cba8c8fe8af 2411888 texlive-fonts-recommended-doc_2009-13_all.deb e8b21fe4e7ad202faa7ca3f2ef75caa171a772bd 40768592 texlive-latex-base-doc_2009-13_all.deb 7a9a2f705041ce9fc192484e2735874a8a999ff4 15448624 texlive-latex-recommended-doc_2009-13_all.deb dbfbcdbaa02783320fe2c2b4361086215d8b4a38 9330872 texlive-metapost-doc_2009-13_all.deb 970b730e2cf89238f52469c90dec3fcdcb1ba344 11890236 texlive-pictures-doc_2009-13_all.deb Checksums-Sha256: 90c0f703097901e7abb38ab0418a15cd140ca847ae415b8fa872a4512ae7f12d 1584 texlive-base_2009-13.dsc 00f6eaf17b465321c7cdbd33aee416b617477e2da7405e2801ebc807bd645809 695331 texlive-base_2009-13.diff.gz 7e8198f6f02bc401a88b68e68e31cd5ea19f187730f5f0af5d4115bd0a19c3c4 14740390 texlive-base_2009-13_all.deb afbc9be6c996a6da48e5915e1de4f4c32c81656492099a2b9f2b6494f053d5fc 1725544 texlive-generic-recommended_2009-13_all.deb 1944c20c7efeac620666e478aed24ab3b91ed87a70c48205c64962b3e56e2661 1423196 texlive-latex-base_2009-13_all.deb 9e174d3a12b6be84b218ce23201d86c0f40cb66da8cecf69a509f8895c4abd65 6776152 texlive-latex-recommended_2009-13_all.deb cc2d3c1de85c32d198def4302c058541228e6b1ab06c15d52bfabc6301b8aacb 7263370 texlive-fonts-recommended_2009-13_all.deb bdde5c590843351b7ce588eb905dfde63f3f39856ea6597f4d43aed2cd4a688e 868070 texlive-pictures_2009-13_all.deb 502e070de954676a5a516021a6eb823ff261fb375732ede68cdb49975ba895cb 985004 texlive-luatex_2009-13_all.deb e8e84b89d52ddb216991e94dabd2b5ab7d89978b178336457ed3550b00a33758 440968 texlive-metapost_2009-13_all.deb 5de388f5b4ddec77d2da135fb47af02f26842e35389b427802952bfe4d82de53 2271354 texlive-omega_2009-13_all.deb f56710ea2cb60890acffc2b30ca8117a62ddf383fd1dd36303b257869525550a 5734420 texlive-xetex_2009
Accepted texlive-base 2009-14 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 20 Sep 2011 08:55:38 +0200 Source: texlive-base Binary: texlive-base texlive-generic-recommended texlive-latex-base texlive-latex-recommended texlive-fonts-recommended texlive-pictures texlive-luatex texlive-metapost texlive-omega texlive-xetex texlive texlive-full texlive-common texlive-fonts-recommended-doc texlive-latex-base-doc texlive-latex-recommended-doc texlive-metapost-doc texlive-pictures-doc Architecture: source all Version: 2009-14 Distribution: unstable Urgency: low Maintainer: Debian TeX Maintainers debian-tex-ma...@lists.debian.org Changed-By: Frank Küster fr...@debian.org Description: texlive- TeX Live: A decent selection of the TeX Live packages texlive-base - TeX Live: Essential programs and files texlive-common - TeX Live: Base component texlive-fonts-recommended - TeX Live: Recommended fonts texlive-fonts-recommended-doc - TeX Live: Documentation files for texlive-fonts-recommended texlive-full - TeX Live: metapackage pulling in all components of TeX Live texlive-generic-recommended - TeX Live: Recommended generic packages texlive-latex-base - TeX Live: Basic LaTeX packages texlive-latex-base-doc - TeX Live: Documentation files for texlive-latex-base texlive-latex-recommended - TeX Live: LaTeX recommended packages texlive-latex-recommended-doc - TeX Live: Documentation files for texlive-latex-recommended texlive-luatex - TeX Live: LuaTeX packages texlive-metapost - TeX Live: MetaPost (and Metafont) drawing packages texlive-metapost-doc - TeX Live: Documentation files for texlive-metapost texlive-omega - TeX Live: Omega texlive-pictures - TeX Live: Graphics packages and programs texlive-pictures-doc - TeX Live: Documentation files for texlive-pictures texlive-xetex - TeX Live: XeTeX packages Closes: 638715 639280 639427 639512 639604 639734 640062 640114 640409 640536 640733 641042 641830 Changes: texlive-base (2009-14) unstable; urgency=low . [ Frank Küster ] * Debconf templates review and translation process initiated and coordinated by Christian Perrier, many thanks! * Debconf templates and debian/control reviewed by the debian-l10n- english team as part of the Smith review project. Closes: #638715 * Czech (Michal Simunek). Closes: #639280 * Russian (Yuri Kozlov). Closes: #639427 * Italian (Dario Santamaria). Closes: #639512 * Slovak (Slavko). Closes: #639604 * French (Alexandre Normand). Closes: #639734 * Swedish (Martin Bagge / brother). Closes: #640062 * Dutch; (Jeroen Schot). Closes: #640114 * Danish (Joe Hansen). Closes: #640409 * German (Chris Leick). Closes: #640536 * Portuguese (Rui Branco). Closes: #640733 * Spanish; (Francisco Javier Cuadrado). Closes: #641042 * Catalan (Innocent De Marchi). Closes: #641830 Checksums-Sha1: e2f2b4980a7964583fba26c91d2fdced7b14cd63 1584 texlive-base_2009-14.dsc 2c34793d5c87fb028fab525662665ab4baa3d5ee 701386 texlive-base_2009-14.diff.gz b2fbf110d6b74e1ed395cca8fb7687abd965b26e 14743478 texlive-base_2009-14_all.deb cf8a20d2f9f1c4340112324e0d0cf02f6ac61700 1725928 texlive-generic-recommended_2009-14_all.deb e44346cf6e9649d7749b95dfe1ba3fcf2a3bdd98 1423450 texlive-latex-base_2009-14_all.deb 734c9352df7adf71867762af7917a96974e25a36 6776798 texlive-latex-recommended_2009-14_all.deb 15486f0e013f4288b73c102d2f7a932ec712d436 7263444 texlive-fonts-recommended_2009-14_all.deb 763e5b97fb1946d3742273fd7d8f58a1bdad3b0a 868302 texlive-pictures_2009-14_all.deb 293b92bf8268495aa0e67f6caf952183d4aa4441 985442 texlive-luatex_2009-14_all.deb fdf251512a5650f6323257808ca396133d170f8e 441258 texlive-metapost_2009-14_all.deb a02e409f6faa34e185f4c72e39db5281695c739c 2271518 texlive-omega_2009-14_all.deb b78c0eaef777a8c448b7af93750487976b03f6bb 5734836 texlive-xetex_2009-14_all.deb 2748bdc2d74cf02f2c1c90ab6fcb2f09246dd11d 28758 texlive_2009-14_all.deb 0f862fc202ad8c29432781b4c15624649b74a8a4 29182 texlive-full_2009-14_all.deb 8b4e27dd6e8bf9a3abc5e401caab6c3ea037ad52 101442 texlive-common_2009-14_all.deb f11b12362e96f29d2cb73efd3b83c91fcd8e9e68 2412458 texlive-fonts-recommended-doc_2009-14_all.deb 085ebf794f43fe7b9ae7b70f9f20a9c296e5f297 40768710 texlive-latex-base-doc_2009-14_all.deb 11cabcaf42edc43b35f877cce4e94ae5698d228a 15449454 texlive-latex-recommended-doc_2009-14_all.deb aa4ebb553bd34594b2a08eb35783f296d8686b34 9331158 texlive-metapost-doc_2009-14_all.deb 78e91a4ee68a624af396e13d16ebd18f1141288c 11890496 texlive-pictures-doc_2009-14_all.deb Checksums-Sha256: b47f1315e35996e5cc38a246edd693d692ae5c31ec3205ea26e478d9e679a584 1584 texlive-base_2009-14.dsc 190ccd64a7916bd19f00c1da74d7179ea5e3426858ddc6f0fb8d1192ae9a8636 701386 texlive-base_2009-14.diff.gz a599edcdc114e163a02d1aa29ae17920f7dc9b22db01d6548a837e645d3ea416 14743478 texlive-base_2009-14_all.deb d2772e78ed11e8b213598899230fde87435855871df03826b8c3601526de768b 1725928 texlive-generic
Accepted texlive-base 2009-15 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sun, 13 Nov 2011 23:03:22 +0100 Source: texlive-base Binary: texlive-base texlive-generic-recommended texlive-latex-base texlive-latex-recommended texlive-fonts-recommended texlive-pictures texlive-luatex texlive-metapost texlive-omega texlive-xetex texlive texlive-full texlive-common texlive-fonts-recommended-doc texlive-latex-base-doc texlive-latex-recommended-doc texlive-metapost-doc texlive-pictures-doc Architecture: source all Version: 2009-15 Distribution: unstable Urgency: low Maintainer: Debian TeX Maintainers debian-tex-ma...@lists.debian.org Changed-By: Frank Küster fr...@debian.org Description: texlive- TeX Live: A decent selection of the TeX Live packages texlive-base - TeX Live: Essential programs and files texlive-common - TeX Live: Base component texlive-fonts-recommended - TeX Live: Recommended fonts texlive-fonts-recommended-doc - TeX Live: Documentation files for texlive-fonts-recommended texlive-full - TeX Live: metapackage pulling in all components of TeX Live texlive-generic-recommended - TeX Live: Recommended generic packages texlive-latex-base - TeX Live: Basic LaTeX packages texlive-latex-base-doc - TeX Live: Documentation files for texlive-latex-base texlive-latex-recommended - TeX Live: LaTeX recommended packages texlive-latex-recommended-doc - TeX Live: Documentation files for texlive-latex-recommended texlive-luatex - TeX Live: LuaTeX packages texlive-metapost - TeX Live: MetaPost (and Metafont) drawing packages texlive-metapost-doc - TeX Live: Documentation files for texlive-metapost texlive-omega - TeX Live: Omega texlive-pictures - TeX Live: Graphics packages and programs texlive-pictures-doc - TeX Live: Documentation files for texlive-pictures texlive-xetex - TeX Live: XeTeX packages Closes: 644737 648652 Changes: texlive-base (2009-15) unstable; urgency=low . [ Hilmar Preusse ] * Updated Italian debconf translation (Dario Santamaria). Closes: #644737 . [ Frank Küster ] * Update the TEXMF filename database before running texconfig in postinst (closes: #648652) Checksums-Sha1: ff527a82390ea0dd7f85bf1905613688206f7db1 2275 texlive-base_2009-15.dsc 85a790d0a425c9a26f9f08b5d496b1eabe0a98f4 701474 texlive-base_2009-15.diff.gz f2cf3716815fea0a92256be161ee84e528e8d94e 14743976 texlive-base_2009-15_all.deb 4925b4b869159cad9c1c1456be3f30fa3defb5b9 1725984 texlive-generic-recommended_2009-15_all.deb 0a1968ab26eb072765c603367041ee470f02ecbe 1423572 texlive-latex-base_2009-15_all.deb 7efed3d84ef67f99930374f3bfbe034a8502350d 6776806 texlive-latex-recommended_2009-15_all.deb 5a7c95840524f5305f482cfca33f0057b2b7c36e 7263412 texlive-fonts-recommended_2009-15_all.deb 2f0c161de85a954f7f80888db67b130b26e57080 868398 texlive-pictures_2009-15_all.deb 06ffd4da6106060afb6eba54e143850f62cf3920 985530 texlive-luatex_2009-15_all.deb a04547592f9a65b9db4366f0a94c729b817971d1 441320 texlive-metapost_2009-15_all.deb 257d0b576e20a7c9b40ffe90b62acf4ea6696b1f 2271424 texlive-omega_2009-15_all.deb c73201578e07f668d07e929c1ac020474aa39f26 5735064 texlive-xetex_2009-15_all.deb 461eacc67eebc24358ce15f4c03a0f91d2836086 28830 texlive_2009-15_all.deb e32f6ec5071eb4c474a9fee7c66a7832360a01ff 29252 texlive-full_2009-15_all.deb 4ea9eda66a00f043981168928b9b208379f18954 101538 texlive-common_2009-15_all.deb b63d5294f69dcc12b2adf01551ad185228a2c1f8 2412568 texlive-fonts-recommended-doc_2009-15_all.deb 1f9cf47ee7343d53604a90e32b94b3f2cd59b8de 40768558 texlive-latex-base-doc_2009-15_all.deb c857e45f5e2cf4ac6ea52abea4ae7b7150c7e298 15449578 texlive-latex-recommended-doc_2009-15_all.deb 404046212ebd399894f334d555f7e55c0fcc8520 9331236 texlive-metapost-doc_2009-15_all.deb c3fd77a4911dea253149dc701edd008d9fddff3b 11890476 texlive-pictures-doc_2009-15_all.deb Checksums-Sha256: 23e0aa076f980b79cc95c7d1a26c2a5e2b20f6e64e0a67527cbf054bca7ad5d8 2275 texlive-base_2009-15.dsc d9594da05d11cba9f9955fd75008c1ad57d15e111280523c8327bf80be6a18c8 701474 texlive-base_2009-15.diff.gz 63c95508ef8cc8291c52f799cab996bd64c46d9bdca4a7142409d32c7746bd61 14743976 texlive-base_2009-15_all.deb 6a66b9ee8b025768f27ca849e43e378961719d04beb88d9874c53466d9227912 1725984 texlive-generic-recommended_2009-15_all.deb dbcb7dda60cd86c7d92bbab8e36737237756ace1f3fcfd6b11f0f8c5a21f3cbc 1423572 texlive-latex-base_2009-15_all.deb 11d59b88896d46d2d86bf4d558bde365250a8a9bbc09038b8e9a50a62a2e36b6 6776806 texlive-latex-recommended_2009-15_all.deb f67288c4375775a2c18c67017acf8bb45289122a57ddcaced7119681831db5d7 7263412 texlive-fonts-recommended_2009-15_all.deb 8c014640d3a74c072eb80a60e3dba25ac7c1d84ad2a4b54133a34eeadc08 868398 texlive-pictures_2009-15_all.deb 1a00926f7e8cca6a0b87d8c7231f76225a22f9f471666a792c4b1e69de1e6884 985530 texlive-luatex_2009-15_all.deb 1ff9a43f72d126d9572aae01e5c7ff32f9b333615e38fd563a6c9f8d1042dbb4 441320 texlive-metapost_2009-15_all.deb
Accepted tex-common 0.39 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 21 Nov 2006 18:32:32 +0100 Source: tex-common Binary: tex-common Architecture: source all Version: 0.39 Distribution: unstable Urgency: low Maintainer: Debian TeX maintainers [EMAIL PROTECTED] Changed-By: Frank Küster [EMAIL PROTECTED] Description: tex-common - Common infrastructure for using and building TeX in Debian Closes: 397717 Changes: tex-common (0.39) unstable; urgency=low . * changelog editing: fix wrong bugnumber in last upload [frank] * Add a more verbose explanation to the warning when updmap-sys failed (closes: #397717), and echo errors to stderr. [frank] * Change default priority for dh_installtex to 20, and document in the TeX Policy that 10 is reserved for Basic TeX packages. This would have avoided bug #399447. [frank] Files: 8ca16023b0603dd6a5ab7c545eb8ade8 756 tex optional tex-common_0.39.dsc aab9b5d4813ed6dcbf8c240556de4434 481919 tex optional tex-common_0.39.tar.gz d564a506be0527ce501b2510140b58d6 474992 tex optional tex-common_0.39_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFZBw3+xs9YyJS+hoRAgo7AJ0bfDbHdwWAn1sLgutTth+fj5TRCACgjn09 306BhxgsZpYgY9dF6ebp6gA= =LBZ8 -END PGP SIGNATURE- Accepted: tex-common_0.39.dsc to pool/main/t/tex-common/tex-common_0.39.dsc tex-common_0.39.tar.gz to pool/main/t/tex-common/tex-common_0.39.tar.gz tex-common_0.39_all.deb to pool/main/t/tex-common/tex-common_0.39_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted texinfo 4.8.dfsg.1-4 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 22 Nov 2006 12:04:54 +0100 Source: texinfo Binary: texinfo info Architecture: source i386 Version: 4.8.dfsg.1-4 Distribution: unstable Urgency: high Maintainer: Norbert Preining [EMAIL PROTECTED] Changed-By: Frank Küster [EMAIL PROTECTED] Description: info - Standalone GNU Info documentation browser texinfo- Documentation system for on-line information and printed output Changes: texinfo (4.8.dfsg.1-4) unstable; urgency=high . * Apply patch by Josh Bressers [EMAIL PROTECTED] to fix CVE-2006-4810, added as 33_texindex_CVE-2006-4810.dpatch * Add myself to Uploaders so this doesn't look like an NMU. Files: 2c233d2bf6627eac32deb9bb87726ea1 680 doc standard texinfo_4.8.dfsg.1-4.dsc e01520524bc114d90a2a1e5eefe71b50 101211 doc standard texinfo_4.8.dfsg.1-4.diff.gz 2deac9cb56abe7d4559dcb956b037fab 680962 text standard texinfo_4.8.dfsg.1-4_i386.deb 18f1155d88419daaf6a849475ede3b60 164870 doc important info_4.8.dfsg.1-4_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFZDZ1+xs9YyJS+hoRAv8jAKCJqHUcbaGkn3uTA1w1d84xVn69/ACfYw+g B5gdnsoWthvy4f6/igxto0k= =Mle0 -END PGP SIGNATURE- Accepted: info_4.8.dfsg.1-4_i386.deb to pool/main/t/texinfo/info_4.8.dfsg.1-4_i386.deb texinfo_4.8.dfsg.1-4.diff.gz to pool/main/t/texinfo/texinfo_4.8.dfsg.1-4.diff.gz texinfo_4.8.dfsg.1-4.dsc to pool/main/t/texinfo/texinfo_4.8.dfsg.1-4.dsc texinfo_4.8.dfsg.1-4_i386.deb to pool/main/t/texinfo/texinfo_4.8.dfsg.1-4_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted tetex-bin 3.0-24 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 24 Nov 2006 15:28:51 +0100 Source: tetex-bin Binary: tetex-bin libkpathsea-dev libkpathsea4 Architecture: source i386 Version: 3.0-24 Distribution: unstable Urgency: high Maintainer: Debian TeX maintainers [EMAIL PROTECTED] Changed-By: Frank Küster [EMAIL PROTECTED] Description: libkpathsea-dev - path search library for teTeX (devel part) libkpathsea4 - path search library for teTeX (runtime part) tetex-bin - The teTeX programs Closes: 396823 399897 Changes: tetex-bin (3.0-24) unstable; urgency=high . * Apply patch from upstream to pdftex that allows it to work properly with CJK fonts with their large number of subfonts. Many thanks to Thanh Han The [EMAIL PROTECTED], Jie Luo [EMAIL PROTECTED] for the patch and many others for debugging. This fixes a FTBFS bug in debian-reference and closes: #399897, hence the urgency * Write a proper manpage for texconfig, and document which commands make sense to be used on a Debian system. Thanks to Géraud Meyer [EMAIL PROTECTED] for reminding us (closes: #396823) * Make texconfig faq find the teTeX faq Files: 6c4c19f79e297f59c15b372e9d8c7799 1011 tex optional tetex-bin_3.0-24.dsc 66f0a66bf5a6506df70066aa95f8cd2f 125710 tex optional tetex-bin_3.0-24.diff.gz f58e324f6bfd4a81e35df1ca07089036 3559746 tex optional tetex-bin_3.0-24_i386.deb 005d4205577d309bde71751d6302c27f 80724 libs optional libkpathsea4_3.0-24_i386.deb 4bd4ba7b444a7f1c4499ea568bf6fd63 70600 libdevel optional libkpathsea-dev_3.0-24_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFZxKd+xs9YyJS+hoRAj1HAKCMeSddBxjFUPUULF/btEk9YtbhCwCeLgKC 4h3U04m3xd/Vy1di7YmqdtA= =1IgJ -END PGP SIGNATURE- Accepted: libkpathsea-dev_3.0-24_i386.deb to pool/main/t/tetex-bin/libkpathsea-dev_3.0-24_i386.deb libkpathsea4_3.0-24_i386.deb to pool/main/t/tetex-bin/libkpathsea4_3.0-24_i386.deb tetex-bin_3.0-24.diff.gz to pool/main/t/tetex-bin/tetex-bin_3.0-24.diff.gz tetex-bin_3.0-24.dsc to pool/main/t/tetex-bin/tetex-bin_3.0-24.dsc tetex-bin_3.0-24_i386.deb to pool/main/t/tetex-bin/tetex-bin_3.0-24_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
