Re: Sharing data between maintainer scripts and debian/rules
Neil Williams 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
Re: Debconf syntax error message that I don't understand
Joey Hess 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: Debconf syntax error message that I don't understand
Joey Hess 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
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: svn.debian.org ???
Norbert Preining 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
Re: Writing to /etc/ from a "privileged" UI
Adam Borowski 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: Writing to /etc/ from a "privileged" UI
Jan Hauke Rahm 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: Directories named after packages
Osamu Aoki 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: Bug#584013: hyperlatex: Security bugs in ghostscript
Romain Beauxis 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: German Debian
I'm a bit late but... Marc Haber 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 Menu category Applictions/Multimedia
Andreas Marschke 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
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: Policy conformant conffile handling...
Frank Küster wrote: > Steve Langasek 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
Re: Policy conformant conffile handling...
Steve Langasek 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
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: Lintian based autorejects
Stefano Zacchiroli 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
Re: Moving binary packages between source packages, and closing bugs
Roberto C. Sánchez 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
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: Policy §10.4 as a divergence from usptream (renamings to remove extensions like .pl and .sh).
David Goodenough 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
Re: What is this rule for?
Russ Allbery wrote: > Andreas Tscharner 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: Auto Backporting
Andreas Tille 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: Non-unified patches and dpkg source format ‘3.0 (quilt)’.
Neil McGovern wrote: > On Fri, Aug 07, 2009 at 10:45:14AM +0900, Charles Plessy wrote: >> Giving a standard interface to reviewers is a laudable goal, but I do not see >> reviewers except in elaborate scenarios about security. Therefore I will not >> trade a real benefit for a hypothetical one, even if both are neglectible. >> Also, I think that it is very important in a project of 1,000 persons to >> stick >> to facts, and avoid building illusions together. So as long as there is no >> reviewing process nor package reviews, there is no need to adapt to imaginary >> reviewers. >> > > /me raises his release team hat. During a freeze, one typically wouldn't apply the upstream patches anyway, but just cherry-pick individual changes. In this case, it wouldn't be a problem to create unified diffs. Or even reformat the context diff to unified, in case the upstream patch contains nothing but RC (and translation) fixes. 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: Non-unified patches and dpkg source format ‘3.0 (quilt)’.
Pierre Habouzit wrote: > On Fri, Aug 07, 2009 at 10:45:14AM +0900, Charles Plessy wrote: >> Le Thu, Aug 06, 2009 at 09:26:02AM -0700, Russ Allbery a écrit : >> > >> > (filterdiff comes with patchutils.) Given that, this seems like a tempest >> > in a teapot to me. Just convert the diff into whatever format the tool >> > that you're using expects or the reviewer wants to read. >> >> Hi Russ and everybody, >> >> I already explained that I prefered that the patch stays in the original >> format > > Then you'll need to write your "own" patch system that calls patch(1) to > apply the patches, à la cdbs-simple-patchsys. Why should he need to do that? If you'd had written "submit patches to dpkg", I could get a meaning out of it, but here? He doesn't want to diverge from upstream. 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: binNMUs for arch:all packages too
Steve Langasek wrote:
> On Mon, Jul 06, 2009 at 01:50:14PM +0300, Kari Pahula wrote:
>> only builds foo_1.0-1+b1 for arch:any packages. No +b1 is built for
>> any possible -doc packages. Often, this is what's expected, but not
>> always.
>
>> I don't know offhand if this has been discussed before. Any reasons
>> why this shouldn't be supported?
>
> Because:
>
> - there are no autobuilders configured to build arch: all packages in debian
We know...
> - allowing arch: all packages to be binNMUed breaks the invariant that
> packages may use ${binary:Version} for package relationships on other
> arch: any packages from the same source package, and ${source:Version} for
> package relationships on arch: all packages from the source package
>
>> What's needed to get this working?
>
> I don't think it should be made to work.
The ${source:Version} thing is a point. However, I also see a need for
such binNMUs, or rather a case where it would be helpful.
That's the case when a package Build-Depends on some package because it
needs to incorporate code (or configuration settings or data or
whatever) into it's arch:all binary packages. For example tex-common
provides dh_installtex which writes code into the Build-Depending
packages's maintainer scripts.
I'm not aware of any other debhelper-like scripts, but there may be
some. Fixing a bug in cdbs (e.g. failing to make the necessary dh_foo
calls) might also mean that some packages need to be rebuilt.
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: BTS and the missing 'invalid' tag
Michael Banck wrote: > On Sun, Jun 21, 2009 at 06:32:10PM +0100, Neil Williams wrote: >> Which is precisely what I don't think we need. There is no difference >> between "invalid" and "this is an invalid bug, closing". > > Of course there is. After the closed bug got archived, it's no longer > displayed by default for a bug search. So chances are that the next > user encountering this non-bug will file it again. In this case, I'd tend to say that there is actually a bug: Move the documentation that explains why the behavior is intended to a more prominent, visible place. 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: RFC: DEP-3: Patch Tagging Guidelines
Raphael Hertzog wrote: > Hello everybody, > > I'll try to do some new proposals based on your feedback. But first let > me address the topic of the usefulness of the proposal. While there are > currently no tools making use of this format, [...] > In any case, it's a required step IMO if we want to increase the visibility > of our patches and ensure they are better reviewed. I think that one important aspect of that format would be that it also says which content should be given. And having that content in more patches in Debian would be very useful even for non-tools (read: people). When adding a new patch, empty fields remind you to write *something* instead of just dropping the diff into debian/patches... 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: Bug#530832: Bug#531581: Critical problems on hppa and ia64 buildds
Luk Claes wrote: > Frank Küster wrote: >> Luk Claes wrote: >> >>> Norbert Preining wrote: >>>> On Do, 04 Jun 2009, Luk Claes wrote: >>>>> Except for arguing, mixing (non?) bugs and resisting to upload an easy >>>>> workaround might have made things worse btw... >>>> And that easy workaround would be??? >>> To only conditionaly use a command that seems to not always be available. >> >> COULD YOU PLEASE START READING WHAT WE ARE WRITING? > > Could you please do that from the start and not spread fud and shout all > the time? I still think that I have tried to give technical arguments all the time, until I had to should this time. I've not yet read one from you, it was Agustin who helped. >> texlive-base's postrm, upon REMOVE, uses a command from tex-common, on >> which it already DEPENDS. This is allowed by policy. > > Sure, though policy not describing what really happens will only make it > a bug in policy AND your package... Sad but true. >> The fact that in this particular chroot, texlive-base was installed >> without tex-common being installed, or even unpacked, is NOT A BUG OF >> tex-common. > > Sure it is. Err, that I still don't understand. I agree that it's a bug in texlive-base not to be able to cope with that. But how can it be a bug of package b that it is not installed, when package a depends on it and is installed? 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: Bug#531581: Critical problems on hppa and ia64 buildds
retitle 530832 maintainer scripts created by tex-common may not assume tex-common to be present in "postrm remove" thanks ia64, I assume that you have moved the broken remains of texlive-base away manually? Agustin Martin wrote: > Frank, your package honours current Debian policy about that, but Debian > Policy is buggy about that. Thank you very much. You seem to be the first person who's not yelling but giving arguments. > See #504880, message #106 from Ian Jackson. You cannot rely on dependencies > being installed at postrm, > > Imagine package a depends on package b > > # dpkg --unpack a > # dpkg --purge a > > can be done without "b" present. And you do not need any --force option. Yes, I see. We'll have to make an upload of texlive-2007. 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: Bug#531581: Critical problems on hppa and ia64 buildds
Luk Claes wrote: > Norbert Preining wrote: >> On Do, 04 Jun 2009, Luk Claes wrote: >>> Except for arguing, mixing (non?) bugs and resisting to upload an easy >>> workaround might have made things worse btw... >> >> And that easy workaround would be??? > > To only conditionaly use a command that seems to not always be available. COULD YOU PLEASE START READING WHAT WE ARE WRITING? texlive-base's postrm, upon REMOVE, uses a command from tex-common, on which it already DEPENDS. This is allowed by policy. The fact that in this particular chroot, texlive-base was installed without tex-common being installed, or even unpacked, is NOT A BUG OF tex-common. It seems it is a bug of policy, or dpkg. 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: Bug#531581: Critical problems on hppa and ia64 buildds
Luk Claes wrote: > Frank Küster wrote: >> Luk Claes wrote: >> >>> Fine, though taking the trouble to talk to the porters might still be >>> worthwile. >> >> Yes, but definitely not after I've spend hours of my little Debian >> arguing about non-bugs with people who don't read what I say and instead >> insist on blaming our packages without explaining why. > > You were the one reassigning in the first place AFAIR... Because I didn't see a reason why it should be a bug in our packages. And I still don't, since although you and others send loads of mails what we should do, no one ever discusses the technical aspects of the problem. 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: Bug#531581: Critical problems on hppa and ia64 buildds
Frank Küster wrote: > Luk Claes wrote: > >> Fine, though taking the trouble to talk to the porters might still be >> worthwile. > > Yes, but definitely not after I've spend hours of my little Debian ^time > arguing about non-bugs with people who don't read what I say and instead > insist on blaming our packages without explaining why. > > Regards, Frank > -- > Dr. Frank Küster > Debian Developer (TeXLive) > VCD Aschaffenburg-Miltenberg, ADFC Miltenberg > B90/Grüne KV Miltenberg -- 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: Bug#531581: Critical problems on hppa and ia64 buildds
Philipp Kern wrote: > On 2009-06-04, Frank Küster wrote: >> And what would be the criterion for "solved"? After an analysis of >> N build logs of random packages on that buildd show no segfaults any >> more? I am not going to do that. >> >> It's not a bug in my package; I am not going to take responsibility for >> it. > > There are two issues: one that a buildd has random segfaults. That's > sadly common on hppa and ought to be ignored. > > Secondly a package messes up the buildd's chroot on ia64. You are speaking of #530832, aren't you? So please tell me why some people think that it is tex-common who messes up the buildd's chroot. I have given detailed arguments, multiple times, why I don't think so. Please follow up on that. Please follow up on http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=530832#51 or http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=530832#56 after you've read what I wrote there. I'm open to be convinced, but so far no one has been giving any technical arguments. Pissed, 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: Bug#531581: Critical problems on hppa and ia64 buildds
Luk Claes wrote: > Fine, though taking the trouble to talk to the porters might still be > worthwile. Yes, but definitely not after I've spend hours of my little Debian arguing about non-bugs with people who don't read what I say and instead insist on blaming our packages without explaining why. 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: Bug#531581: Critical problems on hppa and ia64 buildds
Luk Claes wrote: >> That doesn't solve my problem: Should I > >> - make sure that the porters, buildd admins etc. are aware of the >> problem and simply close the bug? > > You might want to downgrade the bug and only close it when it is realy > solved? And what would be the criterion for "solved"? After an analysis of N build logs of random packages on that buildd show no segfaults any more? I am not going to do that. It's not a bug in my package; I am not going to take responsibility for it. >>> The one on ia64 breaks the buildd's chroot and looks to be easily solved >>> by making sure that the maintainer scripts don't fail when the missing >>> command is not available. >> >> ? >> >> It could be easily solved by making sure that nothing on the buildd >> installs packages without installing their dependencies. > > A patch is appreciated, thanks for your cooperation. Excuse me - that should already be guaranteed by dpkg, or am I missing something? If it isn't on that machine, what kind of patch should I write? 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: Bug#531581: Critical problems on hppa and ia64 buildds
Luk Claes wrote: >> And what should one do with a bug like this? At the moment it's quite >> irrelevant whether one of our packages has a bogus RC bug. But what if >> that happens when I'm hoping for a transition to testing? > > Are you now talking about the failure on hppa or the one on ia64 (in > both cases the bugs were filed by the buildd admin)? I'm talking about any bug that was filed against package $foo because package $bar FTBFS on $buildd_a, when it later turns out that the reason for the breakage is "something" on $buildd_a. > The one on hppa is as far as I can see nothing you can do about and > should probably be mentioned to the porters. That doesn't solve my problem: Should I - keep the bug open against my package? Doesn't make sense, since I have no bug - make sure that the porters, buildd admins etc. are aware of the problem and simply close the bug? - reassign to buildd.debian.org: That you just said I shouldn't do - reassign to $computer_name.buildd.debian.org: That would make most sense, but it isn't possible. > The one on ia64 breaks the buildd's chroot and looks to be easily solved > by making sure that the maintainer scripts don't fail when the missing > command is not available. ? It could be easily solved by making sure that nothing on the buildd installs packages without installing their dependencies. 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: Bug#531581: Critical problems on hppa and ia64 buildds
[a failed build was wrongly assigned as a RC bug of texlive-base, and since the reason was a problem on the buildd, I assigned it to buildd.debian.org] Luk Claes wrote: > buildd.d.o is not the place to reassign bugs for particular buildds to. > If it's just for particular buildds, you'd better contact the buildd > admin like you did. And what should one do with a bug like this? At the moment it's quite irrelevant whether one of our packages has a bogus RC bug. But what if that happens when I'm hoping for a transition to testing? What do people generally do in such a case? What should we do? 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: Who uses @packages.d.o mail?
Stephen Gran wrote: > day from elsewhere. I haven't done an exhaustive survey, but it seems > pretty clear so far that the domain does not get any significant amount > of legitimate mail from machines other than the debian.org hosts. > > If this is actually the case, I'd like to close the domain down to only > accept mail from other debian.org machines. What's the alternative way to send mail to the maintainer of a package? I don't use that feature every day, but when I use it every couple of months (more frequently at times where teTeX or TeXlive changes affected lots of other packages) I'm happy that I needn't check the maintainer in the control file. @packages.qa.debian.org has two disadvantages: I need to look up the source package name (which isn't hard), and I have to either remember, or be told by a bounce (?), that a special header needs to be included, and look up which in the developer's reference. 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: how to satisfy a patched build-dependency in debuild / pdebuild
Malte Forkel wrote: > Sandro Tosi schrieb: >> A general rule may be: patch upstream source code, not debian packaging file. >> >> Regards, > > Well, my patch is active if its in 00list :-) > > But you're right, adding the dependency to debian/control is safe and > easy. It just "doesn't feel right" to always require a specific library > if its only used in a special configuration. The only remedy I can think > of is to document the relationsship between patch and build dependency > both in the patch and in the changelog. But I'd still prefer to tie the > two functionally rather than verbally. If you were involved in maintaining the Debian package, one approach (besides just branches) could be a script for generating/changing the source package from the repository. The script would generate debian/control from debian/control.in or similar, and adjust the Build-Deps according to the patch state. I once did that for backports. There was a target "etch" (or was it sarge?) in debian/rules; thus you could even switch a source tree unpacked from sid sources, so that next time dpkg-source -b would generate a package for building a backport, including correct changelog entries. 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: texlive restrictive licence in main prevents derived works?
Neil Williams wrote: > It looks like packages that build-depend on tex* will simply not build > on Emdebian Grip - for (of all things) legal reasons - without pulling > the unchanged Debian packages. It means bringing in the massive > Packages.gz file from Debian but then, the texlive dependencies aren't > exactly small. Well, if you tell us which files are needed for, say, docbook-utils, we'd be willing to create a legal package which only contains what's really needed for that. Same for other documentation-generation tools. >> What's the problem with that package? > > Emdebian Grip drops Recommends No problem to lower tl-base's dependency on tl-base-doc to Recommends. But still, what's the problem with downloading and installing a package with Installed-Size: 1216 ? 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: texlive restrictive licence in main prevents derived works?
Neil Williams wrote: > On Fri, 8 May 2009 13:10:02 +0200 > Norbert Preining wrote: > >> > How did that get into main? >> >> Long discussion, please see debian-legal quite some time ago. The point >> is that modifications are allowed but the modifyied work needs to be >> renamed (like with tex the program) as long as the status of the >> packages is "Maintained" plus prominent notices etc. >> http://lists.debian.org/debian-legal/2004/07/msg00079.html >> and many other links. > > OK, it's just a naming thing. Not sure how we can handle that in > Emdebian - renaming isn't automated, at least not currently. Renaming won't work, because it's not about filenames, it's about "identification to the interpreter". In other words, if the license of foo.sty requires it be distributed together with foo.pdf, you are allowed to rename the whole thing to bar, but then bar.sty (or still call it foo.sty if you prefer) must identify itself as "Package bar [$date]", and you'll get "foo was requested, bar was loaded" fatal errors. > Hence why I'd like to understand the problem and work out how Emdebian > can have useful packages like docbook-utils without getting into > problems with tex. I hope there's a different way to go: Identify which TeX/LaTeX styles are really needed by docbook-utils, and then let's create a package just for that. If it's still not small enough, including the docs, then let's start thinking again. What about if $this_is_embedian rm $docfiles in postinst? > It wouldn't be so bad if texlive-base didn't depend (not recommend) > texlive-doc-base. What's the problem with that package? Package: texlive-doc-base Priority: optional Section: tex Installed-Size: 1216 I don't think the dependency's needed - I think it was just because we found it easier to have texlive-base Depend on it, instead of every doc package (which Depend's on texlive-base anyway) Depend'ing on it. 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: Possible mass bug filing: non-doc packages recommending doc packages
Neil Williams wrote: > On Fri, 08 May 2009 11:59:27 +0200 > Frank Küster wrote: > >> Frank Lin PIAT wrote: >> >> > The development documentation for libraries and programming languages >> > should not be installed by the runtime. >> > >> > This probably means that packages like perl, python, texlive... should >> > provide a $foo, $foo-doc and $foo-runtime (or -bin, or lib$foo, or >> > whatever). Other package that needs to depend on that tool should then >> > depend on $foo-runtime. >> >> How could we separate texlive-$foo and texlive-$foo-runtime? >> >> And would it make any sense? While many people install python just >> because an application they want needs the interpreter, users don't >> usually install a TeX system because something needs it - but because >> they want to right texts. > > Not true, I have Very true, had I written what I had in mind: s/users/most users/. >> Only in the special case of software documentation does it happen that >> the documentation is completely written, and the "user" (developer or >> buildd) just needs the "runtime". > > Umm, we have a lot of people writing and building software > documentation in things like docbook And that's good, but it's still a special case. Instead of discussing doc or nodoc, it would be much more valuable if someone could tell us which LaTeX packages are really needed by docbook and similar documentation systems, so that we could taylor a minmal package for that - without a doc dependency. 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: Possible mass bug filing: non-doc packages recommending doc packages
Frank Lin PIAT wrote: > The development documentation for libraries and programming languages > should not be installed by the runtime. > > This probably means that packages like perl, python, texlive... should > provide a $foo, $foo-doc and $foo-runtime (or -bin, or lib$foo, or > whatever). Other package that needs to depend on that tool should then > depend on $foo-runtime. How could we separate texlive-$foo and texlive-$foo-runtime? And would it make any sense? While many people install python just because an application they want needs the interpreter, users don't usually install a TeX system because something needs it - but because they want to right texts. Only in the special case of software documentation does it happen that the documentation is completely written, and the "user" (developer or buildd) just needs the "runtime". 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: Possible mass bug filing: non-doc packages recommending doc packages
Y Giridhar Appaji Nag wrote: > I filed a lintian wishlist bug (#527363) requesting a I/W tag when non > documentation packages recommend documentation packages. That might be a good idea. However, for the texlive packages, we'll just add lintian overrides. > With Install-Recommends being the default, many packages pull in a lot of > associated documentation. These documentation packages are sometimes large > and could be suggested rather than recommended. I noticed different opinions > about such bugs on the BTS (See #504042 that went on to be fixed and #526153 > that was not). I understand that upstream would sometimes like documentation > to be installed alongside the binaries, For many parts of texlive, the license requires binary distributions to be complete. This is why we refused to create separate doc packages for a long time in the past. We have only separated the doc packages after Recommends became installed by default. At least that's how I recall the order of events; I might be wrong, but I think the argument holds nevertheless: We can do the splitting of the docs only because it takes a deliberate action to get rid of them, just as anyone receiving a "complete binary distribution" is able to rm -rf the doc directory. > Would there be any objections to filing minor/wishlist bugs against these > packages? We'll just add wontfix tags, so you might as well not bother to file the bugs against the texlive packages. 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: file permissions on /etc/apt/trusted.gpg
"Eugene V. Lyubimkin" wrote: > The easiest way for me to fix this is to do 'chmod +r > /etc/apt/trusted.gpg' in the cupt's postinst. As this file contains only > public gpg public keys, this should not harm anything. An alternative would be to instruct the user to do the change, if you cannot get agreement with the apt maintainers soon. 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: Linux-libre for Debian Lenny
Russ Allbery wrote: > Ben Finney writes: > >> Okay. So I take it then that you would be against separate packaging >> for Linux-Libre for Debian, and prefer instead to apply all its >> changes to Debian's Linux? > > I know this wasn't addressed to me, but I feel the urge to weigh in. > > I think the removal of even the ability to load non-free firmware is > stupid and self-defeating and certainly don't think that should be done > in Debian, in either the main Linux kernel packages or, for that matter, > in a separate package. Shouldn't that be /non-free firmware/external firmware/? If someone starts writing free firmware for some of the affected devices, it will for sure have to live outside the main kernel tree for a while. Later people will still want to give users the option to use the free firmware or the better tested non-free one. Not that I know of any efforts, or even whether that would be realistic. Just a principle thought. 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: ucf: Diversion of /u/b/ucf by etcgit
Jörg Sommer wrote: >>> But I can get the files dpkg installs in /etc. That's enough for the >>> first step. I don't want to create an AI that does everything right. One >>> step after the other! >> >> No, dpkg installs _nothing_ in /etc for ucf related files > > Right, but your are mixing two different things. NO, you don't seem to understand what ucf is for, and is doing. > (1) I use the > hooks provided by apt to get the original files from the > package In other words, with ucf you get NOTHING, since there are no original files in the package. They are only created temporarily while postinst is run. Regards, Frank -- 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: ucf: Diversion of /u/b/ucf by etcgit
Jörg Sommer wrote: > Right, but when I hook into apt-get, I can get the configuration file > shipped with the packages. You cannot, since the very purpose of ucf is to give dpkg-conffile-like behavior for configuration files *not* shipped in the package. Regards, Frank -- 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: ucf: Diversion of /u/b/ucf by etcgit
Manoj Srivastava wrote:
>> Yes, ucf should not touch the configuration file, because the merge
>> was done by etcgit. When ucf sees the “old” configuration file it's
>> already updated by etcgit. The ucf call is only to let ucf update it's
>> internal database.
>
> ucf only changes the configuration file if the user asks it
> to. And the user, in your scheme, may never even know there is a file to
> be updated -- since you have effectively removed ucf functionality.
>
> This sounds more like etckeeper conflicts with ucf.
>
> I suggest you look more into how to integrate ucf mandated
> changes into etckeeper, rather than just gutting ucf.
>From the little information I have about etcgit and etckeeper, it seems
to me that Manoj is right. It may, however, actually make sense to
divert (or change) ucf to make etc{git,keeper} usable with it: It would
have to commit the file to the correct branch of the repository (and
then update it's own database by doing something similar to what was
proposed originally).
Regards, Frank
--
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: Bug#514751: ITP: pgfplots -- TeX package to draw normal and/or logarithmic plots directly in TeX
OHURA Makoto wrote: > Package: wnpp > Owner: OHURA Makoto > Severity: wishlist > > * Package name: pgfplots > Version : 1.2 > Upstream Author : Christian Feuersanger > * URL or Web page : http://pgfplots.sourceforge.net/ > * License : GPLv3 > Description : TeX package to draw normal and/or logarithmic plots > directly in TeX This package will be included in TeXLive 2008. There's still some way to go until we'll be able to upload those packages - or rather, it's probably quite easy, but there's no one who works on this regularly. Of course I'd prefer your working on TeXLive 2008, but if you do prepare packages for pgfplots, are you willing to keep on maintaining them when TL 2008 is in the archive? TIA, Frank -- 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: Help bts-link be a more effective tool
"Paul Wise" wrote: > Debian TeX Maintainers >texlive-bin One was a typo in the upstream address. The other one, E: pkg=texlive-bin, bug=351672, msg=Does not deals dupes: [http://sourceforge.net/tracker/index.php?func=detail&aid=1425283&group_id=23164&atid=377580] I do not understand. The upstream item exists and has the state Closed, with the comment that there was already an upstream request for this which had been closed already. What should we do about that? Regards, Frank -- 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: SmellyWerewolf.com perfume & make-up discount
Andreas Tille <[EMAIL PROTECTED]> wrote: > On Tue, 25 Nov 2008, Frank Küster wrote: > >> http://christian-morgenstern.de/dcma/Der_Werwolf > > Try > > # apt-get install fortunes-de > $ fortune -m Werwölfe > > to see even the plural version ... > > Hope this makes a funny end to this story Sadly not - after some Perl errors in the postinst Use of uninitialized value in list assignment at /usr/share/perl5/Debconf/Element/Gnome/Multiselect.pm line 18, line 2. Use of uninitialized value within @choices in hash element at /usr/share/perl5/Debconf/Element/Gnome/Multiselect.pm line 55, line 2. I simply get nothing: $ fortune -m Werwölfe $ Is this a bug in your Mail or in the package? 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: SmellyWerewolf.com perfume & make-up discount
Gunnar Wolf <[EMAIL PROTECTED]> wrote: > BTW, I could have also felt Joss' message as a personal attack on my > and my family... Wolf? Werewolf? Family? No way. For those who understand German, here's why not: http://christian-morgenstern.de/dcma/Der_Werwolf The same works in English too, as I've just learned, but then it's not a WERwolf, but a banSHEE (the second english version). 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: Bits from the buildd.debian.org world
Adeodato Simó <[EMAIL PROTECTED]> wrote: > * the role address for the wanna-build team is [EMAIL PROTECTED] > However, a buildd.debian.org pseudo-package has been requested in the > BTS, Many thanks for these improvements, especially the one I cited! 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: SmellyWerewolf.com perfume & make-up discount
Ben Finney <[EMAIL PROTECTED]> wrote: > Steve Langasek <[EMAIL PROTECTED]> writes: > >> On Mon, Nov 24, 2008 at 12:07:53AM +0100, Miriam Ruiz wrote: >> > - The only mention women get in the text is thus through a sexual >> > objetification. >> >> This amounts to concluding that any mention of sexuality is sexual >> objectification of women, which is patently absurd. > > No, the claim isn't that broad. The message specifically discusses > women as objects: it promises they will be “delivered directly at > home”, and the entire message discusses women as some kind of reward > being offered to customers. Undead customers, that is to say. Have fun, 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: DFSG violations: non-free but no contrib
Loïc Minier <[EMAIL PROTECTED]> wrote: > On Mon, Nov 03, 2008, Josselin Mouette wrote: >> Le lundi 03 novembre 2008 à 10:12 +0100, Aurelien Jarno a écrit : >> > I haven't say that because they are not executed on by the CPU they are >> > more free. What I mean is that we have those discussions because they >> > are not executed on the main CPU, which makes them different than other >> > non-DFSG compliant software. Then some people consider that acceptable, >> > some other not. >> This case is very similar to non-free documentation, which is not >> executed on any CPU at all. It sounds bogus to split firmware in a >> specific archive and to not do it for documentation, data, etc. > > Which non-free documentation specifically? e.g. PDF files with a DFSG-free license to them, the document source available as a LaTeX file, but LaTeX will typeset the document using a non-free font. Here, you can even modify the content as you like, you just can't reproduce the original PDF, and it would maybe be hard to make sure that the typesetting still looks nice and readable with a free replacement font with different metrics. 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: [DRAFT] resolving DFSG violations
"Jeff Carr" <[EMAIL PROTECTED]> wrote: > On Sat, Oct 25, 2008 at 09:21, Frank Küster <[EMAIL PROTECTED]> wrote: > >> How can that be? (That is an ernest question) > > Because that's how the hardware works. If you are making a widget and > you need a fpga or hybrid chip of any sort, then you generate a binary > blob using the chip manufacturers tools. So it seems to me that there actually is source: The input files for "the chip manufacturer's tools". Isn't that correct? Then the problem wouldn't be to provide the source, but to have free tools available (and maybe the keys mentioned in some other mail). 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: Bug reports of DFSG violations are tagged ???lenny-ignore????
Romain Beauxis <[EMAIL PROTECTED]> wrote: > Do you claim a PDF file is a binary file, or a program object ? Even if PDF > was a programming language, as proposed in another anwser, it would fall into > the script category, where the executed object is also the source. In most cases, the PDF is not the source. If you want to comply to the ftp-masters' current rules, you could easily extract the text and images from the PDF using the available free tools, and create a LaTeX file from it (or OOwriter if you prefer). It would be some work to re-add the markup, but it would be doable, and you could generate a PDF file from it and ship it in a separate source package, with its LaTeX source. If the PDF is frozen documentation, it's probably worth the effort. If upstream changes the PDF with every new version, you should ask them for their sources instead. 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: [Debian-med-packaging] Bug#503367: plink: file conflict with putty-tools
Teodor <[EMAIL PROTECTED]> wrote: > On Sat, Oct 25, 2008 at 6:21 PM, Charles Plessy <[EMAIL PROTECTED]> wrote: >> Le Sat, Oct 25, 2008 at 06:07:11PM +0300, Teodor a écrit : >>> IMO a simple "Conflicts: putty-tools" is enough. If they provide the >>> same functionality than an "alternative" is better than conflicting >>> with each other. >> >> Hello Tedor, >> >> thanks for the feedback, but this would be against our Policy, because the >> two >> files competing for the same name do not provide the same functionality: > > Yes, it seems to be the case. I'm a newcomer to Debian but IMO this > restriction about "Conflicts" in s10.1 seems a little unpractical. No, on the contrary: It would be very unpractical for users if they had to decide whether they want to do genetic analysis *or* use putty. Let alone admins on multi-user systems. > The > "Conflicts" section of the policy [1] does not specify anything about > the restriction of packages that should conflict on each other *only* > if they provide the same functionality. The *alternative* mechanism is > the most natural way to handle the conflicts between packages that > provide the same functionality. Otherwise, the "Conflicts" directive > could help for packages that doesn't provide the same functionality. No, if the functionality is different, it should be possible to install and use both at the same time. Conflicts are useful if a package takes over files from an other one, or if the maintainers decide that you need to make a choice (e.g. each package providing mail-transport-agent installs /usr/sbin/sendmail and conflicts with the others, because using alternatives would probably lead to madness). 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: [DRAFT] resolving DFSG violations
"Jeff Carr" <[EMAIL PROTECTED]> wrote: > There is hardware, for which to function, will always, for the > lifetime of the equipment, require a firmware blob to operate. This > will always be the case; there will never be a human readable version. > It will never be possible to compile it (with non-free compilers) from > source code. How can that be? (That is an ernest question) The engineers will have some description of what the firmware should do (in terms of what to read and write from which register etc., not only in terms of "initialize communication"), and some rules how to translate these procedures into a binary blob. I doubt the translation needs to be done by hand, instead of by a compiler, but even if it was, wouldn't the software be useful? And couldn't the "description of what the firmware should do" be treated as the source, then? I mean, your argument seems to be "there is no such thing as source for firmware, so we cannot possibly require it". But isn't that description of the function just the source? 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: Bug reports of DFSG violations are tagged ???lenny-ignore????
Kalle Kivimaa <[EMAIL PROTECTED]> wrote: > Would it be a good compromise between SCs #1, #3 and #4 if we made an > exhaustive list of non-free bits in main, and make it our goal that the > list gets smaller between each release and not to add anything to > that list? The last part of the sentence is unrealistic, because the list would only describe the *known*to*be* non-free bits. There are unknown non-free bits already in the archive[1], and there might be some that slip in by new upstream releases. Regards, Frank [1] Our up-upstream has recently started a license auditing and found several, just look at texlive's most recent RC bugs -- 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]
closing bugs for packages no longer in unstable (was: Bug#500607: Debian APT Packages/Sources file(s) contains illegal byte sequences in this package's segment)
Hi, Hilmar Preusse <[EMAIL PROTECTED]> wrote: > I just noticed that tetex-src is only in sarge and etch, hence we > can't remove it from unstable. As we (probably) can't fix it in > stable and it is be fixed in unstable, we have to close the bug, > right? I'm not sure, because we have now version tracking in the BTS. In the versions in etch and sarge, the bug is still present, but there's no new version to close it with. What should we do with this bug? If we just keep it open, what will happen once lenny is oldstable and hence both sarge and etch completely removed from our ftp servers? TIA, 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
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]
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
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 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
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]
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]
Re: Available papersizes vs. default papersizes
Ben Hutchings <[EMAIL PROTECTED]> wrote: > On Sun, 2008-08-03 at 18:44 +0200, Frank Küster wrote: > >> Therefore I asked upstream whether they'd be willing to add more paper >> sizes, and they said they would accept patches. However, they also said >> that they didn't want to bloat the code with information about paper >> sizes which no one will ever use as a system-wide default paper. > > Why does this need to be in code? So long as you only care about > rectangular sizes, it seems like it would be trivial to implement a > configuration file syntax for specifying sizes. Then that would be easy > to extend without "bloat". The only problem is that the configuration file syntax is already there (and has been for more than a decade). And although the lines specifying a paper size are rather simple in most of them, parsing and writing the complete file is hard. On the other hand, there is already upstream code to parse and write these files, and there's even a script which can, in principle, handle the default paper size for at least the three most relevant programs. I don't think it makes sense to reinvent all this. And for sure I'm not going to do it. > >> 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. > > Well, why not? Don't know, but the bottom line is that if I want TeXLive in Debian to support all libpaper-supported sizes, I have to keep a patch, since upstream doesn't like the idea. If I could come up with four or eight "sensible" or "frequently used" ones, I could spare myself the patching. 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]
Available papersizes vs. default papersizes
Hi all, I would like to solve a long-standing bug and finally make TeX aware of libpaper and its system-wide paper size setting. In a way, upstream's configuration scripts already provide most of the infrastructure needed. However, taking the intersection of paper sizes the different program's configuration files accept as default, I end up with a4paper and letter. Therefore I asked upstream whether they'd be willing to add more paper sizes, and they said they would accept patches. However, they also said that they didn't want to bloat the code with information about paper sizes which no one will ever use as a system-wide default paper. On the upstream list, the discussion which papers would make sense as a system-wide default paper did not lead anywhere. Some said that only a4paper and letter make sense (my question whether asian or african countries use nothing else stayed unanswered). 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. Do you have any suggestions? 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: glib inconsistencies in testing
Steve Langasek <[EMAIL PROTECTED]> wrote: > Actually, the bug is that libglib-perl is second-guessing glib's package > dependencies and spitting out warnings that it shouldn't. And it's already reported? Thanks, Frank -- Frank Küster Debian Developer (teTeX/TeXLive) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
glib inconsistencies in testing
Hi, since a couple of days ago, I keep getting this message on a lenny system during the configure phase of (seemingly) arbitrary packages: Setting up samba-common (2:3.0.31-1) ... *** This build of Glib was compiled with glib 2.16.4, but is currently running with 2.16.3, which is too old. We'll continue, but expect problems! findpkg -b -r -v libglib2.0-0 * unstable * Package: libglib2.0-0 Version: 2.16.4-2 Package: libglib2.0-0-dbg Version: 2.16.4-2 * testing * Package: libglib2.0-0 Version: 2.16.3-2 Package: libglib2.0-0-dbg Version: 2.16.3-2 It seems like some package which is frequently used in postinsts declares insufficiently strict dependencies on libglib. Before I start playing around with postinst scripts, is this issue known and reported? Regards, Frank -- Frank Küster Debian Developer (teTeX/TeXLive) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: tarball in tarball: opinions
Joey Hess <[EMAIL PROTECTED]> wrote: > Magnus Holmgren wrote: >> Tarballs using the wrong top-level directory name is nothing that can't be >> worked around. > > dpkg-source does not care what directory (if any) a .orig.tar.gz extracts > into. There's nothing "wrong" about an upstream tarball extracting into > "" instead of "-". Or into ., even. Regards, Frank -- Frank Küster Debian Developer (teTeX/TeXLive) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Generating debian package using cmake (take 2)
"Mathieu Malaterre" <[EMAIL PROTECTED]> wrote: > On Mon, Jun 23, 2008 at 9:57 PM, Frank Küster <[EMAIL PROTECTED]> wrote: >> "Mathieu Malaterre" <[EMAIL PROTECTED]> wrote: >> >>> 3. I was suggested libopensync for cmake/debian package start. >>> 3.1 where is the internal name 'libopensync1exp3' coming from ? what >>> does the '1exp3' stand for ? [...[ > You did NOT even try to make a tiniest effort to understand what I > am doing here. You did NOT even try to make a tiniest effort to understand what Debian is doing here (sonames, package names etc.pp.). Regards, Frank -- Frank Küster Debian Developer (teTeX/TeXLive) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Generating debian package using cmake (take 2)
"Mathieu Malaterre" <[EMAIL PROTECTED]> wrote: > 3. I was suggested libopensync for cmake/debian package start. > 3.1 where is the internal name 'libopensync1exp3' coming from ? what > does the '1exp3' stand for ? You shouldn't try to invent a new system for building packages if you are not familiar enough with Debian Policy to know that yourself. Sorry, but that's how it is. Regards, Frank -- Frank Küster Debian Developer (teTeX/TeXLive) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: ODBC, local changes to config files, and policy
Steve Langasek <[EMAIL PROTECTED]> wrote: > Hi all, > However, this has never been enabled by default because the odbcinst > interface is very basic, with the result that on every upgrade any local > modifications to the config for this driver would be lost. The debconf > question is also not shown at the default priority in order to not clutter > the installation process. [...] > Short of rearchitecting odbcinst to require an exact config match before > update/removal (which would lose us the ability to manage driver config > updates in any case), can anyone suggest a way to enable this by default > while still complying with policy? Am I being more cautious than warranted > in this case where local user changes are concerned? I am in a situation which is somewhat (so not completely) similar, and I am thinking about a solution involving ucf. In you case, you would ship a copy of the configuration file in /usr/share, let the driver logic act on a temporary copy this file, and then install it using ucf. If there are no local changes, it will just be installed. If there are some, the user is asked a question they can probably understand (because the differences involve the driver and the changes they made themselves). You could even use ucf's --three-way option for merging changes. Regards, Frank -- Frank Küster Debian Developer (teTeX/TeXLive) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP: debian-backports-keyring -- GnuPG archive key of the backports.org repository
"Wesley J. Landaker" <[EMAIL PROTECTED]> wrote: > On Saturday 21 June 2008 11:38:07 Roberto C. Sánchez wrote: >> On Sat, Jun 21, 2008 at 07:34:59PM +0200, Holger Levsen wrote: >> > Hi, >> > >> > On Saturday 21 June 2008 15:52, Alexander Wirt wrote: >> > > I'm still not that sure if its a good idea to add a non-offical >> > > debian repo keyring into the archive... >> > >> > Nobody is forced to install it?! >> > >> > And AFAICS we regulary recommend backports.org to users, who need newer >> > software. So I think it should be in. >> >> But backports.org is still unofficial. If it were permitted, then what >> would happen when other unofficial repository maintainers want to >> package their repository keyrings? Will those be allowed or disallowed? > > Maybe a common, group maintained, debian-unofficial-keyring package? Err, no. I might want to trust the maintainers of backports.org to handle their keys well, but not necessarily others. Regards, Frank -- Frank Küster Debian Developer (teTeX/TeXLive) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: too many conflicts/replaces
Nikita V. Youshchenko debian.org> writes: > > > 2008/4/4, Nikita V. Youshchenko debian.org>: > > > Martin Schr?der wrote: > > > > I'm trying to create a package that will when installed > > > > automatically replace all TeX packages on the system with our > > > > version of TeX. > > > > > > Don't all debian tex packages depend, directly or indirectly, on > > > tetex-base or texlive-base? You probably could create your own -base > > > package that conflicts with those, and then pre-depend on it? (Just kind-of-back from vacation, and I don't know whether this has been discussed on debian-texmaint) No, tetex-base is an empty package which hopefully can be removed before lenny is released, and texlive packages depend on texlive-base-bin which also provides the tex and pdftex binaries. > > And then I'd get a conflict when installing that package. > > Why? > > Won't apt-get/aptitude handle proper removal/installation actions for you? I think it would. Unless Martin actually wants a parallel installation? Maybe dpkg's diversions would help here? Martin, which files do you need to replace except the binary and pool files? Regards, Frank -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Configuration Packaging System
Timothy G Abbott MIT.EDU> writes: > > On Mon, 25 Feb 2008, Frank Küster wrote: > > > Uh, you can dpkg-divert conffiles, but not generally configuration files, > > since many won't even be known to dpkg. I must admit I'm a bit sceptical > > about a proposal on configuration, written by someone who lets this > > important distinction slip by... > > No, I really meant configuration files. While our system certainly > applies to all conffiles, it also applies to various other classes of > files: But in these cases you can't use dpkg-divert. > 3) Scripts that are not marked as conffiles but which cannot be configured > in any way other than by modifying the script. If those scripts live below /etc, they definitely should be marked as conffiles. If they live elsewhere, no package should edit them. > I probably should have said this explicitly earlier, but our system is > currently only an 80% solution, because it cannot override any package's > configuration file handling system that does not preserve manual changes. Such a package has a RC bug anyway. > It turns out that these are fairly rare, and can be handled with some > annoyance (e.g. releasing a new version of our configuration package > whenever a new release of such a package comes out, so that the > configuration package wins). Of file a bug... > So, yes, our system uses both symlinks and dpkg-divert. Ah, I understand. I think here you have a much larger problem than with the small number of RC-buggy packages that don't keep manual changes: Larger because I fear there are more packages with such problems, because less people are aware that it is a problem, and maybe even because there might be some debate whether respecting a symlink state actually is required by policy. > One idea [...] > would be for dpkg to run postinst scripts in a special environment that > rewrites filenames according to the diversion database I would rather contemplate a new interface for configuration packages, something like a hook which has to be executed by each postinst script and allows the configuration package to bring its settings into effect. If you want to be able to remove configuration packages, the original file needs to be preserved somehow, but the current dpkg-divert is not sufficient for this: Consider someone installing the configuration package in stable+0, then upgrading to stable+1 and keeping it, and then upgrading to stable+2 and subsequently removing the configuration package. Any special code in the maintainer scripts which dealt with incompatible conf(iguration )file changes in the stable-to-stable+1 upgrade is likely to have been removed by now, so the old, incompatible, file from stable+0 will be used after the removal, and the package is in a broken state. Regards, Frank -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Configuration Packaging System
Timothy G Abbott MIT.EDU> writes: > Anders Kaseorg and I created a system of CDBS modules (which we've > tentatively packaged as the config-package-dev package) for creating > Debian configuration packages. By configuration packages, we mean > packages that configure an existing Debian system by applying dpkg-divert > to configuration files. Our configuration package system makes the > process of creating configuration packages efficient. Uh, you can dpkg-divert conffiles, but not generally configuration files, since many won't even be known to dpkg. I must admit I'm a bit sceptical about a proposal on configuration, written by someone who lets this important distinction slip by... Later on you wrote something about symlinks, do you use them, too? Here's one more complication: While I think that "preserve local changes" also includes the symlink-or-not state of a file and thus must be respected by maintainer scripts, I do not think that this is usually done. In particular, every configuration file handling that was first written for sarge (where sed -i wouldn't work) probably used tempfiles and mv, and I have not seen a single case where the script checked whether it was dealing with a symlink. [...] > Since this package is adding a new feature to Debian itself, we think our > system should be discussed before we submit an ITP bug. There are some > changes to Debian that would enhance the effectiveness of this system, > (such as having all packages include md5sums and making ucf interact well > with dpkg-divert'ed configuration files), which should perhaps be > discussed in this context as well. It's not just ucf, it's also perfectly possible that a maintainer script edits a configuration file, e.g. after debconf prompting, in order to take over user changes from a related package's configuration file, or similar. How do you deal with that? Regards, Frank -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Binaries with the same name
sean finney debian.org> writes: > while i don't have any specific knowledge or interest in the details of this > particular problem, i'd just add since you haven't mentioned it as an > alternative that you could always Conflict with the package in question while > waiting for a resolution. This is not possible; it would be a RC bug: /--- Policy 10.1 | Two different packages must not install programs with different functionality | but with the same filenames. (The case of two programs having the same | functionality but different implementations is handled via "alternatives" or | the "Conflicts" mechanism. \--- Regards, Frank -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to deal with bugs from removed packages?
Martin Michlmayr cyrius.com> writes: > In > the past, I closed all bug reports from packages that were removed. > Some people were unhappy about this but it was the best solution we > had. This changed with the introduction of version tracking. The > idea now is to close them with a fake version number that is higher > than the version that was removed (maybe something like version+removed). I don't think these bugs should be closed without considering the type of the removed package. If it's just gotten useless or uninteresting, no problem. But if there's some kind of successor (like foo2 in a new source package, iceweasel to firefox, or TeXLive to teTeX) then the maintainer should check whether the old bug still applies to the new package. Regards, Frank -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Correct spelling/capitalisation of project names
Maybe also something along tetex -> teTeX Tetex -> teTeX TeTeX -> teTeX (but any mention of teTeX, bless its memory, is probably a bug anyway) tex[-]*live -> TeX Live TeX[-]*live -> TeX Live TeX[-]*Live -> TeX Live and even TEX[^tT] -> TeX which may give many semi-false positives: Lots of things not relating to TeX, but still without shouty capitals in the correct form. Regards, Frank -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposalto introduce compiler options passed from dpkg-buildpackage
Manoj Srivastava debian.org> writes: > > On Wed, 5 Dec 2007 21:11:53 +0100, Matthias Klose cs.tu-berlin.de> said: > > > IIRC we cannot assume that debian/rules is a makefile and pass them as > > macros directly, so we have to pass them as environment variables. > > I think you remember incorrectly. Policy currently states [...] > This file must be an executable makefile, Indeed - but there's a bug, #432564, requesting to change it. Regards, Frank -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What to do when the LaTeX sources are missing, but an XML equivalent was rewritten from scratch ?
Don Armstrong debian.org> writes: > > On Mon, 19 Nov 2007, Norbert Preining wrote: > > On Mo, 19 Nov 2007, Joerg Jaspert wrote: > > > > - the source is present, no freedom is taken: The document is present, > > > > the source code. > > > > - the pdf can be regenerated albeit with minor quality. > > > > > > Thats different to "relies on not-available fonts". > > > Relies == cant be build without them. > > > > Recreating the exact same pdf (modulo creation date etc) relies on these > > fonts. Recreating the same document with different fonts, and thus with > > different layout and appearance is possible. > > Then why distribute the original PDFs at all in that case? Because the purpose of the document is to show the differences between several (free as well as non-free) fonts, and help the user make a choice. > Just > distribute the recreations. You're going to have to distribute them at > some point if bugs in the documentation are filed, so you might as > well just start distributing them. Many packages have enough important bugs, plus a good relation to a quickly reacting upstream, that this won't happen. You fix the important bugs in Debian revisions, but wait for documentation patches to come in with a new upstream version. Regards, Frank -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian-infrastructure-announce (was: dupload failed)
Holger Levsen layer-acht.org> writes: > > So why should I subscribe to an additional list? > > Because not every infrastructual bit should/needs to be announced on d-d-a?! I didn't see any infrastructure announcement so far on d-d-a that should not have been there. Furthermore - although I agree that one thing that would improve the DSA team would be more communication, I'm sure there are more important things (like: promptly replying to requests) than announcing porter machine outages, no matter where. > Obviously, if ftp-master is down, this needs to go to d-d-a. But if the 3rd > amd64 porter machine or the swedish debian mirror is offline for 6h due to > scheduled maintainance, this doesnt need to go to d-d-a. But it's nice to > have on the infrastructure list. I don't care it being on a list, as long as http://db.debian.org/machines.cgi is up-to-date. Regards, Frank -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
debian-infrastructure-announce (was: dupload failed)
Kevin Mark verizon.net> writes: > > On Thu, Nov 08, 2007 at 10:08:30PM +0100, Christoph Haas wrote: > > On Thu, Nov 08, 2007 at 10:06:01PM +0100, SZALAY Attila wrote: > > > I couldn't upload my package into the incoming queue with dupload > > > because I could not connect to ftp-master.debian.org on port 21 and 22. > > > > ftp-master is temporarily out of service. See > > debian-devel-announce l.d.o > > > > Christoph > > There is a new list: debian-infrastructure-announce lists.debian.org > Where something like this would be listed, also, in the future. Err, and what exactly is the reason for this? d-d-a isn't exactly overloaded, and availability of debian infrastructure is something every DD and maintainer should know about. It's also not like it would create a problem if we got more frequent status mails from DSA in the future. So why should I subscribe to an additional list? Regards, Frank -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#449317: ITP: zekr-quran-translations-ur -- Zekr Quran Urdu translations
brian m. carlson crustytoothpaste.ath.cx> writes: > > On Sun, Nov 04, 2007 at 10:10:58PM -0500, Mohammad Derakhshani wrote: > >Package: wnpp > >Severity: wishlist > >X-Debbugs-CC: debian-devel lists.debian.org > > > >* Package name: zekr-quran-translations-ur [...] > > There is no authenticity or correctness warranty for these > > translations. For more information please read the provided > > /usr/share/doc/zekr-quran-translations-ur/README.txt file. > > Disclaimers are most appropriate in the copyright file, not in the > package description. The package description should provide only enough > information for one to decide whether or not to install the package. If > the correctness of the translation is so doubtful as to be useless, then > perhaps the translation should not be packaged at all. I am a christian, but I imagine that with regard to your holy texts, things are not so different: The information whether a translation is officially endorsed by some authority (and by which) might be very relevant for many users, and help them to decide whether to install the package or not. Regards, Frank -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Interpreting testing excuses
Hi, we are wondering why texlive-base and texlive-bin don't enter testing, and I fail to understand the output of the update excuses at http://bjorn.haxx.se/debian/testing.pl?package=texlive-base http://bjorn.haxx.se/debian/testing.pl?package=texlive-bin We have not (at least not that I remember...) changed any of the versioned interdependencies of the texlive packages, so I don't understand why the two seem to require going in at the same time at all. And then, why are there those long lists of packages that become uninstallable if they would enter testing? How can I find out why the scripts think that, and find out whether there's a real issue? TIA, Frank -- Frank Küster Debian Developer (teTeX/TeXLive)
Re: making debian/copyright machine-interpretable
Joerg Jaspert <[EMAIL PROTECTED]> wrote: > On 11139 March 1977, Frank Küster wrote: > >> - Packages are buggy, even copyright files are. We should add a >> machine-readable field that indicates that the rest of the machine-readable >> information might not be correct or complete. > > Thats the default mode, always. Well, but not every package has a bug like #218105. Regards, Frank -- Frank Küster Debian Developer (teTeX/TeXLive)
Re: making debian/copyright machine-interpretable
Hi, Sam Hocevar zoy.org> writes: > On Sat, Aug 04, 2007, Joey Hess wrote: [initial comment moved here to fool gmane's "you seem to be top-posting" message] I've come across this intersting thread only today (I was without network access in early August). Although I haven't read everything, it seems like one point has not been raised. If you answer, please Cc me since I'm not subscribed to any Debian list except debian-tex-maint at the moment. > > * I don't see much benefit in putting freeform text at the top of the > > file. Keeping it all at the bottom would simplify parsing/validating. > >I tend to agree with you. The first version used to be like this, > and I got many suggestions for adding freeform text at the beginning > in order to keep the file human-readable so I switched to allowing it > everywhere. I'll wait for more comments on why it may be useful, but the > paragraph below about tarball origin seems already a valid use case. Note that machine-readable copyright files might get very long (tetex-base in etch has more than 1400 lines, most of which are in our poor-man's machine-readable format, but that covers only a subset of the files in the package). Therefore I think we should either allow freeform text at the top of the file, or at least a field that indicates "Hey, it might be worth scrolling down to the end". Two more points: - Packages are buggy, even copyright files are. We should add a machine-readable field that indicates that the rest of the machine-readable information might not be correct or complete. Reasons might be "Upstream acknowledges that the license information in subdir foo/ is partly incorrect/nonfree and is working on relicensing or replacing the code, lenny-ignore tag granted" or "This package is a compilation of software from various sources. The integration work done by upstream is Copyright 2006 Alice Aiken, 2005&2006 Bob Brown, but the upstream license file does not indicate which files were altered or added by them. The list of these files was prepared by the Debian maintainer and might be incomplete". These reasons can be given in free form, but there should be a machine-readable field to indicate that such information exists. - looking at tetex-base's copyright file, I notice that we keep more per-filepattern information in it. This is probably not needed for most packages, but it should be possible to easily add it in case it is useful. It could e.g. go into a notes field, whose content is not necessarily machine-readable, but clearly assigned to a particular filepattern stanza. tetex-base uses * 3.4 List of licenses of individual parts % abstract: lppl (verification data:1.1:1.1:2006-02-08:norbusan:) tex/latex/abstract/* doc/latex/abstract/* % acronym: lppl (verification data:1.26:1.17:2006-03-07:frank:header) tex/latex/acronym/* doc/latex/acronym/* * which indicates that one part of tetex-base is the abstract CTAN package, which is under the lppl[1], and since this information is not in the teTeX license file, we also note that: The current version of abstract is 1.1, the license info was verified by norbusan (Norbert Preining) for version 1.1 on 2006-02-08, and he didn't note in which file in the abstract package the license information can be found. For acronym, I did the verification, but there's a newer upstream version (1.26) now, and I noted that the info is not in a particular file, but in the headers of the individual source files. I suggest that there should be a Notes: field. We would use it to indicate the name of the part as used in the TeX Catalogue (were we keep the license information) and the info in parentheses. TIA, Frank [1] by the way, should we discriminate between LPPL-1.3a, LPPL-1.3b, and things like LPPL-1+ and LPPL-1.2+ (versions 1.2 or older were not DFSG-compatible, but of course any software with an "or later" clause are acceptable)? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: menu policy & use of doc-base for programming documentation
Stefano Zacchiroli debian.org> writes: > > On Thu, Aug 30, 2007 at 03:19:43PM -0400, Eric Cooper wrote: > > The Debian OCaml maintenance team is looking at how to organize the > > HTML documentation provided by the various OCaml packages. Our first > > Right, to add some details to that: > - each library we have (will) ship an HTML documentation of the API, > generated with ocamldoc (the equivalent of javadoc). Such > documentation will be installed as /usr/share/doc/PACKAGE/html/api/ > - we just want to have a global HTML index which contain a listing of > all the library we ship as simple HTML links to the above pieces of > documentation > > If possible we would like to avoid reinventing the wheel, and doc-base > seems to be the right tool; it's just to restrictive: why should its > categories be tight to the menu categories? We have a similar problem with TeX documentation. In my opinion, using menu categories for doc-base might have been a good start, but we should definitely extend that now. I'm currently in semi-VAC mode and don't have time to discuss this or even check the archives - but if I remember right, the problem is that there is no one who really maintains doc-base. Regards, Frank -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: adding desktop files to misc packages
Josselin Mouette <[EMAIL PROTECTED]> wrote: > Le jeudi 26 juillet 2007 08:25 +0200, Frank Küster a écrit : > >> Could you give guidelines how a maintainer of an application should >> classify their app, > > Using categories described in [0] is a good start. The maintainers would > also have to agree on new categories if the ones listed are not > sufficient. To me, these categories look very poor, I really wouldn't want the well-structured debian menu (note that I'm talking about the new Debian menu, not the default menu for etch) to be replaced by anything like this. To me, it rather looks like it doesn't make sense to add additional ones, given that we already have something much better. Moreover, this doesn't answer my question at all, but I was probably unclear. What I meant was "How (do you think) should a maintainer decide whether a particular application is marked as "not for Gnome", or "not for desktop environments", or such. I wanted something more general than "Python should be hidden", "switching windowmanagers should be hidden", because it's hard to discuss whether this hiding thing makes sense when I have no idea what you think should be hidden, except some special examples. > On the > contrary, NotShowIn should be used if similar functionality is available > in one or several environments and displaying an icon would only be a > source of confusion. Okay, that makes sense - a frontend to setxkbmap shouldn't have a menu entry when there's a specific tool for customizing the keyboard for the desktop environement. That's the type of general guideline I'd like to see, but this particular one won't catch many applications. > For applications that aren't useful in the general case, NoDisplay=3Dtrue > should be set. Let me show an example: gstreamer-properties used to have > an icon in the menu. In current releases, the appropriate sinks to use > (esd, alsa, etc.) are autodetected which means there is no *need* for > users to launch it, and this allowed us to set NoDisplay=3Dtrue. The same > should hold for configuration dialogs that are specific to an > application and already available from it. That also makes sense, but here I would argue that those shouldn't have a menu entry at all. >> and how Gnome would decide which classes to hide? > > ConsoleOnly, Shell, Screensaver, X-WindowManager are good candidates. We > could also exclude things like FileManager as nautilus is always > launched, for example.=20 ACK > Sound judgement should do the rest. I'm sceptical about that. Up to this discussion I didn't even have an idea that people might want to hide things from the menu, and I still don't feel I understand exactly what and why you want to hide. But it's going to be the package maintainers like me who assign these classes, so we'd better give them some guidelines. One guideline could be "if there's an application for doing $foo that's provided by the desktop environment, only show this one". Maybe that is what you applied when you suggested to not display other file managers besides Nautilus. However, I don't think this is a good rule in general: If both $gnome_wordprocessor and openoffice.org-writer are installed, I'm sure it would confuse users if there was no menu entry for openoffice.org-writer. Or, nearer to my own packaging work, if someone starts to learn LaTeX, and all they find in the menu to look at DVI files is evince or kdvi or similar, while everyone in the LaTeX community only talks about xdvi (and for a reason). Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: adding desktop files to misc packages
Andreas Tille <[EMAIL PROTECTED]> wrote: > I really wonder whether this concept of user roles are really that strange > or stupid that all posters seem to ignore this idea. (Feel free to teach > me in private to keep silent with those stupid ideas.) Personally, I think it's probably a very good idea. Maybe I'd even like to switch between different types of users (oh, ideally even different users in different workspaces at the same time). I imagine that the reason why no one responds to this suggestion is that the discussion is very focused: The friends of the complete Debian menu on the one hand, and the advocates of a "newbie friendly" desktop environment - and those newbies (I think) are generally believed to use their computer for "home office" work, from writing a letter and web browsing to listening to music and managing their photos. But in fact, I think a user can both be a newbie to Linux (and even to serious computer usage) and still have a quite focused interest, be it "administration of a non-profit organization", a particular field of science, game development, ... Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: adding desktop files to misc packages
Josselin Mouette <[EMAIL PROTECTED]> wrote: > Le vendredi 27 juillet 2007 03:52 -0700, Steve Langasek a écrit : >> > In the end, the people who know whether an application should be given >> > tags that will exclude it from certain menus are the application's >> > maintainers, not the menu systems maintainers. So far they have been >> > reasonable about what is included in the menu, and I have no reason to >> > think this wouldn't remain like that. >> >> In that case, I guess I'm confused, because I had the impression that you >> were still opposed to migrating the existing Debian menu to use the >> freedesktop standard. > > Sorry, that wasn't clear: people are currently reasonable with what they > include in the *freedesktop* menu. Do you mean the menu as shown by desktop environments like gnome, or the menu as specified by the set of .desktop files? > I'm not fond of the idea of > converting the Debian menu entries because it will lead to including all > that's currently in the *Debian* menu, which is not reasonable. I still don't understand what you want: Is it particular categories that you want to hide, or is it the sheer number of applications, and the fact that there are going to be multiple applications for (approximately) the same task, that bothers you? Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: adding desktop files to misc packages
Josselin Mouette <[EMAIL PROTECTED]> wrote: > Le vendredi 27 juillet 2007 à 03:52 -0700, Steve Langasek a écrit : >> > In the end, the people who know whether an application should be given >> > tags that will exclude it from certain menus are the application's >> > maintainers, not the menu systems maintainers. So far they have been >> > reasonable about what is included in the menu, and I have no reason to >> > think this wouldn't remain like that. >> >> In that case, I guess I'm confused, because I had the impression that you >> were still opposed to migrating the existing Debian menu to use the >> freedesktop standard. > > Sorry, that wasn't clear: people are currently reasonable with what they > include in the *freedesktop* menu. Do you mean the menu as shown by desktop environments like gnome, or the menu as specified by the set of .desktop files? > I'm not fond of the idea of > converting the Debian menu entries because it will lead to including all > that's currently in the *Debian* menu, which is not reasonable. I still don't understand what you want: Is it particular categories that you want to hide, or is it the sheer number of applications, and the fact that there are going to be multiple applications for (approximately) the same task, that bothers you? Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: adding desktop files to misc packages
Josselin Mouette <[EMAIL PROTECTED]> wrote: > Meanwhile, real world people have moved to the freedesktop menu, which > despite its flaws is more flexible, more beautiful and allows a better > structure designed for each environment. Tell me, in which world do I live if its not the real world? Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: adding desktop files to misc packages
Josselin Mouette <[EMAIL PROTECTED]> wrote: > Le mercredi 25 juillet 2007 à 19:35 +0200, Frank Küster a écrit : >> >> Menus, by their nature, are inherently unusable for the most frequently >> >> used apps, and we should not be trying to make them more usable at the >> >> expense of making less frequently used apps harder to access. >> > >> > Why shouldn't we attempt to make menus usable? >> >> Because, as Marvin wrote in the text you cite, the drawback is that it >> makes less frequently used applications harder to access. > > If an application is used so infrequently, it shouldn't have its place > in a menu. It seems we have a very different notion of what a menu is. To me, the reply "Exactly because it is used infrequently it should have its place" is obvious and follows strictly from my understanding of a menu, I don't even need an argument for that. To you, it seems to be the contrary. > Furthermore, in the case a user needs it more often, he can > add it to the menu. This becomes even easier if the menu entry is only > hidden, not absent. But it seems to be harder than adding it to the toolbar/dock/whatever. >> But I agree with Marvin (and that's also my usage scheme) that menus >> should provide access to the less frequently used applications, not the >> ones started very often. I don't have toolbars in my WM, but it starts >> the frequently used apps without asking me, so I use the menu for the >> rare ones. > > This is also my usage scheme: everyday apps in the session, less > frequently used apps in the menu, rarely used apps in a terminal or a > launching tool. I don't make this distinction between "less used" and "rarely used", and I'm not even sure what a launching tool is. I nearly never start a graphical application from the terminal, and I don't need to be able to start terminal applications from the menu: For me that is the only reason for deciding whether something should have a (possibly hidden) menu entry. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: adding desktop files to misc packages
Gabor Gombas <[EMAIL PROTECTED]> wrote: > IMHO the best would be a uniof of the two viewpoints: show everything by > default, and gradually hide entries that were not used for some time. Or > did Microsoft patent that? The result being that if I use the application again for work of type B after only using it for type A for three weeks, everything that is only used for B will be hidden. No, thanks. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: adding desktop files to misc packages
Josselin Mouette <[EMAIL PROTECTED]> wrote: > Le mercredi 25 juillet 2007 à 16:17 -0400, Marvin Renich a écrit : >> My original message was specifically concerned with graphical apps. I'm >> not sure which console apps should be displayed; for the most part, I >> think the Debian maintainer should decide whether it deserves to be >> displayed by default. > > I still disagree. The policy should enforce detailed tagging that allows > window managers and menu systems maintainers to filter out entries they > don't want to display. ACK >> Window managers *definitely* should be displayed. If I went to the >> trouble of installing sawfish in addition to metacity, I would like to >> be able to use both. Yes, from the menu. > > Sorry, but the menu is not a holdall where we put all functionality that > we don't know where to put without thinking a few minutes. > > A window manager choice has nothing to do in an application menu, as it > is not an application. This is a matter for a configuration tool, > whatever form it takes. The Debian menu has more Categories than just applications. In particular, it has a category for window managers. If you desktop environment guys want to go a different way and hide this category (and instead allow for window manager switching somewhere else, like some control center) that's fine. But that doesn't say that window managers shouldn't have a menu file, or .desktop if that is going to be its successor. >> > Why shouldn't we attempt to make menus usable? >> >> I didn't say we should not make them usable, I said we should not try to >> make them more usable *by reducing access to less frequently used apps*. > > As things are, even with the best possible menu system one can imagine, > you won't manage to make a menu with 500 entries as usable as one with > 100. Could you give guidelines how a maintainer of an application should classify their app, and how Gnome would decide which classes to hide? >> > Guess what, toolbars are not used by a good share of users. > >> Also, my experience is that a good share of less-technically-oriented- >> but-comfortable-using-a-computer users actually do use toolbars. > > These affirmations are not contradictory. I don't deny that many users > make use of their toolbar, but I think we should keep the menu usable > for users who don't. I don't use a toolbar, but for me "usable" means that everything is there... Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: adding desktop files to misc packages
Mike Hommey <[EMAIL PROTECTED]> wrote: > On Wed, Jul 25, 2007 at 09:56:11PM +0200, Frank Küster <[EMAIL PROTECTED]> > wrote: >> Mike Hommey <[EMAIL PROTECTED]> wrote: >> >> > On Wed, Jul 25, 2007 at 01:50:20PM -0500, Steve Greenland <[EMAIL >> > PROTECTED]> wrote: >> >> On 25-Jul-07, 13:28 (CDT), Josselin Mouette <[EMAIL PROTECTED]> wrote: >> >> > If an application is used so infrequently, it shouldn't have its place >> >> > in a menu. >> >> >> >> That turns out not to be the case. If I use an app frequently, then it >> >> goes on the toolbar. The menu is for finding infrequently used apps. For >> >> a lot of users, browsing the menu is how they find out what's available. >> > >> > IIRC, gnome is going to switch to gnome-main-menu. There is a reason for >> > this. >> >> What does that mean? What is gnome-main-menu? > > apt-get install gnome-main-menu. That won't help unless I start Gnome, which I won't. > http://reverendted.wordpress.com/2007/02/14/show-me-that-updated-gnome-main-menu/ I haven't watched the whole video (it being boring to me), but from the reading I still don't understand which of my statements you want to contradict, let alone why. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
