Bug#671120: debian-policy: suggest delegating binary name conflicts to tech-ctte in last resort
Hi, in 2012 there was a consensus, and this bug was filed. In 2014 there was a single mail w/o reply (possibly because this bug needed a patch, not yet another discussion), but no consensus. In 2016 this bug was closed under wrong assumptions. In 2018 or later this bug might be filed again, hopefully with a patch. * Bill Allombert [2014-03-23 16:56 +0100]: > On Wed, May 02, 2012 at 12:13:22AM +0200, Carsten Hey wrote: > > Package: debian-policy > > Severity: wishlist > > > > Please suggest delegating binary name conflicts to the tech-ctte in last > > resort. > > Anything can be delegated to the tech-ctte. I do not think policy need to > mention it. Different wording for "we do not force both binary names to be changed" are welcome^W^Wwill be welcome. > > * Russ Allbery [2012-05-01 10:28 -0700]: > > > Carsten Hey <cars...@debian.org> writes: > > > > > > > The origin of what the policy suggests to do if there is no consensus is > > > > a mail from Guy Maor <879142cjni@slip-61-16.ots.utexas.edu>, in > > > > which he writes: > > > > | That's basically a stick to force developers to reach a consensus. > > > > > > > Christian Schwarz uploaded this change later in this month. > > > > > > > I don't think that there ever will be a consensus in all those > > > > discussions without discussing in a reasonable way (which failed in the > > > > past multiple times). Previously to this, asking the VP of Engineering > > > > for a decision was suggested in this thread. > > > > > > I have to admit that I'm tempted to change Policy from "if there's no > > > consensus, rename both of them" to "if there's no consensus, try harder to > > > reach a consensus, and the technical committee decides in last resort." > > > > "technical committee decides in last resort" could be read as if it > > would decide without being consulted. To avid such a misreading, > > a clearer wording that for example uses the word 'consulted' could be > > used. > > > > Besides this minor nitpicking, it would be great if the policy could be > > adapted as described in the quoted mail. > > > > > Most of the time, renaming both of them isn't the right answer. > > > > I'm even unable to imagine a case where renaming both would be the right > > answer. > > Whenever the unqualified name become ambiguous. This is not the original intention of this paragraph (which not necessarily means that it's not reasonable or valid). There are consensual transitions of binary names between packages, and there are conflicting binary names without any consensus among the maintainers - Russ and I talked about the latter, and Bill's mail reads as if he had both cases in mind. > If a package name is used in one release, it cannot change purpose in the next > release, there needs some transition period. That's very often, possibly almost always, a sane way to handle such transitions. I wonder if node was handled this way four years ago. Anyway, I can imagine cases where it's reasonable to have no transition period, and more importantly, dictating higher level designs by specifying low level implementation details in the policy not only feels wrong - especially if these higher level design issues aren't mentioned in the policy at all. > An example is git transition: Since git was already used as a package name, > both GNU IT and Linus git were renamed for one release. Regards Carsten
Bug#824346: sort(1): misleading description of option -n
You both misread my mails, and I partly misread Michael's mail, which
lead to discussing things we all are aware of.
The intention of this $'x 10\nx 9' example was to show how people only
knowing the man page, but not POSIX or the info manual would use, and
actually do use, the option -n.
A real world example of such a useless use of -n, taken from
backuptool.sh shipped with some Android firmware images is:
# Execute /system/addon.d/*.sh scripts with $1 parameter
run_stage() {
for script in $(find /tmp/addon.d/ -name '*.sh' |sort -n); do
$script $1
done
}
And a reason why some people think this would work is for this is that
“compare according to string numerical value” is ambiguous. A less
ambiguous replacement could be “compare according to string initial
numerical value”, but I assume there are way better ways to describe
this.
These are a lot of mails and words for such a small change …
* Bob Proulx [2016-05-14 14:55 -0600]:
> Carsten Hey wrote:
> > reopen 824346
>
> But you forgot to terminate the command with 'thanks' or 'stop' and
> therefore the entire rest of your message went to the control robot
> generating many parse errors.
I did. I remembered that it would also work w/o this line, but not the
reason. Assuming that the reason was that empty lines would stop
processing input obviously was wrong - the reason was that parse errors
are ignored and finally also lead to stop processing input.
> … Things seem to be going okay. Then you trip over a snag. You fall
> down. You shout, "Who put that snag there! Someone is going to pay
> for this!" And then go looking for something to blame for it.
AFAIK I never had such an error in a script, but I see such errors from
time to time in other scripts.
Carsten
P.S.: I appreciate your fast and comprehensive answers, even if we were
talking past each other
P.P.S.: A misconfigured router somewhere in the internet might be the
reason that my mail did not hit the list: “(conversation with
eggs.gnu.org[208.118.235.92] timed out while sending end of
data -- message may be sent more than once)”
Bug#824346: sort(1): misleading description of option -n
In case "proving" that I know how to use this simple program helps, the following lines are equivalent, but the second one does not contain the GNUism '-s': LC_ALL=C sort -r -s -k 1.3,1.4 grep -F -n '' | LC_ALL=C sort -t : -k 2.3r,2.4r -k 1n | cut -d : -f 2-
Bug#824346: sort(1): misleading description of option -n
reopen 824346 Looks like this bug even influenced you, i.e., you wrongly assume that GNU sort behaves as documented in sort(1), instead of comparing the _initial_ numeric strings of each line, as required by POSIX and implemented all around (including GNU coreutils). <http://pubs.opengroup.org/onlinepubs/9699919799/utilities/sort.html>: | -n Restrict the sort key to an initial numeric string, consisting | of optional characters, optional minus-sign, and zero | or more digits with an optional radix character and thousands | separators (as defined in the current locale), which shall be | sorted by arithmetic value. An empty digit string shall be | treated as zero. Leading zeros and signs on zeros shall not | affect ordering. * Michael Stone [2016-05-14 15:25 -0400]: > On Sat, May 14, 2016 at 08:15:18PM +0200, Carsten Hey wrote: > >This description reads as if this command: > > > > $ printf '%s\n' 'x 9' 'x 10' | sort -n > > x 10 > > x 9 > > > >… would produce the output of this command: > > > > $ printf '%s\n' 'x 9' 'x 10' | sort -V > > x 9 > > x 10 > > > >…, but instead, -n stops doing its magic after finding the first > >non-numeric, non-whitespace character. There is a short and simple > >way to summarize this behaviour. > > That's because you're attempting a numeric sort on the entire line, If that would be true, this would not work: $ printf '%s asdf\n' 10 9 | sort -n 9 asdf 10 asdf … and it would instead have the output of this command: $ printf '%s asdf\n' 10 9 | sort 10 asdf 9 asdf > which is a string rather than a number. If the line consisted of > only numbers, it would do what you expect: I know how this works, the documentation is wrong. > >printf '%s\n' '9' '10' | sort -n > 9 > 10 > > If you want to sort on the second field, then you need: > > >printf '%s\n' 'x 9' 'x 10' | sort -k2,2n > x 9 > x 10 Thanks, again, I know how this works, I do not need any related support. Regards Carsten
Bug#824346: sort(1): misleading description of option -n
Package: coreutils Given that the forwarded mail did not reach the bug-coreutils mailing list and that http://lists.gnu.org/archive/html/bug-coreutils/2016-05/msg00030.html contains: | I did something very similar in parallel, but somehow the email didn't | reach the list: this silly bug-coreutils thing seems to have some issues … Anyway, the description of the option -n in sort(1) is at best incomplete, see forwarded mail: - Forwarded message from Carsten Hey <cars...@debian.org> - Date: Sat, 14 May 2016 16:17:35 +0200 From: Carsten Hey <cars...@debian.org> To: bug-coreut...@gnu.org Subject: sort(1): misleading description of option -n Hi, the man page sort(1) contains a misleading description of the option -n: $ lsb_release -ic Distributor ID: Debian Codename: jessie $ sort --version | sed -n 1p sort (GNU coreutils) 8.23 $ man sort | grep -A1 -- --numeric-sort | sed -n -e 's/^ *//' -e '1!p' compare according to string numerical value According to Ubuntu's web page, this string is also in their package coreutils_8.25-2ubuntu2_i386. This description reads as if this command: $ printf '%s\n' 'x 9' 'x 10' | sort -n x 10 x 9 … would produce the output of this command: $ printf '%s\n' 'x 9' 'x 10' | sort -V x 9 x 10 …, but instead, -n stops doing its magic after finding the first non-numeric, non-whitespace character. There is a short and simple way to summarize this behaviour. If you use Cyanogenmod on your mobile phone, you carry a minor programming error in your pocket that is very likely caused by this misleading description of -n. Regards Carsten - End forwarded message -
Bug#823534: apt-get remove is unhelpful for virtual packages
Hi, * Richard Stallman [2016-05-05 14:48 -0400]: > Package: apt > Version: 1.0.1ubuntu2.13+7.0trisquel3 > > I tried to remove a package which is virtual, specifically nethack. > apt-get told me it could not do this, but said nothing about > what to do. "apt-cache showpkg mail-transport-agent" lists "Reverse Provides:", but it does not show which m-t-a is installed. Maybe this is worth an additional bug report? > It would surely be easy to make it handle a virtual package by > seeing which real package provides it, and offering to delete > that one. I see three possible ways to address this issue: 1. Offering to delete the real package, as rms wrote. apt-get would then, for instance, ask "... Would you like to remove postfix instead? [yN]". This might or might not be useful for /usr/bin/apt, but I hope apt-get will stay as non-interactive as it has always been. 2. Provide a more useful output. A good example is the output of apt-get _install_ virtual-package on jessie: # apt-get install mail-transport-agent Reading package lists... Done Building dependency tree Reading state information... Done Package mail-transport-agent is a virtual package provided by: opensmtpd 5.7.3p2-1 ... exim4-daemon-heavy 4.84.2-1 You should explicitly select one to install. E: Package 'mail-transport-agent' has no installation candidate 3. "Do What I Mean" (DWIM) - on IRC, it has been suggested to remove the real package if there is only one provider. Assume that the packages foo and bar are installed, that foo is not available via an apt repository anymore, and that bar provides foo. "apt-get remove foo" would then remove foo the first time it is run and it would remove bar the second time it is run. I wouldn't consider this to be an intuitive behaviour. At least I try to remove packages I removed previously from time to time (although I know that I already removed them). And I don't think I'm the only one who occasionally runs "apt-get install pkg1 pkg2- pkg3-", and then presses the up key and appends additional package names in order to save some key presses. > Alas. I can't reproduce this now, or show you the output, > because I no longer have those packages installed. On stable, the according output is: # apt-get remove mail-transport-agent Reading package lists... Done Building dependency tree Reading state information... Done Virtual packages like 'mail-transport-agent' can't be removed The following packages were automatically installed ... I noticed that the 'Virtual packages ...' line vanishes if stdout is piped through, e.g., cat and wonder if this is done deliberately. Regards Carsten
Bug#819793: c-n-f: uses ancient c_n_f_handle as c_n_f_handler
Package: command-not-found Severity: important c-n-f uses an ancient c_n_f_handle as c_n_f_handler. Since this leads, depending on the sets of installed, purged and removed but not purged packages, to a silently failing wipe command, you might want to add a security tag to this bug. Launchpad contains all relevant details for this bug and answers to all related questions I can imagine, hence please see there for further details in case you need them. Recent Ubuntu c-n-f packages contain fixed versions of c_n_f_handle and c_n_f_handler, please merge and adapt these. You might need to add an option to your program that is equivalent to the one used in Ubuntu's c_n_f_handle. Not ignoring me on IRC would have saved me from dgetting this cra^Wpackage you uploaded yesterday and from writing this mail.
Bug#815158: debhelper: dpkg-maintscript-helper is not portable among recent shell releases
I don't know which real world problems, if any, are caused by the
different ways the shells parses those lines. Figuring this out and
discussing it would require more effort than doing the requested code
cleanup, i.e., replacing `` with $().
* Carsten Hey [2016-02-19 15:36 +0100]:
> Package: debhelper
> Serverity: minor
>
> Hi,
>
> recent releases of yash and mksh follow POSIX' wording regarding
> backslashes in backquotes, the other shells follow POSIX' presumable
> intention and the historically correct behaviour, for example (run on
> Debian stable):
>
> $ bash -c 'echo "`echo \"x\"`"'; yash -c 'echo "`echo \"x\"`"'
> x
> "x"
>
> In debhelper's git repository, these lines, using the above-mentioned
> non-portable pattern, can be found:
>
> autoscripts/preinst-moveconffile: if [ "`md5sum \"#OLD#\" |
> sed -e \"s/ .*//\"`" = \
> autoscripts/preinst-moveconffile:"`dpkg-query -W
> -f='${Conffiles}' #PACKAGE# | sed -n -e \"' #OLD# '{s/ obsolete$//;s/.*
> //p}\"`" ]
>
> Given that Debian does not care about shells from about 1970, the most
> obvious fix is to use $() instead of ``. This would also improve the
> code's readability.
>
>
> Regards
> Carsten
Bug#815158: debhelper: dpkg-maintscript-helper is not portable among recent shell releases
Package: debhelper
Serverity: minor
Hi,
recent releases of yash and mksh follow POSIX' wording regarding
backslashes in backquotes, the other shells follow POSIX' presumable
intention and the historically correct behaviour, for example (run on
Debian stable):
$ bash -c 'echo "`echo \"x\"`"'; yash -c 'echo "`echo \"x\"`"'
x
"x"
In debhelper's git repository, these lines, using the above-mentioned
non-portable pattern, can be found:
autoscripts/preinst-moveconffile: if [ "`md5sum \"#OLD#\" |
sed -e \"s/ .*//\"`" = \
autoscripts/preinst-moveconffile:"`dpkg-query -W
-f='${Conffiles}' #PACKAGE# | sed -n -e \"' #OLD# '{s/ obsolete$//;s/.*
//p}\"`" ]
Given that Debian does not care about shells from about 1970, the most
obvious fix is to use $() instead of ``. This would also improve the
code's readability.
Regards
Carsten
Bug#815134: python: please quote backslash in prerm-clean
Package: python Severity: minor Hi, on Debian stable (please close if already fixed in sid): $ fgrep ' \' /usr/share/debhelper/autoscripts/prerm-pyclean dpkg -L #PACKAGE# | grep \.py$ | while read file The \ is not passed to grep, instead it is used to quote the . in the shell. Correct would be: dpkg -L #PACKAGE# | grep \\.py$ | while read file Or even better: dpkg -L #PACKAGE# | grep '\.py$' | while read file To test shell quoting, these commands can be used: printf '%s\n' \. printf '%s\n' \\. printf '%s\n' '\' Carsten P.S.: IMHO “read -r” would make more sense than “read”
Bug#796848: debianutils: Missing dependency on awk
* Croxell, Jeffrey [2015-08-24 22:23 +]:
> Package: debianutils
> Version: 4.4+b1
> Severity: important
> Tags: d-i
>
>* What led up to the situation?
>Using cdebootstrap-static with a limited local mirror.
>The local mirror included 'gawk'.
>It appeared to be a race condition - gawk installed after debianutils.
>Adding 'mawk' allows debianutils to install successfully
>* What exactly did you do (or not do) that was effective (or
> ineffective)?
> Added mawk to local mirror.
>* What was the outcome of this action?
>Mawk by chance gets installed first
>* What outcome did you expect instead?
>Since debianutils 'add-shell' uses 'awk' it should have an explicit
>dependency on awk
awk is used to append missing newlines in the file's last line.
The (pre-)dependencies of the essential packages on each other
and on awk are complicated, but in theory (i.e., if debootstrap and
cdebootstrap would be that smart), adding a dependency on awk would
work for now. Just for the record, either the policy or the consensus
among Debian developers says that dependencies on awk are not required.
If add-shell would create a missing /etc/shells on its first invocation
(I think it should, because of “… core functionality of essential
packages …” and “… avoiding dependencies between essential packages …”),
then a (pre-)dependency on awk wouldn't help at all since the shells
could drop their dependencies on debianutils.
Instead of adding this dependency, I think add-shell should use an
alternative to “awk '{print}'” instead.
Ways to append missing newlines to a file read from stdin with only
essential packages and their dependencies installed include:
* awk '{print}'
* sed "\$a\\" # shellcheck complains if single quotes are used
* grep '^'
* a hundred ways to do this in Perl
* paste
* a shell loop using read -r and printf (error prone implementation)
Embedded people might remove Perl and paste, doing this in a shell loop
would be ugly and awk is pre-dependency of an essential package, but not
essential itself. The remaining tools are sed and grep. I'd tend to
grep since add-shell already uses grep. I wonder if grep '^' and
sed "\$a\\" are guaranteed to work as I expect or if this behaviour
is either undefined or buggy in some implementations.
Carsten
Bug#293879: debianutils: which should cannonicalize the path
I thought that this bug report would be about the behaviour of which
if PATH is unset, but this is not true.
A clean fix for this unfilled bug would require “getconf PATH” (getconf
is in libc6-bin) to return the PATH bash and dash use, and ideally the
other shells to adapt.
* Justin Pryzby [2005-02-14 15:49 -0500]:
> On Mon, Feb 14, 2005 at 09:31:50PM +0100, Thomas Hood wrote:
> > On Sun, 2005-02-13 at 09:59 -0500, Justin Pryzby wrote:
> > > On Sun, Feb 13, 2005 at 12:14:43PM +0100, Thomas Hood wrote:
> > > > To canonicalize a path use "readlink -f". E.g.,
> > > As requested, it wouldn't follow symlink names.
> >
> > jdthood@thanatos:/tmp/w$ ls -l
> > total 0
> > lrwxr-xr-x 1 jdthood jdthood 4 2005-02-14 21:30 usr -> /usr
> > jdthood@thanatos:/tmp/w$ realpath -s //tmp//w//usr
> > /tmp/w/usr
> >
> >
> > You should be able to use something like:
> >
> > dpkg -S $(realpath -s $(which foo))
> I think sed also provides that functionality, as does Bash, I'm sure.
> Since I don't want it to follow symlinks, I think the only
> canonicalization needed is s+//+/+g.
ELEMENT=${ELEMENT%/} would be sufficient to solve the original issue,
i.e., remove the final slash of /usr/sbin/ if $PATH matches
“*:/usr/sbin/:*”.
Whether this is a good idea is an other question, and Clint already
wrote that he doesn't think so.
Carsten
Bug#797017: screen: terminfo hack in /etc/screenrc confuses terminfo's upstream (was: terminfo status line for screen-s)
Hi Axel,
* Axel Beckert [2015-08-27 10:53 +0200]:
Carsten Hey wrote:
People that do not know what a hardstatus is, would just have tried
alwayslastline and succeeded, but a terminfo upstream knows such things.
Yeah, so that bug affects exactly one very knowledgable person ...
this bug affected exactly two people that we are aware of. When I used
screen the first time I was pretty sure that I did not have such
a thing (even though I did not know what it was), but I tried
alwayslastline nevertheless.
Actually this bug started as mail to Thomas Dickey (the question he had
in order to test some screen-s terminfo foo was not answered previously),
but then I noticed that Debian does unexpected things that are not
documented in a way I would have expected it.
... while it adds a nice feature for all others?
I agree that this is a feature some user consider to be useful.
The behaviour is nevertheless different than that of every other
(non-debian based) distribution and people use the same configuration
file on different operating systems. But screen's default behaviour
is also different if you switch from xterm to urxvt or vice versa.
If the behaviour will not be changed, we should think about improving
documentation.
This feature is based on the misuse of some terminfo magic (a titlebar
is no hardline) due to a lack of a proper way to express that one can
change the titlebar. Documenting such a misuse of terminfo magic in
screen(1) does not seem to be the right approach.
There is an alternative hardstatus in /etc/screenrc. The comment above
the setting does not match the default behaviour in Debian (fixing this
would at least a tiny improvement):
# An alternative hardstatus to display a bar at the bottom listing the
# windownames and highlighting the current windowname in blue. (This is only
# enabled if there is no hardstatus setting for your terminal)
#
#hardstatus lastline %-Lw%{= BW}%50%n%f* %t%{-}%+Lw%
README.Debian suggests that people ask how to disable this and that
even the former Maintainer does not know any useful answer that does
not involve becoming root
c) Using hardstatus alwayslastline solves the issue perfectly and
has no other use in xterm anyway.
Then README.Debian should be updated accordingly:
[imagine some diff magic here] (the first three lines are unchanged)
Debian Modifications
* added Debian package maintenance files
Debian Modifications
* added Debian package maintenance files
* added system wide configuration file /etc/screenrc
[imagine some diff magic here] (the first four lines are unchanged)
the /etc/screenrc or you can override it in your personal screenrc by
adding
the following line:
hardstatus alwaysmessage
[imagine some diff magic here]
the /etc/screenrc or you can override it in your personal screenrc by
adding
the following line:
hardstatus alwaysmessage
If you prefer to use the terminals last line to display the hardstatus,
or if you don't want the hardstatus to be displayed at all, use one of
these lines instead:
hardstatus alwayslastline
hardstatus alwaysignore
Those lines have to appear after all other lines that configure the
hardstatus, if any.
And /etc/screenrc should mention /usr/share/doc/screen/README.Debian.gz:
[imagine some diff magic here]
# Set the hardstatus prop on gui terms to set the titlebar/icon title
[imagine some diff magic here]
# Set the hardstatus prop on gui terms to set the titlebar/icon title.
# To override it in ~/.screenrc, see /usr/share/doc/screen/README.Debian.gz
(Which reminds me of https://bugs.debian.org/400111, a request to add
a status line by default.)
tscreen used (I don't like the colors, and such a thing should fit into
the color prompt design of the default interactive shell, i.e., bash):
hardstatus alwayslastline '[^^ac]: New window [^^an]: Next window [^^ad]:
Disconnect [^^aq]: Quit'
caption always %?%{yk}%-Lw%?%{wb}%n*%f %t%?(%u)%?%?%{yk}%+Lw%?
... and it explicitly binded q and ^Q to quit due to the hardstatus line
used.
Anyway, some people use caption and hardline, other use one of them, and
there is no way to avoid the need to edit all ~/.screenrc files on all
accounts (at least on machines they have no root permissions) for some
people.
I still think that extending the copyright screen to be able to install
a recommended .screenrc is the way to go, it just needs to be done (and
fixing such an old bug is all but urgent). If there would not be such
a copyright screen, then I wouldn't know a sensible solution for this.
So this is not really a final wontfix, but I'm not yet convinced
that this line really causes harm.
With proper documentation this line would be fine (and I'd consider this
bug to be closed), if you consider that there is no way to make the
behaviour sane in all cases due to the terminfo hardstatus
Bug#797017: screen: terminfo hack in /etc/screenrc confuses terminfo's upstream (was: terminfo status line for screen-s)
Package: screen
Hi,
in Debian's /etc/screenrc some termcap/terminfo capabilities for xterm
are set (screen seems to always use termcap names in config files):
termcapinfo xterm*|rxvt*|kterm*|Eterm* hs:ts=\E]0;:fs=\007:ds=\E]0;\007
... and accordingly screen thinks that the terminal supports a hardstatus:
screen(1):
| ... if the terminal doesn't have a hardstatus line (i.e. the
^ missing comma
| termcap/terminfo capabilities hs, ts, fs and ds are not set).
... and therefore wrongly requires hardstatus alwayslastline to be
used instead of hardstatus lastline:
screen(1):
| If you prepend the word always to the type (e.g., alwayslastline),
| screen will use the type even if the terminal supports a hardstatus.
... which confused Thomas Dickey, whilst he was trying to improve the
terminfo status line for screen-s:
https://lists.gnu.org/archive/html/bug-ncurses/2014-11/msg1.html:
... Looking for clues in screen(1), I tried adding
hardstatus lastline
to my ~/.screenrc, but saw no difference.
People that do not know what a hardstatus is, would just have tried
alwayslastline and succeeded, but a terminfo upstream knows such things.
So... what configuration details can you provide to help me test
(and document) this change?
For testing purposes (if still relevant), you can also enable
hardstatus interactively:
- start screen (press enter if you see the copyright notice)
- press CTRL-a
- paste this into the terminal (without the leading spaces):
:hardstatus alwayslastline %{= gk} .. oo OO
- press return
Possible fixes for this bug:
1. Convince Thomas Dickey, or whoever is responsible for such things,
to add a new terminfo capability that indicates that the terminal
is able to set the window's titlebar. Then wait until screen and
other tools use this in a proper way ...
2. Disable this setting and confuse other Debian users that expect
this hack.
README.Debian suggests that people ask how to disable this and that
even the former Maintainer does not know any useful answer that does
not involve becoming root ('add hardstatus alwaysmessage' is as
useful as 'use tmux instead').
A feature people want to remove and that can not (easily) be
disabled in ~/.screenrc but can easily be enabled in ~/.screenrc
does not belong to the system wide screen rc file. Adding it to
a recommended ~/.screenrc for new users, if such a file ever will
exist, could be reasonable.
Carsten
Bug#792703: zsh: please improve newuser.zshrc.recommended and add new prompt_debian_setup
* Carsten Hey [2015-08-13 12:02 +0200]: I attached a new prompt_debian_setup and an RCS format diff between the former one and this one. Unconditionally using zstyle or other things available in zsh modules only does not make that much sense for the intended purpose ... I already adapted the vcs_info part of the prompt accordingly and will send a new version after I also updated the other parts. Regards Carsten
Bug#792703: zsh: please improve newuser.zshrc.recommended and add new prompt_debian_setup
Hi,
I attached a new prompt_debian_setup and an RCS format diff between the
former one and this one.
The zstyle pattern now is :prompt:debian:${HOST-}:${USERNAME-}:${TERM-}:
in order to implement a variant of the suggested terminal blacklist in
future. The final : allows additional future extensions, if needed.
Additional configurable things would make the prompt more complex, thus
I skipped implementing them for now (the suggested ones and additional
ones can be implemented later). Franks other suggestions and some minor
changes are applied to the new prompt_debian_setup.
I think a recommended Debian .zshrc should also work on other systems,
at least in future releases of other Linux distributions. Therefore,
submitting this prompt_debian_setup upstream would be great, but only
a Debian zsh maintainer would be able to say We plan to add this prompt
to the Debian zsh package and enable it in the recommended .zshrc for
new users. Please consider applying this patch.. According to the
channel topic, the zsh 5.0.9 release is expected to happen soonish.
Carsten
# debian prompt theme
prompt_debian_help () {
cat 'EOF'
This prompt color-scheme-able via zstyle. If the variabale TERM is set to
'dumb', colors are disabled, though. You can invoke the prompt thus:
prompt debian
TERM=dumb prompt debian
To configure the prompt's colors, this command can be used (don't forget to
run 'prompt debian' again to activate the changes):
zstyle ':prompt:debian:*' STYLE COLOR
You need to replace STYLE with 'dircolor', 'usercolor', 'usercolor-root',
'exitcolor' or 'exitcolor-root'. Valid values for COLOR include the numbers
from 0 to 7, 'black', 'red', 'green', 'yellow', 'blue', 'magenta', 'cyan' and
'white'.
Displaying version control information via vcs_info and displaying the name of
a Debian chroot is supported by this prompt, but only the latter is enabled by
default. To enable vcs_info with the user-context 'prompt_debian', run:
add-zsh-hook precmd prompt_debian_precmd_vcs_info
To disable vcs_info even if the vcs_info command is run, and to enable
it again, zstyle can be used as shown in the two lines below.
The other two lines enable checks for uncommited changes.
zstyle ':vcs_info:*' enable NONE
zstyle ':vcs_info:*' enable ALL
zstyle ':vcs_info:*' check-for-staged-changes true
zstyle ':vcs_info:*' check-for-changes true
To add additional information to the prompt, e.g., the history event number or
the number of background jobs and the shell level, this commands can be used.
The content of the 'nvcsformats' style is only shown if vcs_info is used, but
no version control system repository was found.
PROMPT='%B!%!%b '$PROMPT
zstyle ':vcs_info:*' nvcsformats '%B%F{green}%(1j.j%j .)%(2L.L%L .)%b%f'
EOF
}
prompt_debian_precmd_vcs_info () {
setopt localoptions no_xtrace
vcs_info prompt_debian || return $?
}
prompt_debian_setup () {
setopt localoptions no_errexit no_errreturn
prompt_opts=(cr subst percent)
local zstyle_pattern=:prompt:debian:${HOST-}:${USERNAME-}:${TERM-}:
local dir_max_length='60'
local dir_max_elements='5'
local wrap_at_char='-25'
local p_exit='${${options[printexitvalue]#on}:+%0(?..%? )}'
local p_dir=%${dir_max_length}...%$(( dir_max_elements + 1
))(~:.../:)%${dir_max_elements}~%
local p_space_or_newline=%${wrap_at_char}(l: :${prompt_newline})
local p_vcsinfo='${vcs_info_msg_0_-}'
local p_reset='%b%f%k'
local p_2nd_newline=%1(l:%${wrap_at_char}(l..${prompt_newline}):)
if [[ ${TERM-} == dumb ]]; then
PROMPT=$p_exit\${debian_chroot:+(\$debian_chroot)}%n@%m $p_dir
PROMPT+=$p_space_or_newline$p_vcsinfo$p_reset$p_2nd_newline%#
else
# color config:
local exitcolor exitcolor_root usercolor usercolor_root dircolor
zstyle -s $zstyle_pattern exitcolor exitcolor ||
exitcolor='red'
zstyle -s $zstyle_pattern exitcolor-root exitcolor_root ||
exitcolor_root='green'
zstyle -s $zstyle_pattern usercolor usercolor ||
usercolor='green'
zstyle -s $zstyle_pattern usercolor-root usercolor_root ||
usercolor_root='red'
zstyle -s $zstyle_pattern dircolor dircolor ||
dircolor='blue'
PROMPT=%B%{%0(#:%F{$exitcolor_root}:%F{$exitcolor})%}$p_exit
PROMPT+=%{%F{$dircolor}%}\${debian_chroot:+(}
PROMPT+=%{%0(#:%F{$usercolor_root}:%F{$usercolor})%}\${debian_chroot-}
PROMPT+=%{%F{$dircolor}%}\${debian_chroot:+)}
PROMPT+=%{%0(#:%F{$usercolor_root}:%F{$usercolor})%}%n@%m
PROMPT+=%{%F{$dircolor}%}$p_dir%b%f
PROMPT+=$p_space_or_newline$p_vcsinfo$p_reset$p_2nd_newline%B%#%b
fi
# Only try
Bug#794967: zsh: please enhance /etc/zshrc
Hi,
running zsh -u leads to this warning message:
/etc/zsh/zshrc:14: DEBIAN_PREVENT_KEYBOARD_CHANGES: parameter not set
(My answer to Don't do that is If this is not allowed, zsh should not
accept -u for interactive shells.)
The fix is to replace lines 14 and 15 with:
if [[ -z ${DEBIAN_PREVENT_KEYBOARD_CHANGES-} ]]
[[ ${TERM-} != 'emacs' ]]
* Frank Terbeck [2015-08-08 23:46 +0200]:
Carsten Hey wrote:
[...]
* (( ${+aliases[run-help]} )) requires the zsh/parameter module. If,
in rare cases, possibly involving zsh-static, there is a chance that
this module is not loaded successfully, you should consider doing
this instead to remove the alias w/o error message:
alias run-help=
unalias run-help
That's a good point. I think we can do it like this:
unhash -a -m 'run-help' || true
...
We could also just do this:
unalias run-help 2/dev/null || true
…if that's more straight-forward to read.
We agreed on using unalias -m, not unhash -m. Whether the argument
should be quoted is in this case just a matter style, personal
preferences and syntax highlighting.
The '|| true' is to make sure the setup file exits with successful
status.
If it is sourced with errexit set, or if someone removes the final line
(which might not be that unlikely) and sources this file, appending '||
:' or '|| true' (the former is a POSIX special builtin, but zsh seems to
ignore this difference) actually makes a difference, and for the errexit
case it would not be sufficient to make the final command return 0.
During shell startup errexit is ignored in /etc/zsh/zshrc. I don't
know whether the exit status of /etc/zsh/zshrc could matter.
I also don't know why anybody would source /etc/zsh/zshenv, but
appending '|| :' just in case someone does seems to be sensible.
Could anybody with commit access please replace the old unalias line
with one of lines below?
unalias -m 'run-help' || :
unalias -m 'run-help' || true
unalias -m run-help || :
unalias -m run-help || true
This bug actually is about the bindkey stuff we don't agree on, and
I don't consider this robustness fixes to sufficient to close the bug
(YMMV and you are free close this bug anyway). Maybe it could be tagged
as wontfix to document that we don't agree currently.
Carsten
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#794968: zsh: please clear console on logout (if recommended config is used)
* Carsten Hey [2015-08-09 18:05 +0200]:
Pasting the code that would be part of the recommended .zlogout could
help to clarify some things, but there's still a GPL'd triviality in it.
Without the GPL'd trivial check of being a subshell - i.e., this test
needs to be added before it can be shipped, a ~/.zlogout could look like
this:
if [[ -z ${SSH_CONNECTION-}${TMUX-}${debian_chroot-} ]]
[[ ${0##*/} != (-su|su) -x /usr/bin/clear_console ]]
then
/usr/bin/clear_console || :
fi
The first line is mainly used to avoid accessing the hard disk and
spawning a new process in some common cases - only the check for an
empty ${debian_chroot-} might be required, depending on the actual
implementation of schroot et al.
Also using [[ ${TTY-} != /dev/pts/* ]] would avoid running clear_console
in other cases and possibly make checking ${SSH_CONNECTION-} and
${TMUX-} obsolete.
Carsten
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#794968: zsh: please clear console on logout (if recommended config is used)
Hi Axel, * Axel Beckert [2015-08-09 16:57 +0200]: Carsten Hey wrote: * Axel Beckert [2015-08-09 16:12 +0200]: Carsten Hey wrote: Please clear console on logout if the recommended config for new users is used. ... Ok, thanks for the clarification. I'm mostly annoyed by such behaviour upon remote logins via SSH as usually the whole terminal history gets lost in such cases. I wonder if you still think that it's annoying if you know, that it only clears a console if, and only if, the parent process is /bin/login. Does SSH use /bin/login by default? (IIRC not.) SSH does not use a console but a pseudo terminal, even if it is invoked from a console (and even if this would not be true in rare cases, the check to avoid spawning a new subprocess if SSH_CONNECTION is set would avoid running clear_console anyway). Therefore the screen would never be cleared when returning from an SSH session. I assume this answers your actual question. So if it's really just for the Linux (or FreeBSD or Hurd :-) virtual console, I'm fine with it. You might remember that I asked you if you had physical access to a kFreeBSD box. Now you know what I wanted to test ... There it indeed makes sense. Just not for SSH logins ... This would not be console ;) ... or calling zsh or zsh -l This could be described as subshell (i.e., the parent process is a shell) and therefore clear_console would not be run. Pasting the code that would be part of the recommended .zlogout could help to clarify some things, but there's still a GPL'd triviality in it. Carsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#794968: zsh: please clear console on logout (if recommended config is used)
Hi Axel, * Axel Beckert [2015-08-09 16:12 +0200]: Carsten Hey wrote: Please clear console on logout if the recommended config for new users is used. Why? This is a very annoying behaviour IMHO and definitely shouldn't be a default. at first we should make sure that you are talking about the same console as I do: I consider everything that runs in X not to be a console, but the thing you get if you press for example Ctrl-Alt-F1 is a console. It is indeed a very annoying behaviour if it isn't implemented correctly, bash's implementation isn't significantly better than adding (( $RANDOM % 2 )) clear to ~/.bash_logout. I'm sure that the people that maintain the possibly best interactive shell in the possibly best Linux distribution are able to implement this in a way that is not completely broken ;) I wonder if you still think that it's annoying if you know, that it only clears a console if, and only if, the parent process is /bin/login. If a user wants to have such a behaviour because he considers to be a security feature (I don't), ... If you still consider what I requested to be annoying (I think I should have made the intension and how it should behave more clear), I could grep bash's changelog for the bug number of the bug that contains the same discussion, which might save some time. ... the user should configure that in his user's configuration. It's about the (recommended) user's configuration, no one will ever add this to a *global* zsh config file that is shipped with Debian. Carsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#792703: zsh: please improve newuser.zshrc.recommended and add new prompt_debian_setup
A new prompt_debian_setup that no longer tries to mimic adam1 is
attached.
I think #setopt no_beep and #stty -ixon should also be added to
newuser.zshrc.recommended, but maybe we should concentrate on the
prompt for now.
# debian prompt theme
prompt_debian_help () {
cat 'EOF'
This prompt color-scheme-able via zstyle. If the variabale TERM is set to
'dumb', colors are disabled, though. You can invoke the prompt thus:
prompt debian
TERM=dumb prompt debian
To configure the prompt's colors, this command can be used (don't forget to
run 'prompt debian' again to activate the changes):
zstyle ':prompt:debian:*' STYLE COLOR
You need to replace STYLE with 'dircolor', 'usercolor', 'usercolor-root',
'exitcolor' or 'exitcolor-root'. Valid values for COLOR include the numbers
from 0 to 7, 'black', 'red', 'green', 'yellow', 'blue', 'magenta', 'cyan' and
'white'.
Displaying version control information via vcs_info and displaying the name of
a Debian chroot is supported by this prompt, but only the latter is enabled by
default. To enable vcs_info with the user-context 'prompt_debian', run:
add-zsh-hook precmd prompt_debian_precmd_vcsinfo
To disable vcs_info even if the vcs_info command is run, and to enable
it again, zstyle can be used as shown in the two lines below.
The other two lines enable checks for uncommited changes.
zstyle ':vcs_info:*' enable NONE
zstyle ':vcs_info:*' enable ALL
zstyle ':vcs_info:*' check-for-staged-changes true
zstyle ':vcs_info:*' check-for-changes true
To add additional information to the prompt, e.g., the history event number or
the number of background jobs and the shell level, this commands can be used.
The content of the 'nvcsformats' style is only shown if vcs_info is used, but
no version control system repository was found.
PROMPT='%B!%!%b '$PROMPT
zstyle ':vcs_info:*' nvcsformats '%B%F{2}%(1j.j%j .)%(2L.L%L .)%b%f'
EOF
}
prompt_debian_precmd_vcsinfo () {
setopt localoptions noxtrace
vcs_info prompt_debian || return $?
}
prompt_debian_setup () {
prompt_opts=(cr subst percent)
local zstyle_pattern=:prompt:debian:${HOST:-unknown}:${USERNAME:-unknown}
local pwd_max_length=60
local pwd_max_subdirs=5
local wrap_at_char='-25'
local p_exit='${${options[printexitvalue]#on}:+%0(?..%? )}'
local p_pwd=%${pwd_max_length}...%$(( pwd_max_subdirs + 1
))(~:.../:)%${pwd_max_subdirs}~%
local p_space_or_newline=%${wrap_at_char}(l: :${prompt_newline})
local p_vcsinfo='${vcs_info_msg_0_-}'
local p_reset='%b%f%k'
local p_2nd_newline=%1(l:%${wrap_at_char}(l..${prompt_newline}):)
if [[ ${TERM-} == dumb ]]; then
PROMPT=$p_exit\${debian_chroot:+(\$debian_chroot)}%n@%m $p_pwd
PROMPT+=$p_space_or_newline$p_vcsinfo$p_reset$p_2nd_newline%#
else
# color config:
local dircolor= usercolor= usercolor_root= exitcolor= exitcolor_root=
zstyle -s $zstyle_pattern dircolor dircolor
zstyle -s $zstyle_pattern usercolor usercolor
zstyle -s $zstyle_pattern usercolor-root usercolor_root
zstyle -s $zstyle_pattern exitcolor exitcolor
zstyle -s $zstyle_pattern exitcolor-root exitcolor_root
: ${dircolor:=4} ${usercolor:=2} ${usercolor_root:=1}
: ${exitcolor:=1} ${exitcolor_root:=2}
PROMPT=%B%{%0(#:%F{$exitcolor_root}:%F{$exitcolor})%}$p_exit
PROMPT+=%{%F{$dircolor}%}\${debian_chroot:+(}
PROMPT+=%{%0(#:%F{$usercolor_root}:%F{$usercolor})%}\${debian_chroot-}
PROMPT+=%{%F{$dircolor}%}\${debian_chroot:+)}
PROMPT+=%{%0(#:%F{$usercolor_root}:%F{$usercolor})%}%n@%m
PROMPT+=%{%F{$dircolor}%}$p_pwd%b%f
PROMPT+=$p_space_or_newline$p_vcsinfo$p_reset$p_2nd_newline%B%#%b
##TODO uncomment if setopt transientrprompt works in a prompt function
## Ease copying multi-line commands with the mouse.
## http://www.zsh.org/mla/workers/2015/msg01767.html
#local rps2color=$dircolor
#setopt transient_rprompt
#PS2='${${options[singlelinezle]#off}:+%_ }'
#RPS2=${RPS2:-%B%{%F{$rps2color}%}%^%f%b}
fi
# Only try to set $debian_chroot if it is unset.
if [[ ! ${debian_chroot+set} -r /etc/debian_chroot ]]
then debian_chroot=$( /etc/debian_chroot || :)
fi
# Autoload and configure vcs_info:
# The format strings 'formats' and 'actionformats' should end with a space
# to fit into the prompt's design.
# Colors: 1:=red, 2:=green, 3:=yellow, 4:=blue, 5:=magenta, 6:=cyan, ...
autoload -Uz vcs_info
if [[ ${TERM-} == dumb ]]; then
zstyle ':vcs_info:*:prompt_debian:*' formats '[%s|%b%c%u] '
zstyle ':vcs_info:*:prompt_debian:*' actionformats '[%s-%a|%b%c%u] '
zstyle ':vcs_info:(sv[nk]|bzr):prompt_debian:*' branchformat '%b:%r'
zstyle ':vcs_info:*:prompt_debian:*' stagedstr '(S)'
zstyle ':vcs_info:*:prompt_debian:*'
Bug#792703: zsh: please improve newuser.zshrc.recommended and add new prompt_debian_setup
[ dropping #756138 again from CC, people reading
it should now know that there is a related bug ]
Hi Frank,
thanks a lot for you insightful feedback :)
I noticed, that I should add a note how to disable displaying the name
of a debian chroot (i.e., set it to or unset it).
* Frank Terbeck [2015-08-08 17:28 +0200]:
Carsten Hey wrote:
[...]
I think #setopt no_beep and #stty -ixon should also be added to
The latter might better be replaced by zsh's no_flow_control option.
Indeed, setopt no_flow_control is much better.
[...]
This prompt color-scheme-able via zstyle. If the variabale TERM is set to
'dumb', colors are disabled, though. You can invoke the prompt thus:
prompt debian
TERM=dumb prompt debian
You could also check something like a blacklist style, that could be a
list of term names (or better yet, patterns). That way you could
blacklist $TERMs like emacs for colours as well.
Looks like emacs used to set TERM to dumb (see #143361), but this might
have changed. Anyway, the blacklist is a great idea, the default
blacklist would currently contain emacs and dumb.
zstyle ':prompt:debian:*' STYLE COLOR
Hmm, even if * matches :, this could be changed to ':prompt:debian:*:*'
(one * for the host name and one for the user name).
PROMPT='%B!%!%b '$PROMPT
zstyle ':vcs_info:*' nvcsformats '%B%F{2}%(1j.j%j .)%(2L.L%L .)%b%f'
Maybe use a name rather than a number here: %F{green}
At least for the examples shown in the help text %F{green} is much more
readable.
local pwd_max_length=60
local pwd_max_subdirs=5
local wrap_at_char='-25'
Maybe make these configurable via styles?
It was configurable, but I assumed that nobody would care about being
able to configure this and removed it again - looks like I was wrong.
The additional file I attached contains a part of what is required to
make it configurable via styles, just in case I'll need it in the
future. I'll also add local enable_exit_status=1 again in order to
make this configurable too.
# color config:
local dircolor= usercolor= usercolor_root= exitcolor=
exitcolor_root=
zstyle -s $zstyle_pattern dircolor dircolor
zstyle -s $zstyle_pattern usercolor usercolor
zstyle -s $zstyle_pattern usercolor-root usercolor_root
zstyle -s $zstyle_pattern exitcolor exitcolor
zstyle -s $zstyle_pattern exitcolor-root exitcolor_root
: ${dircolor:=4} ${usercolor:=2} ${usercolor_root:=1}
: ${exitcolor:=1} ${exitcolor_root:=2}
To set defaults you can do:
zstyle -s $zstyle_pattern dircolor dircolor || dircolor=4
And again, maybe rather use names instead of numbers:
zstyle -s $zstyle_pattern dircolor dircolor || dircolor=blue
You also don't need to initialise to the empty string in the local
above.
zstyle -s ... || dircolor=... looks a lot cleaner than what I had.
I'm undecided, but easily convincible, whether color names or numbers
should be used in a string that users won't see (unless they do print -r
-- $PROMPT and try to understand the output), given that the numbers
are shorter.
##TODO uncomment if setopt transientrprompt works in a prompt
function
## Ease copying multi-line commands with the mouse.
## http://www.zsh.org/mla/workers/2015/msg01767.html
#local rps2color=$dircolor
#setopt transient_rprompt
I don't understand this. transientrprompt can — and IMO should be —
set outside a prompt setup.
Without transient_rprompt, the painless multiline copying won't work and
therefore there would be no reason to set PS2 and RPS2 accordingly.
I assume one has to read the linked thread to fully understand what the
purpose of this four lines is (or try it interactively).
Alternative approaches are:
* setting PS2 and RPS2 and expecting the user to set transient_rprompt
(which is fine for a default .zshrc, but might not be the best idea
if used in a hand-written .zshrc)
* providing a function users are able to call if they want this
behaviour - this sounds like a good approach if it is done
independent from a specific prompt
#PS2='${${options[singlelinezle]#off}:+%_ }'
I'd do this in an if ...; then...; fi to improve readability.
An if condition would not catch cases when singlelinezle is set after
the prompt's setup function is run (we don't build the prompt in
a precmd) - OTOH this is not an option many people would set.
The contents of the .thisfiledoesnotexist file seems very similar to
the one of the prompt_debian_setup file. Attached by mistake?
It contains some additional lines (as mentioned above) I expected to
need in some years, if at all - but apparently I need them in this year.
Carsten
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#794968: zsh: please clear console on logout (if recommended config is used)
Package: zsh Severity: wishlist There are more important things that involve less work to do, therefore this is intended as a low priority wishlist bug. Please clear console on logout if the recommended config for new users is used. This requires: * a console_clear (currently part of the bash package) that is not completely broken * a patched zsh-newuser-install that also installs the file /etc/zsh/newuser.zlogout.recommended if available * a newuser.zlogout.recommended that handles everything console_clear does not and should not handle, for example, don't clear the console if $0 is -su (such a file is currently available in a bug report against bash and might in future be part of bash) * doko relicensing a trivial shell snippet used in /etc/.bash_logout (this shouldn't be a problem) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#794967: zsh: please enhance /etc/zshrc
Package: zsh
Severity: wishlist
Please enhance /etc/zshrc:
* Please add some additional keybindings, at least for the emacs keymap:
- bind PageUp ${terminfo[kpp]} to history-search-backward
- bind PageDown ${terminfo[knp]} to history-search-forward
The bash like history-search-end magic would be an alternative for
PageUp and PageDown, but history-search-backward does not require
running zle -N ...
- bind BackTabKey ${terminfo[kcbt]} to reverse-menu-complete
In terminfo(5), the capname cbt is described as back tab (P)
and kcbt is described as back-tab key, therefore the suggested
'BackTabKey' instead of 'BackTab' - even though grml confuses
people that know terminfo(5) by using 'BackTab' as name.
- Maybe F1 could invoke run-help? But then the output of run-help
w/o arguments should be more useful for new users.
- Red Hat maps or mapped space to magic-space, I think Debian should
_not_ do this, but initially I thought that this would be a good
idea.
* $key should be unset unless there is a reason for not doing so.
* (( ${+aliases[run-help]} )) requires the zsh/parameter module. If,
in rare cases, possibly involving zsh-static, there is a chance that
this module is not loaded successfully, you should consider doing
this instead to remove the alias w/o error message:
alias run-help=
unalias run-help
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#794968: zsh: please clear console on logout (if recommended config is used)
* Frank Terbeck [2015-08-08 23:51 +0200]:
Carsten Hey wrote:
Please clear console on logout if the recommended config for new users
is used.
I think this should be doable with a zshexit hook like this:
function debian_clear_upon_exit () {
clear
}
add-zsh-hook zshexit debian_clear_upon_exit
Interesting :) This could indeed avoid the need to ship a .zlogout for
new users. (An ugly alternative would be to set some variable and clear
consoles in /etc/zsh/zlogout if this variable is set.)
By console I meant the thing you get if you press Ctrl-Alt-F1. The
usual use case is to clear the console on logout for privacy reasons (an
other one is that the user might not want to be annoyed by things she/he
did in previous sessions whilst logging in again).
A minimal console_clear implementation with some tiny bugs could be
(this might fail to compile):
#include required_headers.h
void main(void) {
int mode;
if (ioctl(STDOUT_FILENO, KDGKBMODE, mode) != 0)
exit(EXIT_SUCCESS); /* not a console, exit successfully */
if (access(/usr/bin/clear, R_OK | X_OK) == 0)
execl(/usr/bin/clear, /usr/bin/clear, (char *) NULL);
exit(EXIT_FAILURE);
}
To meet the requirements of this use case, but not clearing the terminal
if it is not required, the shell needs to check if the terminal is
a console (or rather let clear_console do this check), ensure that it is
not a subshell and check that ${0##*/} does not match (-su|su). Also
checking if $SSH_CONNECTION is set would avoid some useless calls to
console_clear.
console_clear could be replaced by checking $(tty) and running clear if
the output indicates that the terminal is a console. But relying on
ttyname() and correctly interpreting its result is not the clean
solution I would prefer. I'd rather wait until doko has the time to fix
/usr/bin/clear_console, i.e., presumably after the gcc transition is
done. Nevertheless, using an zshexit hook seems to be worth
considering.
Carsten
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#794967: zsh: please enhance /etc/zshrc
* Frank Terbeck [2015-08-08 23:46 +0200]:
Carsten Hey wrote:
[...]
* Please add some additional keybindings, at least for the emacs keymap:
- bind PageUp ${terminfo[kpp]} to history-search-backward
- bind PageDown ${terminfo[knp]} to history-search-forward
- bind BackTabKey ${terminfo[kcbt]} to reverse-menu-complete
I firmly believe, that a vendor's *global* setup file should be as
minimal as possible, which is why I really don't want to add anything
that's more than making the zsh defaults behave more robustly across
multiple terminals or deal with stuff specific to Debian.
It looks like you changed your opinion since you wrote
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622933#10
In terminfo(5), the capname cbt is described as back tab (P)
and kcbt is described as back-tab key, therefore the suggested
'BackTabKey' instead of 'BackTab' - even though grml confuses
people that know terminfo(5) by using 'BackTab' as name.
By that logic, kpp would need to be mapped to PreviousPageKey. I think
the current naming is fine.
No, there is no such name collusion with kpp. What would be the name of
cbt if kcbt is BackTab? Actually, the name does not matter ;)
...
- Red Hat maps or mapped space to magic-space, I think Debian should
_not_ do this, but initially I thought that this would be a good
idea.
Again, this fits into the recommended setup file
The difference is that Red Hat destroys or destroyed existing mappings
with binding Space to magic-space. Binding BackTab, which is unbound by
default, does not annoy or harm anybody. The same applies to PageUp and
PageDown. Nothing you wrote changed my opinion that BackTab, PageUp and
PageDown should by bound to something useful by default.
* $key should be unset unless there is a reason for not doing so.
The reason I left it set, is because its layout matches the $key
dictionary, that zsh's zkbd function produces and can be used as a
drop-in replacement. I still think that's a reasonable idea, even though
it slightly violates the A vendor's global setup needs to be minimal
rule.
If you can imagine a real world use case and nobody complains, it's fine :)
* (( ${+aliases[run-help]} )) requires the zsh/parameter module. If,
in rare cases, possibly involving zsh-static, there is a chance that
this module is not loaded successfully, you should consider doing
this instead to remove the alias w/o error message:
alias run-help=
unalias run-help
That's a good point. I think we can do it like this:
unhash -a -m 'run-help' || true
-a removes alias from its hash table. -m uses the argument as a pattern.
Since there's no character that's significant to pattern matching, this
will work. This way, there is no error message. The '|| true' is to make
sure the setup file exits with successful status.
A sole : as last line instead of appending '|| true' to the last command
would make this intension more clear.
We could also just do this:
unalias run-help 2/dev/null || true
…if that's more straight-forward to read.
If there is a reason to write something in a way that is less
straight-forward to read, one could add a comment that explains the
code.
debootstrap --foreign ... enters a chroot without /dev/null, there might
be other rare but valid cases where /dev/null is not available.
Normally this is not a problem (everybody does this, POSIX allows it,
...), but I'd like to avoid such things in default shell rc files and
especially in global shell rc files to avoid issues in rare corner
cases.
Carsten
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#794967: zsh: please enhance /etc/zshrc
* Frank Terbeck [2015-08-08 23:46 +0200]: Carsten Hey wrote: [...] - Maybe F1 could invoke run-help? But then the output of run-help w/o arguments should be more useful for new users. - Red Hat maps or mapped space to magic-space, I think Debian should _not_ do this, but initially I thought that this would be a good idea. Again, this fits into the recommended setup file Btw., we agree on this part, Space - magic-space and F1 - run-help are possible candidates for a recommended setup file, but not for a global zshrc (I should have waited a few minutes after having the idea to map F1, instead of immediately sending the bug report). Carsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#794696: zsh: please set $VENDOR to debian
Package: zsh Severity: wishlist % echo $VENDOR pc This should print something useful, for example, 'debian'. ID in /etc/os-release or /usr/lib/os-release if the former does not exist looks like the correct value, a possible fallback if both do not exist is 'unknown'. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#793883: bash: clears console after running ssh
* Carsten Hey [2015-07-28 16:11 +0200]:
clear_console normally does not clear an xterm, but after running su
it does,
This is a .bash_logout problem, the code below fixes this.
and (run through skel.bash_logout) it also clears after running ssh on
tty1.
This is actually a clear_console problem, the code below works around
this, and if clear_console would do what it should, it would still be
a significant performance improvement.
Maybe you should throw away clear_console and replace it with a simple
shell script that runs getopts, prints the message known from
clear_console if -q is not used and no terminal was detected (I would
have added a -v option instead and made -q default) and contains the
inner case snippet from the code below.
Also, skel.bash_logout sometimes fails with exit code 1 although it
should not,
The code below contains the fix: add a : as last line.
and it is neither set -e nor set -u safe.
Use ${VAR-}, not $VAR and add : to commands that could fail.
Also fixed below.
Unless noted otherwise, anything below is too trivial to be
copyrightable.
# The author of the “if [ $SHLVL = 1 ]; then” part of below condition
# is Matthias Klose, see /usr/share/doc/bash/copyright on Debian or
# Ubuntu for copyright and license information.
if [ ${SHLVL-}|${SSH_CONNECTION-} = 1| ]; then
case ${0##*/} in
(-su|su)
;;
(*)
# This is a replacement for console_clear, which is broken.
# After console_clear has been rewritten, it will be able to
# replace below code.
#
# The glob to detect consoles below is:
# Copyright (C) 2011 Anton Zinoviev, and published under
# the license terms found in /usr/share/doc/expat/copyright,
# commonly known as MIT license.
if [ -x /usr/bin/tty ]; then
case $(/usr/bin/tty) in
(/dev/tty[1-9]*|/dev/vc/[0-9]*|/dev/console|/dev/ttyv[0-9]*)
[ -x /usr/bin/clear ] /usr/bin/clear :
;;
esac
fi
;;
esac
fi
:
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#793883: bash: clears console after running ssh
Package: bash 16:03:32 carstenh Hi, clear_console normally does not clear an xterm, but after running su it does, and (run through skel.bash_logout) it also clears after running ssh on tty1. You might use an other definition of console as I do, or this is a bug. 16:03:44 carstenh Also, skel.bash_logout sometimes fails with exit code 1 although it should not, and it is neither set -e nor set -u safe. I fixed this for you and added a workaround for the misbehaviour after running ssh on tty1: 16:03:49 carstenh http://paste.debian.net/plainh/7f08bc66 16:07:50 carstenh Do you consider skel.bash_logout as copyrightable (only the code)? The only non-obvious thing in it is the undocumented option (the manpage misses them). 16:09:05 doko please file a bug report -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#792703: zsh: please improve newuser.zshrc.recommended and add new prompt_debian_setup
If you add the attached files you do not read the other two mails :)
The attached prompt_debian_setup is updated all around:
* The prompt is not color-scheme-able anymore (the way all prompts do
it is ugly, and introducing a new way to do this is beyond the scope
of this bug report) - this also makes the funtion quite small.
* It now looks like adam1 on black terminals, but much better on light
terminals.
* $vcs_info_msg_1_ should not be part of $PROMPT, therefore I removed
it.
* Setting debian_chroot to '' disables displaying it.
* The help function is improved.
The h=history alias is removed from the attached newuser.zshrc.recommended.
Possible things to discuss after this file has been added to the package:
* dircolors:
- Use colored ls by default, i.e., use an according ls alias; or
at least make it easier to enable by adding #alias ls='ls
--color=auto?
- Should dircolors really be run w/o checking if it is available?
- Use ~/.dircolors if available?
* Add some additional aliases?
* Set the exit code of the most recent executed command to 0, i.e.,
run : at the end of the file (we use print_exit_value ...)?
* Use /etc/zsh_command_not_found is available, but only after this
package is updated?
# debian prompt theme
prompt_debian_help () {
cat 'EOF'
This prompt is currently not color-scheme-able. You can invoke it thus:
prompt debian
Displaying version control information via vcs_info and displaying
the name of a Debian chroot is supported by this prompt.
Displaying version control information is disabled by default.
To enable it, invoke the function vcs_info in a precmd function.
If the variable $vcs_info_msg_0_, which is set by vcs_info, is not
empty, its content is shown in the prompt. Other vcs_info variables,
i.e., $vcs_info_msg_N_, are ignored by this prompt, but they can be
used in an user supplied $RPROMPT or in a precmd function.
Displaying the name of the Debian chroot, if any, is enabled by default.
To disable it, unset $debian_chroot after enabling the debian prompt.
An other way to disable it is to set $debian_chroot to an empty string.
The options prompt_cr, prompt_subst and prompt_percent are set.
It is suggested to also set the option print_exit_value.
EOF
}
prompt_debian_setup () {
prompt_opts=(cr subst percent)
if [[ -z ${debian_chroot+set} -r /etc/debian_chroot ]]
then debian_chroot=$(/etc/debian_chroot) || :
fi
PROMPT='%F{white}%K{blue}${debian_chroot:+($debian_chroot)}%n@%m%f%k '
PROMPT+='%B%F{cyan}%(5/:.../:)%4~%b%f '
PROMPT+='${vcs_info_msg_0_:+${vcs_info_msg_0_# }%b%f%k }'
PROMPT+='%B%#%b%f%k '
}
prompt_debian_setup $@
# Set up the prompt:
autoload -Uz add-zsh-hook promptinit vcs_info
promptinit
(( ${+prompt_themes[(r)debian]} )) prompt debian || prompt adam1
setopt print_exit_value
# Uncomment the next line to enable vcs_info; the second line adds colors:
#add-zsh-hook precmd vcs_info
#zstyle ':vcs_info:*' formats '%F{5}(%f%s%F{5})%F{3}-%F{5}[%F{2}%b%F{5}]%f'
# Use emacs keybindings even if our EDITOR is set to vi:
bindkey -e
# Alias definitions:
alias ll='ls -l'
# Keep 1000 lines of history within the shell and save it to ~/.zsh_history:
HISTSIZE=1000
SAVEHIST=1000
HISTFILE=~/.zsh_history
setopt hist_ignore_all_dups share_history
# Use modern completion system:
autoload -Uz compinit
compinit
zstyle ':completion:*' auto-description 'specify: %d'
zstyle ':completion:*' completer _expand _complete # _correct _approximate
zstyle ':completion:*' format 'Completing %d'
zstyle ':completion:*' group-name ''
zstyle ':completion:*' menu select=2
eval $(dircolors -b)
zstyle ':completion:*:default' list-colors ${(s.:.)LS_COLORS}
zstyle ':completion:*' list-colors ''
zstyle ':completion:*' list-prompt %SAt %p: Hit TAB for more, or the character
to insert%s
zstyle ':completion:*' matcher-list '' 'm:{a-z}={A-Z}' 'm:{a-zA-Z}={A-Za-z}'
'r:|[._-]=* r:|=* l:|=*'
zstyle ':completion:*' select-prompt %SScrolling active: current selection at
%p%s
zstyle ':completion:*' use-compctl false
zstyle ':completion:*' verbose true
zstyle ':completion:*:*:kill:*:processes' list-colors '=(#b) #([0-9]#)*=0=01;31'
zstyle ':completion:*:kill:*' command 'ps -u $USER -o pid,%cpu,tty,cputime,cmd'
Bug#793008: pal: weeknumber calculation not locale aware
Thanks for this great bug report! * Rhonda D'Vine [2015-07-20 14:10 +0200]: I noticed today that pal seems to calculate the weeknumber always US centric (or at least not locale aware). If one has put show_weeknum into ~/.pal/pal.conf, regardless of LC_TIME setting pal always seems to calculate as if it's set to C. A few notes: * A Google search revealed DIN 1355 / ISO 8601 as possibly relevant, if one wants to verify that ncal -w is indeed correct. * This bug presumably isn't triggered for all years (depending on the first day of the year). * LC_TIME=de_DE* seems to behave as LC_TIME=C in this case. * pal(1) does not mention show_weeknum. * An additional relevant pal rc setting is week_start_monday. * This could be useful for testing: LC_TIME=C TERM=dumb datefudge 1980-01-01 00:00 ... * Since ncal hardly implemented proper LC_TIME handling itself, this might be related to a libc function it uses - checking if setlocale() is used correctly looks like a good idea. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#792703: zsh: please improve newuser.zshrc.recommended and add new prompt_debian_setup
Package: zsh
Severity: wishlist
Hi,
there is an additional, related, bug report in this one. The actual bug
report starts below the three dashes.
If I use the color-enabling zstyle ':vcs_info:*' formats string from
zshcontrib(1), it does not only add colors, but also slightly modifies
the format. In the example below, a space is removed and a minus is
replaced with a space. I would expect that such an documented example
format only modifies the colors - but YMMV.
~% setopt prompt_percent prompt_subst
~% autoload -Uz add-zsh-hook vcs_info
~% add-zsh-hook precmd vcs_info
~% PROMPT='%~$vcs_info_msg_0_%# '
~% cd gittest
~/gittest (git)-[master]-% zstyle ':vcs_info:*' formats
'%F{5}(%f%s%F{5})%F{3}-%F{5}[%F{2}%b%F{5}]%f '
~/gittest(git)-[master] %
The above format string without the trailing space is used (if
uncommented) in the improved newuser.zshrc.recommended and I think at
least in this file should a format string be used that only adds colors
and changes nothing else. OTOH, I think the default trailing minus does
not make that much sense, but I also assume that it won't be removed.
Anyway this detail of the improved newuser.zshrc.recommended can still
be changed in future.
The same possible documentation issue might, or might not, apply to the
example actionformats and branchformat strings.
It would be great if there would be a way to get a colorful vcs_info
without copying around (or alternatively, understanding) format strings;
for example running vcs_info --setup-only --enable-colors could set up
colorful format strings, but not execute vcs_info's vcs foo. Such
options could be used in the improved newuser.zshrc.recommended. The
obvious generalisation of --enable-colors is adding support for themes
that can be enabled via command line option.
---
Clint did a great job with his newuser.zshrc.recommended, he even added
proper integration into zsh upstream and added instructions for
inexperienced users (Hit TAB ...). Anyway, there are still some small
issues that could be fixed and things that could be improved (I might
have missed to list some things I changed):
* On white terminals, the recommended prompt for new users looks like
the broken hourly cron syslog entry - both contain three characters
equivalent to spaces in a row. The obvious fix for the prompt is
not using white text on white background.
* On white terminals, default foreground color on blue background is
suboptimal too, white on blue is way better.
* There is no (non-insane) way to add vcs_info to the used adam1
prompt.
* debian_chroot support is missing and can't easily be added to the
used prompt either.
* An exit code != 0 is not displayed, but IMHO this is useful. There
are two common ways how this is done, either added to the prompt in
some way, or using printexitvalue (known from tcsh) - I prefer the
latter.
* Menu select is only enabled if there are a lot of matches, I first
assumed that this might be a bug, but it looks like this was done by
intension. I agree that it is more useful if there are a lot of
matches, but it is still useful otherwise; and either always
enabling or always disabling this feature makes zsh feel more
consistent.
* A completion with _correct and _approximate might be useful for some
users and confuse others - presumably especially long time
unix/linux users, but also some new users don't expect their shell
to behave like a desktop word processor. I think such a feature
should be out-in.
* Some default aliases could be useful, at least ll seems to be used
all around. I also added h=history. l and la could be added too.
* The .zshrc could use a layout that is more consistent to itself and
zshall(1):
+ One comment line ends with a colon (I think I wrote this line),
the others don't.
+ History related options and history related variables should be
part of the same part of the file, but are split by bindkeys -e.
+ One comment is followed by an empty line, others don't.
+ zshall(1) writes option names with _ between the words, which
improves readability, and, if used the same way in a .zshrc,
eases searching for the option in the man page.
The two files can be found at:
http://stateful.de/~carsten/tmp/150717QVwIxjFQx9U/prompt_debian_setup
http://stateful.de/~carsten/tmp/150717QVwIxjFQx9U/newuser.zshrc.recommended
prompt_debian_setup should be submitted for inclusion in zsh after being
added to Debian's zsh.
The design and the source code of prompt_debian_setup was originally
based on prompt_adam1_setup and there might still be some lines from it.
Anything copyrightable (if there is something copyrightable in it at
all) in it that is not copied from prompt_adam1_setup is published under
the most liberal, public domain equivalent, license possible. On
request, I'll assign copyright to zsh's upstream. The
Bug#792703: zsh: please improve newuser.zshrc.recommended and add new prompt_debian_setup
* Carsten Hey [2015-07-17 18:22 +0200]: http://stateful.de/~carsten/tmp/150717QVwIxjFQx9U/prompt_debian_setup http://stateful.de/~carsten/tmp/150717QVwIxjFQx9U/newuser.zshrc.recommended c894f695cc02f16af429c7506bb78354dcd9a1e3 looks like the final PROMPT+= line in prompt_debian_setup could be replaced with this shorter one: PROMPT+='%(!:#:\$)%b%f%k ' -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#792733: ksh: setenv() is wrong
Package: ksh
Severity: minor
Hi,
setenv() in the example .kshrc at least in Jessie behaves different than
setenv in tcsh. Your behaviour with one argument (exporting $1) makes
more sense than the tcsh's behaviour (exporting and setting $1 to ),
but this doesn't seem to be relevant for an undocumented function. Even
if this would be on purpose, it should not fail if $# is 0.
A verbose ksh93/zsh specific implementation might look similar to this:
setenv() {
case $# in
0) export ;;
1) export $1= ;;
2) export $1=$2 ;;
esac
}
A short equivalent one that is set -u safe is:
setenv() { export ${1+$1=${2-}}; }
The possibly shortest one (not set -u safe) is:
setenv() { export ${1+$1=$2}; }
csh's setenv is weird (setenv '$FOO' BAR expands $FOO and uses the
result as variable name) and can only be implemented with eval
- therefore choosing tcsh's setenv instead looks like a good decision.
Carsten
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678896: lintian: please add check for multi-arch: foreign -dbg packages
Package: lintian Severity: wishlist Hi, please add a check for multi-arch: foreign -dbg packages. https://wiki.ubuntu.com/MultiarchSpec: | Multi-Arch: foreign | * The package is not co-installable with itself, but should be allowed | to satisfy the dependencies of a package of a different arch from | itself. The above seems to be wrong for -dbg packages. Sid currently contains one example for a real -dbg package, i.e., with debugging symbols; and one example for a transitional -dbg package, which also seems to be wrong: | $ ftp.de.debian.org_debian_dists_sid_main_binary-amd64_Packages perl -00 -ne 'print if /^Multi-Arch: f/m /^Package:.*-dbg$/m' | egrep '^Package:|^Multi-Arch:|^Description:|Version:|^$' | Package: libva-intel-vaapi-driver-dbg | Version: 1.0.17-1 | Description: VAAPI driver for Intel G45 HD Graphics family (transitional package) | Multi-Arch: foreign | | Package: libsqlite3-0-dbg | Version: 3.7.13-1 | Description: SQLite 3 debugging symbols | Multi-Arch: foreign Regards Carsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676653: tor: please add Multi-Arch: foreign to the tor package
* Peter Palfrader [2012-06-24 15:34 +0200]:
Helmut Grohne schrieb am Freitag, dem 08. Juni 2012:
The tor package seems to provide an architecture independent interface
(i.e. command line and architecture independent network protocols such
as socks and ssl). As such it should be marked as Multi-Arch: foreign.
In practise that would allow installing the following combination of
packages: dpkg:amd64 tor:i386 tor-geoipdb. This set is currently not
installable, since the tor dependency on tor-geoipdb needlessly enforces
that tor uses the same architecture as dpkg.
The impact of that change, or why it is even needed, is not entirely
obvious.
weasel noted that tor-dbg exists and depends on tor. Since dpkg
currently handles arch all packages as if they were native for
dependency resolution [1], this leads to this situation:
* tor-dbg requires tor to be installed for the same arch as tor-dbg.
* tor-geoipdb:all should be happy with tor installed for any arch, but
currently depends on tor on the native arch.
According to [2] and in theory, the fix for this bug is:
Package: tor
Architecture: any
Depends: ...
Multi-Arch: allowed
^^^
Package: tor-dbg
Architecture: any
Depends: tor (= ${binary:Version}), ${misc:Depends}
Package: tor-geoipdb
Architecture: all
Depends: tor:any (= ${source:Version}), ${misc:Depends}
In practice, I think delaying this for after Wheezy as you suggested is
the way to go because:
* debfoster and presumably other programs have no idea about the arch
suffix :any.
* :any is currently neither used in Ubuntu nor in Debian. Introducing
the first package with such a dependency a week before the freeze
even though it is known to break existing tools would hardly be sane.
Regards
Carsten
[1]
https://wiki.ubuntu.com/MultiarchSpec#Dependencies_involving_Architecture:_all_packages
[2]
https://wiki.ubuntu.com/MultiarchSpec#Extended_semantics_of_per-architecture_package_relationships
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670106: initscripts: please ignore noauto sysfs entries in fstab
* Carsten Hey [2012-05-11 00:58 +0200]:
* Carsten Hey [2012-04-30 02:00 +0200]:
* Roger Leigh [2012-04-29 23:19 +0100]:
how do other distributions handle noauto in this situation? Do they
respect it, ignore it, or not look at fstab at all?
...
For current systems, I think it's useful to know what systemd and
upstart are doing. systemd is simple enough to test on Debian;
for upstart we can look at Ubuntu. ...
So if all the others choose to not respect noauto for specific
mounts, that's a point in favour of doing that.
Being consistent to other init systems in Debian makes sense. I'll send
an other mail after knowing this.
I installed Fedora 16 (uses systemd as init and was released in November
2011) and the just released Ubuntu LTS (uses upstart) into a KVM
container and added a noauto sysfs line for /sys that matches (besides
noauto) their default mount options to /etc/fstab on both systems.
On both systems, /sys was mounted despite the noauto sysfs entry.
In my previous mail I forgot to mention if others ignore the fstab entry
completely or only ignore the noauto option.
systemd/Fedora and upstart/Ubuntu ignore the noauto option but respect
the other options (or at least some of them). I tested this by adding
relatime as mount option to the noauto sysfs entry on Ubuntu and
replacing relatime with strictatime on Fedora.
I also tested this with the same result for /proc on Fedora.
The attached yet untested patch adapts initscripts to match the
behaviour of the other systems.
Regards
Carsten
From ac727044e3c0a0d71e9bebdb7268aed4b823acc3 Mon Sep 17 00:00:00 2001
From: Carsten Hey cars...@debian.org
Date: Fri, 15 Jun 2012 17:36:06 +0200
Subject: [PATCH] initscripts: ignore noauto option in fstab for sysfs and proc
For both filesystem types, the noauto option is only ignored for the
default moint point.
systemd in Fedore 16 also ignores the noauto option for both filesystem
types with their default mount point, but respects other options, i.e.,
the entry is not completely ignored.
upstart in the recent Ubuntu LTS release behaves the same way for sysfs.
If it also does so for proc has not been tested.
This commit fixes Debian bug #670106.
---
debian/src/initscripts/lib/init/mount-functions.sh | 18 +-
1 files changed, 17 insertions(+), 1 deletions(-)
diff --git a/debian/src/initscripts/lib/init/mount-functions.sh b/debian/src/initscripts/lib/init/mount-functions.sh
index 4b5bf09..ca10dad 100644
--- a/debian/src/initscripts/lib/init/mount-functions.sh
+++ b/debian/src/initscripts/lib/init/mount-functions.sh
@@ -184,8 +184,24 @@ domount () {
if read_fstab_entry $MTPT $FSTYPE; then
case $MNT_OPTS in
noauto|*,noauto|noauto,*|*,noauto,*)
-return
+case $FSTYPE in
+ sysfs)
+ if [ $MTPT != /sys ]; then
+ return
+ fi
+ ;;
+ proc)
+ if [ $MTPT != /proc ]; then
+ return
+ fi
+ ;;
+ *)
+ return
+ ;;
+esac
;;
+ esac
+ case $MNT_OPTS in
?*)
FSTAB_OPTS=-o$MNT_OPTS
;;
--
1.7.2.5
Bug#670716: gtkorphan: please use deborphan's forward compatible options
Hi, * Carsten Hey [2012-04-28 14:19 +0200]: Uploading this change in the time frame from now (Ubuntu LTS is releasing today) to the upcoming freeze of Debian Wheezy guarantees that the installed deborphan release provides these options (even during partial updates and without the need to add a versioned dependency) and also ensures that during the next Debian release cycle deborphan is able to adapt the output of --all-packages or --show-deps if needed without breaking gtkorphan. this time frame I wrote about is nearly over (possibly just a matter of hours), so I uploaded a NMU that fixes this bug, adds the Spanish translation, and, since debhelper compat level 4 is deprecated and there is no difference in the built binary anyway, I bumped the dh compat level to 9. The diff without the Spanish translation file es.po between the source packages 0.4.4-1 and 0.4.4-1.1 is attached. Regards Carsten diff -u gtkorphan-0.4.4/debian/changelog gtkorphan-0.4.4/debian/changelog --- gtkorphan-0.4.4/debian/changelog +++ gtkorphan-0.4.4/debian/changelog @@ -1,3 +1,22 @@ +gtkorphan (0.4.4-1.1) unstable; urgency=low + + * Non-maintainer upload. + * Use deborphan's frontend specific options. They provide a non-changing +interface to deborphan, even if deborphan needs to adapt its output +format, for example, if sections are replaced by tags in Debian. +(Closes:#670716) + * Depend on deborphan = 1.7.28.2 instead of = 1.7.17. deborphan +1.7.28.2 or later is available since Debian Squeeze (6.0) and Ubuntu +Natty (11.04). + * Bump debhelper compat level to 9, adapt build-dependency on debhelper in +debian/control and use dh_prep in debian/rules. The rationale for this +change is that the previously used compat level has been deprecated +and the there were no changes in debhelper since compat level 4 that +are relevant for gtkorphan. + * Add Spanish translation, provided by Omar Campagne. (Closes:#537825) + + -- Carsten Hey cars...@debian.org Fri, 15 Jun 2012 22:31:17 + + gtkorphan (0.4.4-1) unstable; urgency=low * Replaced gksu with su-to-root (Closes:#479819) diff -u gtkorphan-0.4.4/debian/rules gtkorphan-0.4.4/debian/rules --- gtkorphan-0.4.4/debian/rules +++ gtkorphan-0.4.4/debian/rules @@ -47,7 +47,7 @@ install: build dh_testdir dh_testroot - dh_clean -k + dh_prep dh_installdirs $(MAKE) install DESTDIR=$(CURDIR)/debian/gtkorphan diff -u gtkorphan-0.4.4/debian/compat gtkorphan-0.4.4/debian/compat --- gtkorphan-0.4.4/debian/compat +++ gtkorphan-0.4.4/debian/compat @@ -1 +1 @@ -4 +9 diff -u gtkorphan-0.4.4/debian/control gtkorphan-0.4.4/debian/control --- gtkorphan-0.4.4/debian/control +++ gtkorphan-0.4.4/debian/control @@ -1,13 +1,13 @@ Source: gtkorphan Section: admin Priority: optional -Build-Depends: debhelper (= 4.0.0), libxml-parser-perl, libgtk2-perl (=1:1.100) +Build-Depends: debhelper (= 9.0.0), libxml-parser-perl, libgtk2-perl (=1:1.100) Standards-Version: 3.7.3 Maintainer: Fabio Marzocca thesalty...@gmail.com Package: gtkorphan Architecture: all -Depends: menu, perl, deborphan(=1.7.17), libgtk2-perl (=1:1.100-1), libglib-perl (=1:1.100-1), liblocale-gettext-perl, libgtk2-gladexml-perl +Depends: menu, perl, deborphan(=1.7.28.2), libgtk2-perl (=1:1.100-1), libglib-perl (=1:1.100-1), liblocale-gettext-perl, libgtk2-gladexml-perl Description: A graphical tool to find and remove orphaned libraries GtkOrphan is a graphical tool which scans your Debian system, looking for orphaned libraries. It implements a GUI front-end to deborphan, but adds the only in patch2: unchanged: --- gtkorphan-0.4.4.orig/configure +++ gtkorphan-0.4.4/configure @@ -2246,7 +2246,7 @@ ACLOCAL=$ACLOCAL $ACLOCAL_FLAGS -ALL_LINGUAS=it fr bg de cs vi sv nl zh_CN +ALL_LINGUAS=it fr bg de cs vi sv nl zh_CN es GETTEXT_PACKAGE=gtkorphan only in patch2: unchanged: --- gtkorphan-0.4.4.orig/configure.in +++ gtkorphan-0.4.4/configure.in @@ -13,7 +13,7 @@ dnl put the ACLOCAL flags in the makefile ACLOCAL=$ACLOCAL $ACLOCAL_FLAGS -ALL_LINGUAS=it fr bg de cs vi sv nl zh_CN +ALL_LINGUAS=it fr bg de cs vi sv nl zh_CN es GETTEXT_PACKAGE=gtkorphan AC_SUBST(GETTEXT_PACKAGE) AC_DEFINE_UNQUOTED(GETTEXT_PACKAGE, $GETTEXT_PACKAGE, [Gettext package]) only in patch2: unchanged: only in patch2: unchanged: --- gtkorphan-0.4.4.orig/lib/gtkorphan_ops.pm +++ gtkorphan-0.4.4/lib/gtkorphan_ops.pm @@ -227,7 +227,7 @@ $options .= --find-config if ($find_config-get_active()) ; #all packages checked? - $options .= --all-packages if ($find_all-get_active()) ; + $options .= --all-packages-pristine if ($find_all-get_active()) ; #GUESS options @@ -608,7 +608,7 @@ $application-tv_regular-set_sensitive(TRUE); #get orphaned to remove from list - #(deborphan bug on -d option + #(deborphan bug on --show-deps-pristine option $command = $application-dorph; my @orphaned = `$command`; chomp (@orphaned); @@ -617,7 +617,7 @@ #build and spawn command
Bug#676811: packagesearch: apparently enters an endless loop if xapian index is missing
* Benjamin Mesing [2012-06-12 20:59 +0200]: tag 676811 +patch I assume you meant pending. I have therefore changed packagesearch from using /etc/alternatives/x-terminal-emulator (where the behaviour is only roughly specified within the policy) to /usr/bin/xterm. You recommend xterm | x-terminal-emulator. If you choose invoke xterm, you could change this recommendation. This should fix this bug unless something else was going on at your side. I have neither xterm nor any other x-terminal-emulator installed. If you use execve() or similar, checking if the function it returns (on success it does not) and if it does, displaying an error message that matches errno in packagesearch itself would in my opinion be the correct way to prevent the problem I had. I think packagesearch entered an endless loop after it failed to start a terminal. Carsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676809: packagesearch: not fully multiarch aware
Hi,
* Benjamin Mesing [2012-06-11 22:42 +0200]:
thanks for the extensive testing and information. I have already fixed
many of your reports in SVN
great! Please remember that Debian freezes in the second half of June
and that a release team member recently wrote that uploads thus should be
done before the 15th of June (yes, this is still the first half ...).
* It fails silently fails to remove packages (after installing
aptitude, before it complained about the missing aptitude).
The installation tool (apt vs. aptitude) is configurable within
packagesearch. I have changed the default to apt since packagesearch
depends on apt anyways. I have also improved the error message, when
aptitude is not available to point to the configuration dialog.
Sounds sane.
However, I cannot reproduce the silent failure to remove the package
after installing aptitude.
I replaced /bin/su and /usr/bin/aptitude with a script that writes the
invocation name and the arguments to /foo. The content of /foo does not
change if I try to install or remove a package using packagesearch.
Maybe I just don't understand how packagesearch should be used. If
I use it correctly, possible explanations include that packagesearch
don't like to be run by root or that a minimal environment (e.g.,
without $SHELL) is not sufficient, ...
I do not know, if I have a multiarch system
... but that this problem is multiarch related seems to be most likely,
or in other words, that I have a multiarch system and you do not.
dpkg --print-foreign-architectures will print the foreign architecture
if you have a multiarch system.
(deborphan reports the :arch tag), but I guess this has nothing to do
with it anyways.
dpkg and apt are supposed to run on the system they do act on, deborphan
acts on the status file you feed to it and if you do not specify one it
defaults to /var/lib/dpkg/status. To detect multiarch, deborphan reads
all Architecture: fields and counts the number of distinct values.
Accordingly, deborphan might detect a system not to be multiarch if dpkg
has been told to enable multiarch but no foreign package is installed.
You case seems to be the opposite, which should not happen if your
system never was multiarch (you would know if it was). The output of
the following command would be interesting (replace amd64 with i386 if
you run a 32 bit Debian):
egrep '^(Package:|Version:|Architecture:)|^$' /var/lib/dpkg/status | perl -00
-ne 'print if /^Architecture:/m !/^Architecture: (all|amd64)$/m' | cat -A
The first paragraph of http://wiki.debian.org/Multiarch/Implementation
describes how to enable multiarch. To install a foreign package you
could for example run 'apt-get install sc:i386'. Doing this in a newly
created chroot prevents possible problems on your productive system if
things don't work as expected.
* It complains that the file list for $package is not available for
co-installable multiarch packages. I assume all you do is listing
the file content of /var/lib/dpkg/info/${packagename}.list. For
co-installable multiarch packages, this is not enough, for example,
/var/lib/dpkg/info/devscripts.list would be found, but
libapt-pkg4.12:amd64.list in the same directory would not be found
using this approach.
I quick fixed that: packagesearch now scans for packagename[:*].list
and takes the first match..
Given that, for example, libc6:amd64.list and libc6:i386.list contain
different filenames, doing this properly might be worthwhile for
Wheezy+1.
packagesearch as deborphan frontend works as expected, except of above
noted general problems. On multiarch enabled systems, deborphan/Wheezy
prints package names with architecture suffix, for example 'vim:amd64'
instead of 'vim'. On non-multiarch systems, it omits this architecture
suffix.
I have quick fixed this by removing the trailing :arch part, even
though, in the long run, it might be desirable to include
arch-information.
JFTR: deborphan does not display a package as orphaned that is installed
for multiple architectures if it is not orphaned on all architectures.
Unless the user uses an possible future option to do tell deborphan
otherwise, this behaviour should never change.
Thanks for your help
Thanks for fixing things that fast :)
Carsten
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676809: packagesearch: not fully multiarch aware
* Carsten Hey [2012-06-12 01:09 +0200]: The first paragraph of http://wiki.debian.org/Multiarch/Implementation describes how to enable multiarch. To install a foreign package you could for example run 'apt-get install sc:i386'. Doing this in a newly created chroot prevents possible problems on your productive system if things don't work as expected. If everything else works, you could try to remove sc:i386 via packagesearch with apt-get and aptitude. Doing this with apt-get requires the package name to be architecture qualified for foreign arch packages if they are also available on the native arch (since an needless arch suffix does not cause any harm, checking the availability on the native arch would be a waste of time). I have no idea how aptitude handles arch qualified packagenames, but I assume that it does not complain if arch suffixes are added even if they are not needed. Regards Carsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672829: upgrade-system|grml-live: running deborphan in loops (was: Bug#672829: upgrade-system: please bump dependency on deborphan to 1.7.28.7 after it has reached unstable
tl;dr: You use deborphan wrong. The last paragraph of this mail describes the fix that depends an unreleased deborphan version. I'll send an update when it hits unstable. * Martin-Éric Racine [2012-06-09 12:24 +0300]: 2012/5/14 Carsten Hey cars...@debian.org: Since it does not require a multiarch-aware dpkg, I don't think it should depend on a multiarch-aware dpkg. It's upgrade-systems that enters an endless loop if it is run with deborphan 1.7.28.6 or earlier on multiarch enabled systems (which of course requires a recent dpkg). It only enters into a loop when the components below it are mismatched. In this case, it was deborphan that wasn't able to produce multiarch-aware output that APT could use. deborphan was broken, not upgrade-system. I'm closing this bug. I disagree for multiple reasons, anyway, the partial upgrade problem in Debian in only theoretical and this is not Ubuntu's bug tracker. In general, running while [ -n `deborphan` ]; do apt-get remove `deborphan`; done without checking for endless loops is wrong, as described in the quoted paragraph below: upgrade-systems relies on apt to remove the packages that are displayed by deborphan. This is nothing deborphan can guarantee, for example apt won't remove itself without using --force-whatever. It is mostly save to rely on this behaviour, though. If you need this you must ensure that the known exceptions won't occur, for example, don't run deborphan with options that could show apt as orphaned, or, as in this case, don't run an old deborphan on mutliarch-enabled systems. If you ran stable with oldstable still in your sources.list, e.g., whilst upgrading to stable, you got a similar problem that could lead (depending on your loop's implementation) to a failure or an endless loop: | deborphan (1.7.28.2) unstable; urgency=low | * Exclude diff and mktemp from being displayed in orphaner. Apt and dpkg | sometimes disagree about essentialness of packages, which leads to | failures for dpkg frontends that use apt to remove packages, e.g., | deborphan. Currently, the relevant packages are diff and mktemp. The | package install-info has deliberately not been added to the list of to be | excluded packages. A proper fix for both packages, upgrade-system and grml-live, is depending on a yet not released deborphan with a --recursive option and running apt-get remove `deborphan` instead of of your loop. I'll drop you a mail when such a deborphan release gets uploaded to unstable. Regards Carsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672829: upgrade-system|grml-live: running deborphan in loops (was: Bug#672829: upgrade-system: please bump dependency on deborphan to 1.7.28.7 after it has reached unstable
* Carsten Hey [2012-06-09 13:37 +0200]: A proper fix for both packages, upgrade-system and grml-live, is depending on a yet not released deborphan with a --recursive option and running apt-get remove `deborphan` instead of of your loop. I'll drop you a mail when such a deborphan release gets uploaded to unstable. That should have been: apt-get remove `deborphan --recursive` -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672829: upgrade-system|grml-live: running deborphan in loops (was: Bug#672829: upgrade-system: please bump dependency on deborphan to 1.7.28.7 after it has reached unstable
* Martin-Éric Racine [2012-06-09 14:50 +0300]: 2012/6/9 Carsten Hey cars...@debian.org: * Carsten Hey [2012-06-09 13:37 +0200]: A proper fix for both packages, upgrade-system and grml-live, is depending on a yet not released deborphan with a --recursive option and running apt-get remove `deborphan` instead of of your loop. I'll drop you a mail when such a deborphan release gets uploaded to unstable. That should have been: apt-get remove `deborphan --recursive` You're trying to fix a kludge with yet another kuldge. I'm not gonna support this. Sorry. You have problems with endless loops because you do not check for already seen packages and deborphan fixes this for you in a proper way so that there is no need to run deborphan in a loop. You could replace the whole loop with apt-get remove `deborphan --recursive`. I hope this clarifies this (the need to clarify is implied by your answer). Carsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672829: upgrade-system|grml-live: running deborphan in loops (was: Bug#672829: upgrade-system: please bump dependency on deborphan to 1.7.28.7 after it has reached unstable
* Martin-Éric Racine [2012-06-09 15:16 +0300]: 2012/6/9 Carsten Hey cars...@debian.org: You have problems with endless loops because you do not check for already seen packages and deborphan fixes this for you in a proper way so that there is no need to run deborphan in a loop. No. The loop used to break on multiarch systems because deborphan did not produce multiarch-aware content until recently. Even then, this only affects Ubuntu's Precise release. No other Debian or Ubuntu release is affected. This multiarch related issue was a symptom of the general problem that this using this option fixes. You could replace the whole loop with apt-get remove `deborphan --recursive`. This is a nice new feature, but it's not backportable, hence why I'll stick with my own loops for now. Actually it is backportable, or rather, it can be written in a way that works since Ubuntu Natty and Debian Squeeze. You could check if the option --recursive is present in the system's deborphan and use this in an if condition. Anyway, since there is currently no known problematic package and the multiarch issue is solved, waiting for post-Wheezy to use a proper deborphan invocation is fine, but it should in my opinion be done for Wheezy+1. Checking for an option can be done with the option --check-options: $ deborphan --check-options --recursive/dev/null 21 echo option is implemented $ deborphan --check-options --show-section /dev/null 21 echo option is implemented option is implemented --check-options is only able to check one option reliably, needs to be the first option itself and output on stdout or stderr might happen. This restrictions might be removed in future. Regards Carsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676809: packagesearch: not fully multiarch aware
Package: packagesearch
A while ago I checked all reverse dependencies of deborphan for
multiarch and deborphan related problems, except of packagesearch since
I assumed that it wouldn't be actively maintained anymore and had an
release critical bug at that time. Now its very late in the release
cycle and Debian will presumably freeze in the second half of June.
The multiarch related problems I spotted in your package are listed
below. These issues are not limited to the deborphan part of
packagesearch, as it also applies to packages found via debtags:
* It fails silently fails to remove packages (after installing
aptitude, before it complained about the missing aptitude).
* It complains that the file list for $package is not available for
co-installable multiarch packages. I assume all you do is listing
the file content of /var/lib/dpkg/info/${packagename}.list. For
co-installable multiarch packages, this is not enough, for example,
/var/lib/dpkg/info/devscripts.list would be found, but
libapt-pkg4.12:amd64.list in the same directory would not be found
using this approach.
packagesearch as deborphan frontend works as expected, except of above
noted general problems. On multiarch enabled systems, deborphan/Wheezy
prints package names with architecture suffix, for example 'vim:amd64'
instead of 'vim'. On non-multiarch systems, it omits this architecture
suffix.
There are some frontend specific options in deborphan, but none of them
is relevant for your package, with the possible exception of --show-arch
to always print package names with arch qualification. If you are
interested in using this option, please drop me a mail so that I can
clarify some related problems with partial upgrades and how to check if
the option is available in the system's deborphan.
Regards
Carsten
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676810: packagesearch: please recommend aptitude
Package: packagesearch Severity: wishlist Please recommend aptitude. When trying to remove a package, packagesearch complains that aptitude is not installed (which was correct). If a package requires an other package for optional core functionality, adding the other package to the Recommends: field is appropriate. Regards Carsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676811: packagesearch: apparently enters an endless loop if xapian index is missing
Package: packagesearch When I started packagesearch the first time in a multiarch Debian/Sid chroot (including the usual mounts) as root, it complained that the xapian index was not generated and offered to generate it. The systems CPU usage raised to 100% and nothing user visible happend in the one or two minutes I waited, neither in the GUI nor on the terminal I used to start packagesearch. The output of ps axuf contained: | root 16779 85.2 0.3 377520 19780 pts/22 Rl+ 13:51 1:25 | | \_ packagesearch | root 16784 0.0 0.0 0 0 pts/22 Z+ 13:52 0:00 | | \_ [packagesearch] defunct | root 16785 0.0 0.0 148796 3712 pts/29 Ss+ 13:52 0:00 | \_ /bin/zsh I saw no process that seemed to be related to xapian or apt. If I just did not wait long enough and missed the xapian process, then there are still two issues: * PID 16784 was a zombie. * There should be something user visible whilst the xapian cache is generated, or at least the user notice should be noticed that generating the cache might take some minutes. After manually invoking /usr/sbin/update-apt-xapian-index --update, packagesearch started as expected. Regards Carsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676812: packagesearch: shows only one-line descriptions
Package: packagesearch When displaying a packages description, only the first line is displayed. Nowadays the Packages files on the mirrors only contains this first line, the complete description is available in files that end in i18n_Translation-en or similar. If have no idea how libapt has been adapted for this. apt-cache, aptitude and dpkg show the complete description, but the latter shows them only in English. Regards Carsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#257505: dpkg: patch to fix the wrong output of dpkg-query --list in UTF-8 locales
Hi,
I saw this old bug report yesterday whilst looking for the convention
for bug subjects used in dpkg.
* Changwoo Ryu [2004-07-04 06:57 +0900]:
In my ko_KR.UTF-8 locale and with the new Korean translation added
(#254590),
dpkg-query --list prints each fields in wrong columns (see attached
dpkg-list-before.png file).
This is because dpkg assumes that a string's length (strlen) is the
width it occupies
in text terminals, which is not true in UTF-8 locales. (A Korean hangul
character
is 3 bytes long but width is 2.) I fixed this problem by adjusting the
string lengths
in *printf() formats according to the their actual widths in text
terminal (see the
attached patch).
With attached patch applied, it displays each fiels with Hangul
characters correctly.
(attached dpkg-list-after.png file)
Just for the record, I wrote a similar function as used in the patch to
align the columns for (non-dpkg) --help output. I wonder if the rest of
the patch can be simplified. Maybe I'll have a look at this during the
next release cycle.
The code of my function is:
static size_t
mbswidth(const char *s)
{
#if ENABLE_NLS
size_t rv, len, wlen;
wchar_t *wstr;
int wcsw;
rv = len = strlen(s);
if ((wstr = (wchar_t *)malloc((len + 1) * sizeof(wchar_t))) != NULL
(wlen = mbstowcs(wstr, s, len + 1)) != (size_t)-1
(wcsw = wcswidth(wstr, wlen)) = 0)
rv = (size_t)wcsw;
free(wstr);
return rv;
#else
return strlen(s);
#endif
}
Unlike the function in the patch with the same name, mine returns
strlen(s) as fallback on errors (for example ENOMEM). Both are not
thread-save nor fast when used in a loop. Mine assumes that strlen(s)
= mbstowcs(NULL,s,0). Both require POSIX 2001 + XSI extensions.
Instead of ENABLE_NLS, dpkg would of course use HAVE_MBSTOWCS or
similar.
Regards
Carsten
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#675918: dpkg: [S-S-D]: write_pidfile() should not follow symlinks
Hi, thanks for applying and extending the patch that fast! * Guillem Jover [2012-06-05 11:12 +0200]: (a configure script would ease testing patches) I'm not sure what you mean with this? I did not write what I meant ;) What I meant is that it is not obvious without looking into the documentation that autoreconf -f -i is the correct way to generate a configure script. For regular contributors this is not a problem, but if one only plans to send one patch, making this more obvious would ease doing so. For example, a autogen.sh in the repositories root directory with the content below would have made it obvious for me: #/bin/sh autoreconf -f -i Regards Carsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#675918: dpkg: [S-S-D]: write_pidfile() should not follow symlinks
Package: dpkg
Hi,
start-stop-daemon should not follow symlinks:
# ls -l /etc/shadow /var/run/foo.pid
-rw-r- 1 root shadow 662 Apr 10 12:20 /etc/shadow
lrwxrwxrwx 1 nobody nogroup 11 Jun 4 06:00 /var/run/foo.pid - /etc/shadow
# start-stop-daemon --start --verbose --make-pidfile --pidfile
/var/run/foo.pid --exec /bin/true
Starting /bin/true...
# ls -l /etc/shadow /var/run/foo.pid
-rw-r- 1 root shadow 6 Jun 4 07:32 /etc/shadow
lrwxrwxrwx 1 nobody nogroup 11 Jun 4 06:00 /var/run/foo.pid - /etc/shadow
I attached an untested (a configure script would ease testing patches)
patch to fix this. The patch uses O_NOFOLLOW which specified in POSIX
2008 and in Sid it is defined without any additional magic. In Squeeze
one needs to define _GNU_SOURCE to be able to use O_NOFOLLOW.
Carsten
From e181963ad7653f6a73bc84e273654c530d998210 Mon Sep 17 00:00:00 2001
From: Carsten Hey cars...@debian.org
Date: Mon, 4 Jun 2012 09:27:01 +0200
Subject: [PATCH] s-s-d: Do not follow symlinks when creating pidfiles
---
utils/start-stop-daemon.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/utils/start-stop-daemon.c b/utils/start-stop-daemon.c
index ad55097..e2569a4 100644
--- a/utils/start-stop-daemon.c
+++ b/utils/start-stop-daemon.c
@@ -377,8 +377,14 @@ static void
write_pidfile(const char *filename, pid_t pid)
{
FILE *fp;
+ int fd;
+
+ fd = open(filename, O_CREAT | O_WRONLY | O_TRUNC | O_NOFOLLOW, 0644);
+ if (fd == -1)
+ fp = NULL;
+ else
+ fp = fdopen(fd, w);
- fp = fopen(filename, w);
if (fp == NULL)
fatal(unable to open pidfile '%s' for writing, filename);
--
1.7.2.5
Bug#675918: dpkg: [S-S-D]: write_pidfile() should not follow symlinks
* Carsten Hey [2012-06-04 09:36 +0200]: start-stop-daemon should not follow symlinks: # ls -l /etc/shadow /var/run/foo.pid -rw-r- 1 root shadow 662 Apr 10 12:20 /etc/shadow lrwxrwxrwx 1 nobody nogroup 11 Jun 4 06:00 /var/run/foo.pid - /etc/shadow # start-stop-daemon --start --verbose --make-pidfile --pidfile /var/run/foo.pid --exec /bin/true Starting /bin/true... # ls -l /etc/shadow /var/run/foo.pid -rw-r- 1 root shadow 6 Jun 4 07:32 /etc/shadow lrwxrwxrwx 1 nobody nogroup 11 Jun 4 06:00 /var/run/foo.pid - /etc/shadow I forgot to clarify that this is _not_ a security problem in Debian since /var/run is only writeable by root. In custom setups it could be a security problem if a directory writeable by the service is used for the pid files. Carsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673193: apt-get: should remove foreign arch packages even if arch suffix is missing
* David Kalnischkies [2012-05-18 18:15 +0200]: On Fri, May 18, 2012 at 1:22 AM, Carsten Hey cars...@debian.org wrote: * David Kalnischkies [2012-05-17 14:41 +0200]: On Wed, May 16, 2012 at 10:16 PM, Carsten Hey cars...@debian.org wrote: No, dpkg is consistent in it's out-/input as is apt, so no bug. The out-/input just happens to be inconsistent between apt and dpkg. apt's command line tools do not provide a way to list the installed packages, so people using apt on the command line need to use for example dpkg to do so. synaptic users do not have this problem since it provides a complete user interface for the usual package management tasks, at least as long X as is not broken. I don't see the problem here. debian already has a commandline tool to list installed packages, as it has a tool to list the status of a package. ... This existing commandline tool lists installed packages in a way that can't be used to feed packages that should be removed to apt-get. Did you mean 'pkg:arch'? helps a bit, though. The problem with consistency is that in that case we would need to require a user to specify always the architecture if he deals with a M-A:same package. I dislike this because this changes overtime and isn't really easy to discover for a user. Yesterday libsame=1-1 installed fine, now i have to install libsame:native=1-2 to get what i want… (jftr: and the first in debian unreleased dpkg interface agreed with me) This would break debfoster (and many other scripts) way harder than the behavior now as the installation/removal of a library is a way more likely usecase and actually forces them to do a multiarch update, even through many script, howtos and even full-blown programs detailing how to install this and that will never really care about multi-arch (or at least they shouldn't). It also carries the problem that such a tool has to detect which version of APT it deals with (to know if it can/must use the architecture qualifier as e.g. squeeze includes already M-A:same packages). So, in short: You really don't want consistency between apt and dpkg. After reading a non-helpful dpkg error message like: | dpkg: error: --purge needs a valid package name but 'libconfig9' is | not: ambiguous package name 'libconfig9' with more than one installed | instance … and more importantly the need to display this message at all, especially if only one of the packages is installed and the other is removed, but not purged, I have to agree that consistency to the current dpkg interface is not a worthwhile goal. I still think that if the architecture qualifier is missing, installing should default to :native if the package is available there and otherwise try to install the package from a foreign architecture (as apt does), and that removing should default to all architectures. If both, apt and dpkg, would follow this, all the consistency and user interface problems I can think of would then vanish even with co-installable binary packages. Anyhow, since I can't convince you (choose between singular and plural as you like) to move a little bit into this direction, I presumably wouldn't be able to convince you and the dpkg maintainers to adapt apt and dpkg accordingly. apt and dpkg in Squeeze seem to work as expected if arch-qualified package names are passed to them. Since skip-upgrades are not supported anyway, I don't see why tools like debfoster would need to check the apt version. Maybe my concern for consistence inside apt-* is better understandable I think understand why consistency inside apt is worthwhile. Maybe it is also because i regularly remove packages which are not installed in an install command as apt-get can be hinted this way that i don't want this package installed as a dependency of whatever i have requested. The inverse is also true if e.g. removing a bunch of packages by regex and just want to keep a few. (Not sure how many normal users know/use that through.) I'd assume the number of users that use apt-get in this way is rather low ;) I don't know your setup, but it sounds like you have APT::Default-Release set, so apt just does what you said. apt-get source apt/unstable might does the right thing™. That shouldn't have changed too much in squeeze through either, so feel free to add a few more details. There are no apt preferences files and the part of the sources.lists that matches ^deb.*ftp.*debian\.org is: deb http://ftp.de.debian.org/debian squeeze main deb-src http://ftp.de.debian.org/debian sid main But it looks like this problem is fixed in Sid. I locally changed the version of the package debconf in a Sid chroot to a lower number and told apt to use a sources.list with only a deb-src Sid entry and no deb entry and was able to download the debconf source package. Doing the same on Squeeze failed to download the package. So all three issues I mentioned already have been fixed in Sid in a sane way
Bug#539340: Bug#673193: apt-get: should remove foreign arch packages even if arch suffix is missing
* David Kalnischkies [2012-05-17 14:41 +0200]: On Wed, May 16, 2012 at 10:16 PM, Carsten Hey cars...@debian.org wrote: apt-get should remove foreign arch packages even if arch suffix is missing. I know that you disagree, but documenting unintuitive behaviour in the BTS in a good thing and this bug report explains why your reasoning is wrong. In that sentence you(r) is /me, just so that everyone gets who is meant. Sorry for mixing this up. (i think it is unreasonable to change it after wheezy release, but maintainer choice…) That changing it after the release in unreasonable is a good point. Given the unreasonableness of a change after Wheezy's release and that documenting possibly unintuitive behaviour in the BTS of a package with several hundred bugs is not that sane, I think this feature request should be closed during freeze, or, if it is clear that apt will not be changed previously, soonish. No, dpkg is consistent in it's out-/input as is apt, so no bug. The out-/input just happens to be inconsistent between apt and dpkg. apt's command line tools do not provide a way to list the installed packages, so people using apt on the command line need to use for example dpkg to do so. synaptic users do not have this problem since it provides a complete user interface for the usual package management tasks, at least as long X as is not broken. If apt would provide a list sub-command, your explanation that this is not a bug in apt would be reasonable, nevertheless, this bug has severity wishlist, so it is indeed not a bug but a feature request ;) I could invoke the i was first argument here, but the better argument is that dpkg only needs to specify an architecture if a M-A:same package is involved (and in that case it forces it) while apt has to deal with all packages being either native or foreign at all times, so if multiple architectures for a package are available it needs to know which one the user talks about. For convenience native is assumed by default for all packages … As a result of the inconsistency between apt's and dpkg's user interface, tools like debfoster (I CC'd the according 'please implement multiarch' bug) need to print package names with arch suffix on foreign architectures or its users will not always be able to remove the displayed packages using apt-get. It especially needs to pass the packages arch qualified to apt-get if it invokes it itself. If apt and dpkg would be consistent to each other, this behaviour could be documented in the policy so that other tools could rely on it, even in less widely used dpkg frontends. The logic consequence of this bug is through to remove the convenience of installing the foreign package in case no native package is available, not to add even more maybe the user meant something else logic… Your logic seems to be different to mine, anyway, you prefer the current behaviour over both alternatives and I prefer the current and my preferred behaviour over what you mentioned above, thus, at least unless someone else answers, removing the described convenience would all but reasonable. It's up to frontends to guess what the user meant, apt-* usually does what the user said, even through the user might be wrong. I personally think that is better than trying to tell the program that i am not the idiot the program thinks i am and therefore decides to do something else instead. At least for a tools as low-level as apt-*. I agree to what you wrote, but what I understand under the above does not completely match the behaviour of apt-*, for example, on stable with unstable sources, apt-get source apt fails and there is no non-weird way to tell apt-get to do what it did in previous releases, except when you look up the version number previously. I would not ask apt-get to download its sources on a system with only unstable source entries in the sources.list if I did not want to get them. apt-cache show does not preserve the command line order in its output anymore. We already discussed installing essential packages automatically in the past. P.S.: Yeap, this no maintainer thing is by choice and i like it. This explains a lot :) I always wondered why you are not listed in the uploaders field. Regards Carsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673190: dpkg-query: --list should add arch suffix to all foreign arch packages
Package: dpkg Version: 1.16.3 Severity: wishlist dpkg-query --list should add arch suffix to all foreign arch packages. # dpkg --print-architecture amd64 # dpkg -l sc | grep ' sc' | tr -s ' ' ii sc 7.16-3 Text-based spreadsheet with VI-like keybindings # apt-get remove sc ... Package 'sc' is not installed, so not removed. Did you mean 'sc:i386'? 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. # dpkg -s sc | grep Arch Architecture: i386 Actually there are two bugs shown above. One is that dpkg -l omits important information. The other is that apt-get only removes foreign packages if either the arch suffix is added or if the package is not available on the native architecture. The reasoning by apt's maintainers is that in the above case sc:i386 must explicitly have been installed, which is obviously wrong since that a packages is available on one architecture now does not mean that it has been available on this architecture in the past and apt installs foreign packages if the architecture suffix is not added and the package does not exist on the native architecture. Carsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673193: apt-get: should remove foreign arch packages even if arch suffix is missing
Package: apt Version: 0.9.3 Severity: wishlist apt-get should remove foreign arch packages even if arch suffix is missing. I know that you disagree, but documenting unintuitive behaviour in the BTS in a good thing and this bug report explains why your reasoning is wrong. # dpkg --print-architecture amd64 # dpkg -l sc | grep ' sc' | tr -s ' ' ii sc 7.16-3 Text-based spreadsheet with VI-like keybindings # apt-get remove sc ... Package 'sc' is not installed, so not removed. Did you mean 'sc:i386'? 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. # dpkg -s sc | grep Arch Architecture: i386 Actually there are two bugs shown above. One is that dpkg -l omits important information. The other is that apt-get only removes foreign packages if either the arch suffix is added or if the package is not available on the native architecture. The reasoning by apt's maintainers is that in the above case sc:i386 must explicitly have been installed, which is obviously wrong since that a packages is available on one architecture now does not mean that it has been available on this architecture in the past and apt installs foreign packages if the architecture suffix is not added and the package does not exist on the native architecture. Carsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673190: dpkg-query: --list should add arch suffix to all foreign arch packages
* Guillem Jover [2012-05-16 22:46 +0200]:
As long as the user enabled a foreign architecture, and the
dependencies are fulfilled, I don't see why the fact that it's
foreign or not is really important.
There are cases where knowing that a package is installed from arch foo
is interesting, anyhow, collecting examples like filing bugs against
segfaulting programs would not lead us to anywhere.
If the user really wants to know there's always more explicit and
reliable ways to query that, with dpkg-query -W for example.
The dpkg-query -W syntax is too long to type and too complicated to be
used by non-experienced users, but I think there should be an easy way
to query information like the list of all installed packages, their
state, their version and their architecture.
If we ignore multi-arch and dpkg frontends like apt, I see two problems
with dpkg -l:
* The output is designed to be human readable and thus the column
headings are included in the output. People use this human readable
output in scripts and thus hack up ways to remove this headings. One
way to prevent this need for such hacks would have been adding an
additional option (for example --quiet or --verbose to disable or
enable printing of the headings), an other way would have been to
print the headings to stderr, flush stderr and then print the actual
information to stderr.
* There is no way to add a new column without breaking existing
scripts. Currently, the short description starts at column 4, if
a column would be added before the description, the description
would start at column 5; appending a column would be weird because
the description contains spaces, which are also used as column
separator.
If a new option would be added, the above could be prevented easily. The
column's headings and explanations could be send to stderr, and what is
sent to stdout after flushing stderr could be equivalent to:
dpkg-query -W -f
'${db:Status-Abbrev}\t${binary:Package}\t${Version}\t${Architecture}\n' |
column -t
In the man page, it could be mentioned that new columns might be added
in future and that the same package name could occur in the output
multiple times in future versions, and possibly that db:Status-Abbrev
might be extended but the first two letters will not change their
meaning.
Regards
Carsten
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670542: synaptic: please adapt deborphan invocation to work with upcoming multiarch supporting deborphan
* Michael Vogt [2012-05-15 13:59 +0200]: On Mon, May 14, 2012 at 01:17:42AM +0200, Carsten Hey wrote: * Carsten Hey [2012-04-29 00:10 +0200]: This untested but trivial patch fixes synaptic to be able to parse both output formats by stripping the architecture suffix: ... I uploaded a multiarch aware deborphan to delayed/8: ... This will break synaptic's deborphan integration on multiarch enabled systems. Drop me a mail if you want me to NMU above one line patch. Thanks a bunch for this offer and sorry for my late reply, I was traveling. I merged your fix into trunk and it will be part of the next upload (that should happen soon, i.e. this week). Great, thanks! JFTR: synaptic's setPackageOrphaned() sets packages only on the native architecture as orphans, thus foreign arch orphans are not displayed by synaptic if the arch suffix is stripped (but stripping makes the native arch orphans shown again). Due to the way deborphan and synaptic's deborphan integration work, this does _not_ affect the correctness of the displayed list of orphans. I think listing foreign arch orphans in synaptic is nice to have, but not more than that. Carsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672829: upgrade-system: please bump dependency on deborphan to 1.7.28.7 after it has reached unstable
* Martin-Éric Racine [2012-05-14 09:24 +0300]: 2012/5/14 Carsten Hey cars...@debian.org: as discussed, please bump dependency on deborphan to 1.7.28.7 to prevent endless loops in Ubuntu Q… and in weird cases in Debian. The multiarch aware deborphan release 1.7.28.7 has been uploaded to the delayed queue and will reach unstable on 2012-05-21. Source: deborphan Binary: deborphan Version: 1.7.28.7 Distribution: unstable Delayed-Until: 2012-05-21 22:46:33 Actually, I was wondering if it wouldn't make more sense for the multiarch-aware deborphan to depend upon multarch-aware dpkg or more recent? Since it does not require a multiarch-aware dpkg, I don't think it should depend on a multiarch-aware dpkg. It's upgrade-systems that enters an endless loop if it is run with deborphan 1.7.28.6 or earlier on multiarch enabled systems (which of course requires a recent dpkg). upgrade-systems relies on apt to remove the packages that are displayed by deborphan. This is nothing deborphan can guarantee, for example apt won't remove itself without using --force-whatever. It is mostly save to rely on this behaviour, though. If you need this you must ensure that the known exceptions won't occur, for example, don't run deborphan with options that could show apt as orphaned, or, as in this case, don't run an old deborphan on mutliarch-enabled systems. Carsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672829: upgrade-system: please bump dependency on deborphan to 1.7.28.7 after it has reached unstable
* Carsten Hey [2012-05-14 16:53 +0200]: * Martin-Éric Racine [2012-05-14 09:24 +0300]: 2012/5/14 Carsten Hey cars...@debian.org: as discussed, please bump dependency on deborphan to 1.7.28.7 to prevent endless loops in Ubuntu Q… and in weird cases in Debian. The multiarch aware deborphan release 1.7.28.7 has been uploaded to the delayed queue and will reach unstable on 2012-05-21. Source: deborphan Binary: deborphan Version: 1.7.28.7 Distribution: unstable Delayed-Until: 2012-05-21 22:46:33 Actually, I was wondering if it wouldn't make more sense for the multiarch-aware deborphan to depend upon multarch-aware dpkg or more recent? Since it does not require a multiarch-aware dpkg, I don't think it should depend on a multiarch-aware dpkg. It's upgrade-systems that enters an endless loop if it is run with deborphan 1.7.28.6 or earlier on multiarch enabled systems (which of course requires a recent dpkg). I forgot to state the obvious ;) You'd need to wait with the upload until 1.7.28.7 has reached unstable, or upload to the delayed queue. Carsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670542: synaptic: please adapt deborphan invocation to work with upcoming multiarch supporting deborphan
* Carsten Hey [2012-04-29 00:10 +0200]:
This untested but trivial patch fixes synaptic to be able to parse both
output formats by stripping the architecture suffix:
--- a/common/raptoptions.cc
+++ b/common/raptoptions.cc
@@ -222,8 +222,8 @@ void RAPTOptions::rereadOrphaned()
return;
}
while (fgets(buf, 254, fp) != NULL) {
- //mvo: FIXME this sucks (remove newline at end)
- buf[strlen(buf) - 1] = 0;
+ // remove newline at end and strip architecture suffix
+ buf[strcspn(buf, \n:)] = '\0';
//cout buf: buf endl;
setPackageOrphaned(buf, true);
}
I uploaded a multiarch aware deborphan to delayed/8:
Source: deborphan
Version: 1.7.28.7
Distribution: unstable
Delayed-Until: 2012-05-21 22:46:33
This will break synaptic's deborphan integration on multiarch enabled
systems.
Drop me a mail if you want me to NMU above one line patch.
Carsten
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672829: upgrade-system: please bump dependency on deborphan to 1.7.28.7 after it has reached unstable
Package: upgrade-system Severity: wishlist Hi, as discussed, please bump dependency on deborphan to 1.7.28.7 to prevent endless loops in Ubuntu Q… and in weird cases in Debian. The multiarch aware deborphan release 1.7.28.7 has been uploaded to the delayed queue and will reach unstable on 2012-05-21. Source: deborphan Binary: deborphan Version: 1.7.28.7 Distribution: unstable Delayed-Until: 2012-05-21 22:46:33 Carsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670106: [Pkg-sysvinit-devel] Bug#670106: initscripts: please ignore noauto sysfs entries in fstab
* Carsten Hey [2012-04-30 02:00 +0200]: * Roger Leigh [2012-04-29 23:19 +0100]: I was just thinking, is there a way to detect if the system was bootstrapped with grml-bootstrap compared with plain debootstrap? If that was the case, we could put a specific check for that in, and clean up the fstab if so. It would mean everyone else would get the configuration preserved, and only the broken ones get updated, which I think would be a reasonable compromise if possible. grml-debootstrap copies files into the chroot that is being created: cp $VERBOSE $CONFFILES/chroot-script $MNTPOINT/bin/chroot-script cp $VERBOSE $CONFFILES/config$MNTPOINT/etc/debootstrap/ ... If you choose this way of solving the issue, please drop us a mail so that we can look up if tests like the above would work with all relevant grml-debootstrap versions. This still holds, if you think detecting grml-debootstrap'ed systems is the way to go, please drop us a mail previously. This would of course not fix other systems with such a buggy fstab entry. how do other distributions handle noauto in this situation? Do they respect it, ignore it, or not look at fstab at all? I know that at least some switched from requiring an /sys fstab entry to not requiring it, but I do not know what others do if there is still such a line. This is what I meant by not being sure about the answers. Anyway, you seem to consider this questions to be important. If you think that they are that important that the outcome of this discussion depends on it, I think the behaviour of other distributions can be investigated, it just will need some time. For current systems, I think it's useful to know what systemd and upstart are doing. systemd is simple enough to test on Debian; for upstart we can look at Ubuntu. Part of the reason for the mount changes was to align the mount options with those used in the initramfs (copied both ways, but mainly updating the initramfs with the initscripts defaults), and also with systemd so that we have consistent behaviour across all init systems and boot methods. So if all the others choose to not respect noauto for specific mounts, that's a point in favour of doing that. Being consistent to other init systems in Debian makes sense. I'll send an other mail after knowing this. I installed Fedora 16 (uses systemd as init and was released in November 2011) and the just released Ubuntu LTS (uses upstart) into a KVM container and added a noauto sysfs line for /sys that matches (besides noauto) their default mount options to /etc/fstab on both systems. On both systems, /sys was mounted despite the noauto sysfs entry. I don't know if upstart and systemd on Debian behave differently than on their native distributions, but if they do, then I'd tend to consider this derivation to be buggy unless there is a valid reason for it. Regards Carsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671507: debian-policy: policy section 7.4 conflicts with section 10.1
* Jonathan Nieder [2012-05-04 17:35 -0500]: Carsten Hey wrote: * Patrick Ouellette [2012-05-04 13:38 -0400]: If you read the entire section 7.4 is seems entirely reasonable to create a package with an executable name that already exists in Debian with a package conflicts tag if the two executables have different functionality. But I want to play the boulder dash clone epiphany whilst browsing the web using the epiphany browser! This misses the point. The goal of policy §10.1 is that other packages (in Debian and elsewhere) can rely on a command name having a single, reliable meaning, independent of the $PATH setting and installed package set. What you describe is one goal of §10.1's first paragraph, an other is the one I hinted at, there is no reason to prohibit users to install two unrelated programs that both use the same executable name upstream. Due to support for partial upgrades, the situation that it is not clear to a third package which program an executable name refers to (unless package relation ship fields are used to circumvent this) is nothing new in Debian and happend for example with epiphany. Given that the affected maintainers are aware of it (for example they know that which command would not lead to a useful result) and that these situations are only temporary exceptions, then Debian is able to handle such situations well as it did already in the past. Carsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671507: debian-policy: policy section 7.4 conflicts with section 10.1
* Patrick Ouellette [2012-05-04 13:38 -0400]: Conflicts should be used when two packages provide the same file and will continue to do so /usr/bin/sendmail is provided by citadel-mta, courier-mta, dma, esmtp-run, exim4-daemon-heavy, exim4-daemon-light, ... That is what the policy means by same file (but I agree that this wording is a bit misleading), and not the same filename in a different directory - otherwise all packages that provide a copyright file in /usr/share/doc/*/ would have to conflict with each other. If you read the entire section 7.4 is seems entirely reasonable to create a package with an executable name that already exists in Debian with a package conflicts tag if the two executables have different functionality. But I want to play the boulder dash clone epiphany whilst browsing the web using the epiphany browser! Carsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671120: debian-policy: suggest delegating binary name conflicts to tech-ctte in last resort
Package: debian-policy Severity: wishlist Please suggest delegating binary name conflicts to the tech-ctte in last resort. The common reading of the according section does neither match what seems to be the original intention [1] nor my common sense. [1] http://lists.debian.org/879142cjni@slip-61-16.ots.utexas.edu * Russ Allbery [2012-05-01 10:28 -0700]: Carsten Hey cars...@debian.org writes: The origin of what the policy suggests to do if there is no consensus is a mail from Guy Maor 879142cjni@slip-61-16.ots.utexas.edu, in which he writes: | That's basically a stick to force developers to reach a consensus. Christian Schwarz uploaded this change later in this month. I don't think that there ever will be a consensus in all those discussions without discussing in a reasonable way (which failed in the past multiple times). Previously to this, asking the VP of Engineering for a decision was suggested in this thread. I have to admit that I'm tempted to change Policy from if there's no consensus, rename both of them to if there's no consensus, try harder to reach a consensus, and the technical committee decides in last resort. technical committee decides in last resort could be read as if it would decide without being consulted. To avid such a misreading, a clearer wording that for example uses the word 'consulted' could be used. Besides this minor nitpicking, it would be great if the policy could be adapted as described in the quoted mail. Most of the time, renaming both of them isn't the right answer. I'm even unable to imagine a case where renaming both would be the right answer. Regards Carsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670106: [Pkg-sysvinit-devel] Bug#670106: initscripts: please ignore noauto sysfs entries in fstab
* Roger Leigh [2012-04-29 23:19 +0100]: On Sat, Apr 28, 2012 at 11:16:48PM +0200, Carsten Hey wrote: So the correct thing could, besides doing it manually, only be done in a maintainer script of an essential package, but as you explained, doing this would be wrong. I think we agree that there is no clean way to remove the line automatically. I was just thinking, is there a way to detect if the system was bootstrapped with grml-bootstrap compared with plain debootstrap? If that was the case, we could put a specific check for that in, and clean up the fstab if so. It would mean everyone else would get the configuration preserved, and only the broken ones get updated, which I think would be a reasonable compromise if possible. grlm-debootstrap copies files into the chroot that is being created: cp $VERBOSE $CONFFILES/chroot-script $MNTPOINT/bin/chroot-script cp $VERBOSE $CONFFILES/config$MNTPOINT/etc/debootstrap/ Removing a part of them has been added in a commit after the fstab has been fixed, but I don't know if this clean up was always (or rather in the four years the fstab error existed) missing in grml-debootstrap or if it has been deleted whilst refactoring, but this can be looked up. Users might delete either /bin/chroot-script, /etc/debootstrap/ or both after installation. Normally I don't delete any of them, but I don't know how others handle this or if others even know that there are still files needed during installation on their system. Possible ways to detect 'grml-bootstrap'ed systems include (given that the files have not been deleted manually and that there are no relevant changes grlm-debootstrap in the relevant timeframe): $ fgrep -q -x done /etc/debootstrap/stages/fstab 2/dev/null $ test -x /bin/chroot-script $ [ -x /bin/chroot-script ] grep -qx '^# Purpose:.*executed.*via grml-debootstrap$' /bin/chroot-script Unlike the second line, the third will not wrongly return 0 if a user created an unrelated script with the same name. One way to raise the probability of a correct result in case the user deleted either the directory or the file is to combine the first and the last line. If you choose this way of solving the issue, please drop us a mail so that we can look up if tests like the above would work with all relevant grml-debootstrap versions. If the admin deliberately configured a mount with noauto, Is there any valid use-case to configure a sysfs mount to /sys with noauto? If so, was there an according bug report before doing so had this effect? Not that I am aware of for the host system. I assume the reason for these questions is obvious; without a valid use case for this, both options seem to be reasonable for me, and with a valid use case only initscripts' current behaviour would have been reasonable. we would be deliberately trashing their configuration. A regression leading to unbootable systems sounds like a bug to me, even if the previously working configuration is considered to be buggy. It's a bug. And we should not break any systems if we can help it. But the change in behaviour is only exposing a latent bug originating elsewhere. I fully agree. how do other distributions handle noauto in this situation? Do they respect it, ignore it, or not look at fstab at all? I know that at least some switched from requiring an /sys fstab entry to not requiring it, but I do not know what others do if there is still such a line. This is what I meant by not being sure about the answers. Anyway, you seem to consider this questions to be important. If you think that they are that important that the outcome of this discussion depends on it, I think the behaviour of other distributions can be investigated, it just will need some time. For current systems, I think it's useful to know what systemd and upstart are doing. systemd is simple enough to test on Debian; for upstart we can look at Ubuntu. Part of the reason for the mount changes was to align the mount options with those used in the initramfs (copied both ways, but mainly updating the initramfs with the initscripts defaults), and also with systemd so that we have consistent behaviour across all init systems and boot methods. So if all the others choose to not respect noauto for specific mounts, that's a point in favour of doing that. Being consistent to other init systems in Debian makes sense. I'll send an other mail after knowing this. Regards Carsten P.S.: No, you are not the only one. The current situation is more or less an evolution of what started years ago. If needed, I think there is a large enough community to provide alternatives before people become completely insane and create a tightly integrated Gnome distribution (what btw. already has been proposed) based on Linux core. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas
Bug#670501: gtkorphan: list of non-orphaned packages contains orphaned packages
* Carsten Hey [2012-04-26 10:36 +0200]: Whilst checking gtkorphan I noticed that it uses a colon to separate package names in the code that seems to be supposed to remove orphaned packages from deborphans --show-deps output. Back then when you wrote gtkorphan, a colon was a good choice as separator, but nowadays it is used to separate package names from the architecture, which can lead to undesirable results of such algorithms. The colon using code in gtkorphan_ops.pm is: my $orphaned = join(:,@orphaned); $orphaned=$orphaned.:; I think it should use for example # instead of :. I still think using a colon as separator is not that robust nowadays and changing this might make gtkorphan more robust, regardless of what I write below. Because the above is kind of fishy nowadays, I checked if the orphaned packages from deborphans --show-deps output are removed as seems to be intended. They are not removed, neither when used with a deborphan that prints arch suffixes, nor when used with one that does not print arch suffixes. Since deborphan does not print orphaned packages if -d is used, I assume the code does the opposite of what I thought at first sight. So this part of the bug report seems to be invalid, although I think listing orphaned packages in a tab non-orphaned packages is not what most users would expect. Please consider closing this bug if listing orphaned packages in the list of non-orphaned packages is really intended. Carsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670716: gtkorphan: please use deborphan's forward compatible options
Package: gtkorphan
Tags: patch
Hi,
please use deborphan's forward compatible options
--all-packages-pristine and --show-deps-pristine instead of
--all-packages and --show-deps.
The output format of --all-packages will need to change when Debian
replaces sections with tags and the output format of --show-deps is kind
of ugly and thus might change too. To provide a non-changing interface
for deborphan's frontends, the options --all-packages-pristine and
--show-deps-pristine have been introduced a while ago. After checking
all known reverse dependencies (except of one that is broken anyway and
presumably will be removed from Debian soon), it has been noticed that
gtkorphan is the only package in Debian that needs them.
More information about these options can be found in the file
'/usr/share/doc/deborphan/README.frontends', which is shipped in
deborphan 1.7.28.6 and later.
Uploading this change in the time frame from now (Ubuntu LTS is
releasing today) to the upcoming freeze of Debian Wheezy guarantees that
the installed deborphan release provides these options (even during
partial updates and without the need to add a versioned dependency) and
also ensures that during the next Debian release cycle deborphan is able
to adapt the output of --all-packages or --show-deps if needed without
breaking gtkorphan.
I attached a patch that contains the needed changes. I have not yet
tried to build with this patch, anyway, this patch is trivial enough to
assume that it will not cause any breakage.
Please also consider adding the Spanish translation file that can be
found in the bug http://bugs.debian.org/537825 to your gtkorphan upload.
Regards
Carsten
P.S.: The bugs I reported two days ago were found during checking
deborphan's reverse dependencies and are, unlike this one, not
important to be fixed soon (or even to be fixed at all).
diff --git a/lib/gtkorphan_ops.pm b/lib/gtkorphan_ops.pm
index 6b2581b..b85ed4d 100644
--- a/lib/gtkorphan_ops.pm
+++ b/lib/gtkorphan_ops.pm
@@ -227,7 +227,7 @@ sub get_orphan_options
$options .= --find-config if ($find_config-get_active()) ;
#all packages checked?
- $options .= --all-packages if ($find_all-get_active()) ;
+ $options .= --all-packages-pristine if ($find_all-get_active()) ;
#GUESS options
@@ -608,7 +608,7 @@ sub populate_regular
$application-tv_regular-set_sensitive(TRUE);
#get orphaned to remove from list
- #(deborphan bug on -d option
+ #(deborphan bug on --show-deps-pristine option
$command = $application-dorph;
my @orphaned = `$command`;
chomp (@orphaned);
@@ -617,7 +617,7 @@ sub populate_regular
#build and spawn command line
- $command = $application-dorph. -Psz -d.$options;
+ $command = $application-dorph. -Psz --show-deps-pristine.$options;
my @libraries = `$command`;
chomp (@libraries);
@@ -666,7 +666,7 @@ sub get_regular_options {
$check_all=$gtkorphan_app::gladexml-get_widget('check_all_regular');
#check_all checked?
- $options .= -a if ($check_all-get_active()) ;
+ $options .= --all-packages-pristine if ($check_all-get_active()) ;
return $options;
Bug#670106: [Pkg-sysvinit-devel] Bug#670106: initscripts: please ignore noauto sysfs entries in fstab
* Henrique de Moraes Holschuh [2012-04-28 12:11 -0300]: On Wed, 25 Apr 2012, Carsten Hey wrote: The problem is that installing Squeeze via grml-debootstrap perfectly works and after upgrading to Wheezy udev will not start. A wrongly generated /etc/fstab can't be fixed for existing systems by releasing a fixed version of a tool that is only run once during installation. The correct thing to do would be to fix the broken /etc/fstab, then... There is only one reliable way to do so: in initscripts' preinst. But if it does not need to be that reliable, then postinst would be fine too in case you'd like to keep the preinst scripts of essential packages (and their dependencies) as small or as simple as possible. initscripts is currently respecting what you obviously *think* are the wishes of the admin. Since /sys is nowadays mounted on most or all Which means we're following the principle of least surprise... In general, I don't consider changing a programs behaviour without a reason to do so to match the principle of least surprise. Not starting udev because of this change (not mounting /sys in Wheezy with the same config that works in Squeeze) doesn't make the situation any better. And you can mount /sys more than once, in weird places for whatever reasons. Those could conceivably be noauto, so we'd have to ignore noauto only on lines that attempt to mount the special filesystems where we'd expect them to be mounted in the first place. I agree, and I don't think that this would be a problem. Alternatively fstab entries could be ignored entirely if the file system is sysfs, the mountpoint is /sys and the options contain noauto; and similar for /proc. In my opinion, the underlying problem is that there is no clear and distribution independent semantic of noauto when used in a fstab entry for those standard virtual file systems. If there would be such a clear The other distros ignore noauto? Or do them ignore /etc/fstab entirely for the special filesystems? I suspect it is the later. I'm neither sure about the answers to your questions not about their intention. Regards Carsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670106: [Pkg-sysvinit-devel] Bug#670106: initscripts: please ignore noauto sysfs entries in fstab
[ Dropping hmh from Cc, I was not sure if he's one of the uploaders and thus should receive the mail anyway - but I looked it up now. ] * Roger Leigh [2012-04-28 20:17 +0100]: On Sat, Apr 28, 2012 at 06:21:58PM +0200, Carsten Hey wrote: * Henrique de Moraes Holschuh [2012-04-28 12:11 -0300]: The correct thing to do would be to fix the broken /etc/fstab, then... There is only one reliable way to do so: in initscripts' preinst. But if it does not need to be that reliable, then postinst ... initscripts can't fix this problem /at all/ by altering /etc/fstab. ... So the correct thing could, besides doing it manually, only be done in a maintainer script of an essential package, but as you explained, doing this would be wrong. I think we agree that there is no clean way to remove the line automatically. If the admin deliberately configured a mount with noauto, Is there any valid use-case to configure a sysfs mount to /sys with noauto? If so, was there an according bug report before doing so had this effect? we would be deliberately trashing their configuration. The admin relied on undocumented and undefined behaviour if a sysfs mount to /sys with noauto was deliberately configured, and this configuration attempt was never successful in any stable Debian release. In general, I don't consider changing a programs behaviour without a reason to do so to match the principle of least surprise. ... ... This made everything more readable, consistent and maintainable, as well as fixing a number of bugs. It also made respecting various mount options such as noauto consistent across the board. However... I really don't think the new behaviour is buggy or broken. If anything, it's a big improvement over the old code. Well, better code and consistent behaviour (over different mount options or over different releases) are not necessarily the same. I'm not sure I think this is a bug in initscript at all, really. It's breaking on a file generated by a buggy grml-debootstrap, All but producing the same fstab entries as the debian-installer would is in my opinion a bug in any alternative installer. but I don't think that is in any way initscripts' responsibility. That initscripts does not fix bugs introduced by other packages is not a bug in initscripts. initscripts responsibility in this case is in my opinion that it should not render systems that worked well under an previous stable release to be unbootable after upgrading to an new release. A regression leading to unbootable systems sounds like a bug to me, even if the previously working configuration is considered to be buggy. In my opinion, the underlying problem is that there is no clear and distribution independent semantic of noauto when used in a fstab entry for those standard virtual file systems. If there would be such a clear The other distros ignore noauto? Or do them ignore /etc/fstab entirely for the special filesystems? I suspect it is the later. I'm neither sure about the answers to your questions nor about their fixed typo here ^ intention. It sounds quite straightforward to me: Yes, the question is indeed straightforward. how do other distributions handle noauto in this situation? Do they respect it, ignore it, or not look at fstab at all? I know that at least some switched from requiring an /sys fstab entry to not requiring it, but I do not know what others do if there is still such a line. This is what I meant by not being sure about the answers. By not being sure about the intention I meant this: Since Debian Squeeze handles such lines different from Debian Wheezy, we already got two major distributions (stable and testing) that assume a different semantic. If we would check how other distributions handle this, we would (independent of the result) get at least two different behaviours in major distributions and I don't see which conclusion could be drawn from some do this and others do this. Even if all would assume the same semantic, due to a lacking standard like document or reference implementation, no one could guarantee that some distributions do not switch to a different behaviour the next day (even with a standard no one could guarantee this, but then we at least would know that they are broken and how to do it correctly). Anyway, you seem to consider this questions to be important. If you think that they are that important that the outcome of this discussion depends on it, I think the behaviour of other distributions can be investigated, it just will need some time. Regards Carsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670542: synaptic: please adapt deborphan invocation to work with upcoming multiarch supporting deborphan
tags 670542 + patch
thanks
* Carsten Hey [2012-04-26 16:29 +0200]:
* Pass an option to deborphan to let it print it's output in the way
you like, or teach synaptic to parse both output formats.
This untested but trivial patch fixes synaptic to be able to parse both
output formats by stripping the architecture suffix:
--- a/common/raptoptions.cc
+++ b/common/raptoptions.cc
@@ -222,8 +222,8 @@ void RAPTOptions::rereadOrphaned()
return;
}
while (fgets(buf, 254, fp) != NULL) {
- //mvo: FIXME this sucks (remove newline at end)
- buf[strlen(buf) - 1] = 0;
+ // remove newline at end and strip architecture suffix
+ buf[strcspn(buf, \n:)] = '\0';
//cout buf: buf endl;
setPackageOrphaned(buf, true);
}
Adapt synaptic to work with multiarch enabled deborphan versions:
-
All additional options intended to be used by deborphan's frontends are
documented in /usr/share/doc/deborphan/README.frontends on an up to date
Debian sid.
Reimplement a subset of deborphan:
--
Trying to prevent the need to discuss details afterwards might have lead
to a bit too verbose description.
In a nutshell:
* create a set of possibly orphaned packages you want to check
* create a set of all dependencies of all installed packages
* remove packages that are in the second set from the first
* do something sane with Provides:, depending on your data structure
(Squeeze has 180 packages in main/{old,}libs with a Provides: field
and 2695 packages without.)
* Get a set D of all Depends: and all Recommends: ...
deborphan by default also considers Suggests: as dependency.
Enhances: might be worth considering too.
Regards
Carsten
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670652: deborphan treats packages on hold as uninstalled
Hi, please Cc me on answers. I only saw your bug report because I was looking up bug numbers for debian/changelog (maintaining deborphan is currently transitioning from me to a team I'll not be part of and I'm not subscribed to the team's list). * Jakub Wilk [2012-04-27 17:38 +0200]: As far as I can see, deborphan treats packages that are on hold like if they were not installed: $ deborphan deborphan deborphan sbuild $ echo 'deborphan hold' | sudo dpkg --set-selections $ deborphan deborphan deborphan: package deborphan not found or not installed You hit the presumably only case where deborphan treats packages on hold as being uninstalled. A possible changelog entry for the bugfix is: * Imply --force-hold in show-deps mode. Closes: #670652 The fix itself is obvious. A workaround you could to use is to use the option -H when listing a package's dependencies using deborphan. Commands I used for testing are: $ dpkg --get-selections | grep ubuntu-dev-tools ubuntu-dev-toolshold $ deborphan sbuild sbuild ubuntu-dev-tools $ deborphan -H sbuild sbuild ubuntu-dev-tools $ deborphan ubuntu-dev-tools deborphan: package ubuntu-dev-tools not found or not installed $ deborphan -H ubuntu-dev-tools ubuntu-dev-tools Regards Carsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670652: deborphan treats packages on hold as uninstalled
* Carsten Hey [2012-04-27 21:07 +0200]: * Jakub Wilk [2012-04-27 17:38 +0200]: As far as I can see, deborphan treats packages that are on hold like if they were not installed: $ deborphan deborphan deborphan sbuild $ echo 'deborphan hold' | sudo dpkg --set-selections $ deborphan deborphan deborphan: package deborphan not found or not installed You hit the presumably only case where deborphan treats packages on hold as being uninstalled. This should have been: You hit the presumably only case where deborphan _wrongly_ treats packages on hold as being uninstalled. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670499: gtkorphan: non-root users should be able to run gtkorphan in restricted mode
Package: gtkorphan Severity: wishlist gtkorphan is not only a tool that can be used to remove orphaned packages, it can also be used to display them. Displaying package names is nothing that should require being root. An error window is shown if one starts gtkorphan as non-root user and then gtkorphan is closed. I think it should warn non-root users instead that they will not be able to remove packages without being root, but it should start gtkorphan anyway - with the 'Ok' button disabled. Carsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670500: gtkorphan: please use deborphan's --print-guess-list option to generate @GuessList
Package: gtkorphan Severity: wishlist Please use deborphan's --print-guess-list option described below to generate @GuessList in lib/gtkorphan_ops.pm instead of a using a hardcoded list. The rationale for this is that over the time additional guess options were and will be added and maintaining this list separately in gtkorphan is not ideal. Removing guess options would be wrong and I don't think this will ever happen, so nothing will break if you do not switch to using --print-guess-list. Since i18n and glade is involved in generating the according menu, this might not be that straightforward to implement. As you know, --guess-section is actually a bit misleading; mapping this option to wrong section in your menu was a very good choice. Such mappings should not be lost if gtkorphan switches to using --print-guess-list. deborphan in Squeeze and later contains some options intended to be used by deborphan's frontends: --print-guess-list (since version 1.7.28.2 or Squeeze) This prints all available guess options, separated by newline characters. On Squeeze, the output is: common data debug dev doc dummy interpreters kernel mono perl pike python ruby section If this option is used by gtkorphan, there are three obvious ways to ensure that deborphan is not passed an option it does not understand. Adding a versioned dependency on deborphan is the first one; checking if the option is available using below described --check-options and waiting to switch to --print-guess-list until Wheezy is released are the other two. --check-options (since version 1.7.28.2 or Squeeze) This option causes deborphan to exit after option parsing. The exit status is zero if there was _no_ option parsing error and not zero otherwise. The current implementation does not prevent output on stderr, e.g., caused by getopt(). If the action performed by a to be checked option is performed during option parsing, as it is done for --print-guess-list, output on stdout might happen and the remaining options might be ignored, i.e., only one option can be reliably checked by one deborphan invocation. Thus the correct and supported way to check if the installed deborphan has the option --print-guess-list is to run deborphan --check-options --print-guess-list /dev/null 21 and to check if it exists with status 0 (available) or any other status (not available). A future implementation might include a more powerful --check-options implementation, for example, one that never prints anything to stdout or stderr if --check-options is the first argument and that is able to check up to seven options at once by setting the according bits in the exit status (2^7=128). --show-arch, --no-show-arch (both will be available in version 1.7.28.6 and later or in Wheezy) Always/never print packages with architecture suffixes, for example apt:i386 instead of apt. This applies to the output in --check-deps mode and when printing orphaned packages. It does not apply to keep related options. When not used, deborphan chooses --show-arch on multiarch enabled systems and --no-show-arch on other systems. --all-packages-pristine (since version 1.7.28.2 or Squeeze) Same as --all-packages, except that its output format will not change in future (implying --show-sections will be all but sane if sections will be replaced by debtags in Debian, so this implication might be removed). Regards Carsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670501: gtkorphan: list of non-orphaned packages contains orphaned packages
Package: gtkorphan Severity: minor To support multiarch, deborphan will on multiarch enabled systems print all packagenames (except of when --list-keep is used) with an architecture suffix appended. I checked if this change will break gtkorphan - it does not, gtkorphan works greatly with architecture suffixes. Whilst checking gtkorphan I noticed that it uses a colon to separate package names in the code that seems to be supposed to remove orphaned packages from deborphans --show-deps output. Back then when you wrote gtkorphan, a colon was a good choice as separator, but nowadays it is used to separate package names from the architecture, which can lead to undesirable results of such algorithms. The colon using code in gtkorphan_ops.pm is: my $orphaned = join(:,@orphaned); $orphaned=$orphaned.:; I think it should use for example # instead of :. Because the above is kind of fishy nowadays, I checked if the orphaned packages from deborphans --show-deps output are removed as seems to be intended. They are not removed, neither when used with a deborphan that prints arch suffixes, nor when used with one that does not print arch suffixes. Regards Carsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670502: gtkorphan: gui does not disable the --all-packages box if the --find-config box is checked
Package: gtkorphan Severity: wishlist If I do this: - start gtkorphan - click on 'Options' - check 'Show uninstalled ...' aka --find-config - check 'Show all ...' aka --all-packages then the list of packages does not change due to checking 'Show all ...'. The reason for this is that deborphan's --find-config implies --all-packages (this has not changed since --find-config was implemented). I think the 'Show all ...' checkbox should be disabled if 'Show uninstalled ...' is checked, so that the former can not be checked or unchecked until 'Show all ...' is unchecked again. Carsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670503: gtkorphan: please consider using apt-get instead of dpkg to remove packages
Package: gtkorphan Severity: wishlist Summary: Please consider using apt-get instead of dpkg to remove packages. If dpkg is used directly, the hook scripts are not run. Verbose: Apt has the widely used feature of dpkg hooks. A nowadays rather common use case for this feature is to feed the changes done in /etc during package installations into a version control system, but there are many other uses for this. rw mounting a readonly /usr is an other one, and this is the classical argument for using apt and not dpkg in scripts like gtkorphan or orphaner. Actually I consider this to be a bug in dpkg, which should IMO instead of apt contain and run these hooks - apt could then if needed invoke dpkg in a way that delays or skips running these hooks if running the hooks on every dpkg invokation is not desirable when used together with apt. Until someone convinces dpkg's and apt's maintainers to fix this situation (or writes patches and convinces them to accept them), these hooks are not run if gtkorphan is used to remove a package. If gtkorphan would use apt-get instead of dpkg to remove packages, then these hooks would be run as intended. It would then need to depend on apt. Carsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670507: p.d.o: section tasks is missing
Package: www.debian.org User: www.debian@packages.debian.org Usertag: packages Hi, the section 'tasks' is missing on http://packages.debian.org/unstable/ and http://packages.debian.org/testing/. projectb= select s.section, s.created from section s where s.section = 'tasks'; section |created -+--- tasks | 2011-04-01 15:31:59.554227+00 Regards Carsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670542: synaptic: please adapt deborphan invocation to work with upcoming multiarch supporting deborphan
Package: synaptic
synaptic is the only[1] blocker before deborphan with multiarch support
can be uploaded. The current synaptic with multiarch support does not
display any package as orphaned if it is used with the upcoming
deborphan release on a multiarch enabled system. The other reverse
dependencies of deborphan work fine with it.
There are basically two sane ways to fix this:
* Pass an option to deborphan to let it print it's output in the way
you like, or teach synaptic to parse both output formats.
* Reimplement the subset of deborphan that you use. An advantage of
this is that this part of synaptic wouldn't require an additional
package to be installed for finding orphans anymore.
Adapt synaptic to work with multiarch enabled deborphan versions:
-
I assume that you don't do anything related to deborphan's keep file,
--exclude lists or --show-deps mode; thus I skip explaining how arch
suffixes are handled in these cases.
If the option --show-arch is used, arch suffixes are always printed,
e.g., 'apt:amd64' instead of 'apt'. If the option --no-show-arch is
used, arch suffixes are never printed, that is, it's output is the same
as it is since ten years. If none of these two options is used,
deborphan decides if it prints all packages with arch suffix, or if it
prints all packages without arch suffix. Since deborphan is for
non-relevant reasons not able to ask dpkg if the system has multiarch
enabled, it instead checks if packages from more than one architecture
are installed ('all' is not considered to be an architecture in this
case).
These options are not documented in the man page due to a missing
plausible use case besides usage in deborphan's frontends.
The correct way to check if the above mentioned option --show-arch
(checking for --no-show-arch is equivalent) is available on a system's
deborphan is:
$ deborphan --check-option --show-arch /dev/null 21
The exit status is 0 if and only if the option is available.
Reimplement a subset of deborphan:
--
Reimplementing this subset is way more easy that one would expect.
A naive algorithm with quadratic runtime regarding the number of
installed packages is also possible, but the one below should be faster
and it is still simple. If you already have built a graph of all
package relationships, you could use a simple linear time algorithm.
The algorithm below uses naive set theory and can be implemented using
the standard algorithm header:
* Abort if any package is half-installed, half-configured, unpacked,
triggers-awaited or triggers-pending.
* Get a set A of all installed packages that are in section 'libs' or
'oldlibs', but not in base nor marked as $insert_weired_field_names.
* Get a set B of all virtual packages provided by any package in A.
* Create a set C that is a set_union of A and B. A and B are not
needed anymore. (Obviously, if implemented in C++, you wouldn't have
created three sets up to now.)
* Get a set D of all Depends: and all Recommends: (summarized under the
term dependencies from now on) of any installed package, ignoring
versions. To be sure that the final result consists only of packages
that are orphaned, regardless of decisions done by an advanced
solver, alternative dependencies must be parsed as if there would be
a dependency on all alternatives, for example, foo | bar must be
considered to be equivalent to foo, bar.
* Create a set E that is a set_difference of packages in C but not in
D. No package in E has a non-virtual reverse dependency from any
installed package.
* For all packages X in E, check if all virtual packages provided by
package X are also in E. If all provides are in E, then X has no
reverse dependency from any virtual package, and due to above point
no reverse dependency at all. Since X is also in section libs or
oldlibs and not in base (see second point), it would be considered to
be orphaned by deborphan (there are non-relevant historical
exceptions to this).
The above has one bug, packages depending on them self are never
considered to be an orphan, but this happens rarely. Circular
dependencies are not detected too, but they are seldom enough to be
ignored in synaptic, and adapting synaptic's UI for circular
dependencies would be a mess.
Regards
Carsten
[1] The package 'packagesearch' is broken anyway in sid and it is not
part of precise, so I did not manually check it, nor did I read
it's source.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670429: debian-policy: section tasks is missing
Package: debian-policy Hi, 2.4 Sections is missing the section 'tasks': projectb= select s.section, s.created from section s where s.section = 'tasks'; section |created -+--- tasks | 2011-04-01 15:31:59.554227+00 This section is also missing on http://packages.debian.org/unstable/. Is www.debian.org the correct package to report this to? Regards Carsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670106: initscripts: please ignore noauto sysfs entries in fstab
* Roger Leigh [2012-04-24 16:31 +0100]: On Tue, Apr 24, 2012 at 02:55:55PM +0200, Michael Prokop wrote: * Carsten Hey [Mon Apr 23, 2012 at 01:07:17 +0200]: Please ignore noauto sysfs entries in fstab. Not mounting sysfs to /sys if such a line is present in fstab leads to udev not starting. If this bug is not fixed, this problems will show up after upgrading to Wheezy on some systems. [...] FTR: According to my tests, bootstrapping wheezy with grml-debootstrap 0.49 fails WRT /sys mounting and bootstrapping whezzy with grml-debootstrap 0.50 (just released and uploaded, it does not add a noauto sysfs line any longer) succeeds. So does this problem still need addressing in initscripts? The problem is that installing Squeeze via grml-debootstrap perfectly works and after upgrading to Wheezy udev will not start. A wrongly generated /etc/fstab can't be fixed for existing systems by releasing a fixed version of a tool that is only run once during installation. We could certainly make it skip the noauto check for critical mountpoints like /proc and /sys. I would prefer this. An alternative to this would be commenting out such lines in initscripts preinst, but as I already wrote, I would prefer your suggestion to skip the noauto check for critical mountpoints like /proc and /sys. OTOH, if you explicitly asked for that behaviour... we are only respecting the wishes of the admin. initscripts is currently respecting what you obviously *think* are the wishes of the admin. Since /sys is nowadays mounted on most or all major Linux distributions regardless of a possibly existing according fstab entry and admins might know this, the wish of an admin who adds such a noauto entry could also be let me mount sysfs by only typing 'mount /sys' if I need to do a chroot, which I consider to be way more likely than don't mount /sys at all. If some people would like mounting /sys to be skipped, you should have received an according bug report in all those years when this was not possible, i.e., before the according change in initscripts that happend during Wheezy's release cycle. An argument to also expect such a noauto sysfs entry on systems not installed via grml-debootstrap is (besides those webforum entries Google finds) that the paper The sysfs Filesystem [1] published at the Linux Symposium 2005 in Ottawa includes an fstab example entry for sysfs that contains the option noauto. I'm not sure if this entry was copied from a distribution or if the paper is the first occurrence of such a line. Anyway, one could expect that using a sysfs paper published by a Linux kernel developer on a major Linux conference as reference for a simple sysfs fstab entry would be a good choice. [1] www.kernel.org/pub/linux/kernel/people/mochel/doc/papers/ols-2005/mochel.pdf In my opinion, the underlying problem is that there is no clear and distribution independent semantic of noauto when used in a fstab entry for those standard virtual file systems. If there would be such a clear semantic, then either initscripts in Squeeze or the one in Wheezy would be buggy as one of them wouldn't respect this clear semantic. Regards Carsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670074: grml-debootstrap: please remove the noauto sysfs entry from generated/copied fstab
Package: grml-debootstrap Please remove the noauto sysfs entry from generated/copied fstab. Gregor Thill noted that initscripts/Wheezy does not mount /sys if there is an according fstab entry with the option noauto, which leads to udev not starting. He verified this by removing this fstab line and booting again. Other fstab entries might benefit from reconsidering them too. Regards Carsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670106: initscripts: please ignore noauto sysfs entries in fstab
Package: initscripts Bug summary: Please ignore noauto sysfs entries in fstab. Not mounting sysfs to /sys if such a line is present in fstab leads to udev not starting. If this bug is not fixed, this problems will show up after upgrading to Wheezy on some systems. Bug details: Gregor Thill noted: | When bootstrapping Wheezy, the (grml-debootstrap) script creates an | fstab including a line for sysfs with the mount option noauto. During | boot of the resulting Debian system, sysfs won't be mounted and as | udev depends on it, udev does not run. Removing the line or the noauto | option fixes this behaviour. Only changing grml-debootstrap to not to create this line, as already reported in Debian bug #670074, won't solve this problem for all those pre-Wheezy systems created using buggy grml-debootstrap versions. The problem will be noticed after an upgrade to Wheezy since initscripts/Squeeze (or less likely, anything else installed by default on Squeeze) mounts sysfs despite a noauto sysfs fstab entry. The line added to /etc/fstab is: /sys /sys sysfs noauto,rw,nosuid,nodev,noexec 0 0 I don't think such an entry will only occur on systems installed using grml-debootstrap, and I think initscripts should be adapted to ignore a noauto fstab entry for /sys, even if you might consider such and line to be buggy. The initscript responsible for mounting sysfs to /sys seems to be /etc/init.d/mountkernfs.sh, which uses a function in /lib/init/mount-functions.sh to do so. Regards Carsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#645190: Bug#645191: update on waf binary data
* Yves-Alexis Perez [2012-04-15 09:18 +0200]:
On ven., 2012-03-23 at 23:39 +0100, Carsten Hey wrote:
I think we should drop ftpmaster from CC in further mails.
Maybe, since they don't seem to care about this.
They provided an IMHO acceptable, but not ideal, way (because there
there does not seem to be an ideal way) to handle this. I suggested
dropping them from CC because there is nothing relevant yet they could
comment on, which presumably is also the reason they did not comment up
to now ;)
Well, parsing python might not be an option, but what about:
egrep -a ^C[1|2]='..' waf
C1='#*'
C2='#%'
We need to be able to repack a changed wafadmin directory into an
existing waf script to gain anything. To repack, C1 and C2 need to be
adapted. If adapting C1 and C2 is done via regular expressions, it
would fail, possibly without being noticed, if, for example, the
variable names in future waf versions change or if the character ' is
part of this variable and you did not handle this in your regular
expression. All in all, this is a rather natural approach for this
problem, but it is all but robust.
It could be done using regular expressions, but I assume that the effort
required to ensure that it works correctly and to update it is way more
than the effort to just shipping an unpacked waf in every waf using
package. Besides this, the probability of unnoticed related errors is
presumably unreasonably high.
A way to handle this that would possibly make everybody happy would
require to convince waf upstream to adapt waf.
As already mentioned, the reason that we are not able to repack waf
scripts in a reasonable way using only essential tools is that waf
scripts are not clearly divided into a data part and an non-data part,
i.e., C1 and C2 contain information that one would expect to be in
a header and not in a script.
If waf script's would instead of the variables C1 and C2 contain
a header like the one below, and would parse the header itself to figure
out which replacements it should do, then tools that unpack and/or
repack waf scripts in a reliable way could easily be written.
#===
# Waf-Data-Format: 1.0
# Waf-Archive-Type: tar.gz
# Waf-Archive-Base-Directory: wafadmin
# Waf-Line-Feed-Replacement: ab
# Waf-Carriage-Return-Replacement: xy
#==
#...
#==
If such a header would be used by waf upstream, it would be important
that there is exactly one space between the colon after the field name
and the field's data. The reason for this is that a replacement string
could begin with a space character. Introducing a way to escape some
characters would IMO be too over-engineered. Alternatively, the
(uppercased) hex values could be used instead of the real string, i.e.,
' m' would be written as 206D in the header.
Reasons to brute-force unused sequences instead of simply prefixing all
line feeds and all carriage returns with a numbersign are:
* Kepp the size of the encoded string as small as possible. Prefixing
two of the possible 256 characters would enlarge the encoded string
on average by 2/256 or 0.78%, given that the compression method is
reasonable.
* Some editors do not wrap lines by default. One could consider
displaying just one long unwrapped line instead of multiple lines (on
average size/128 lines) if a waf script is opened in an editor to be
more beautiful.
* The data part ends before a line that only contains the string
'#=='. If you would encode an archive of infinite size by the
described prefixing, it would also contain this line _in_ the data
part. A way to fix this it to additionally prefix the equal sign
with a number sign. A presumably better way it to interpret the
semantic of '#==' as the data part ends before the _last_ equal
line in a comment block and not ... before the _first_ equal line
Perl one-liner filters to encode and decode the data part using the
described prefixing are:
perl -e '$_ = do { local $/ = }; s/\n/\n#/sg; s/\r/\r#/sg; print #,
$_, \n'
perl -e '$_ = do { local $/ = }; $_ = substr($_, 1, -1); s/\r#/\r/sg;
s/\n#/\n/sg; print'
They can be used in the same way as all other filters:
cat file | filter result
With this approach, the need for C1 and C2 (or the according header
fields) would vanish. The header would still be very useful, though.
The remaining non-trivial part, which I will not do since I think the
existing solution (shipping waf unpacked) is ugly but sufficient and
I don't even use waf, is to try to convince waf's upstream to add such
a header. With such a header and the according scripts, changes between
different Debian revisions would still not be reviewable as easy as
running zrun interdiff *.diff.gz, but I don't think that this is
a blocker, as long as README.source contains easy recipes for changing
waf and reviewing these changes.
Well, when needed because we need to patch the build script (like for
the hppa issue) we can do that.
Being
Bug#654468: Bug#645191: update on waf binary data
* Carsten Hey [2012-04-15 20:32 +0200]: #=== # Waf-Data-Format: 1.0 # Waf-Version: 1.8 # Waf-Archive-Type: tar.gz # Waf-Archive-Base-Directory: wafadmin # Waf-Line-Feed-Replacement: ab # Waf-Carriage-Return-Replacement: xy #== #... #== -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#667960: [PATCH] combine: let xor read a file only once. This is required to correctly work when reading from pipes. Closes: #667960
* Carsten Hey [2012-04-10 02:00 +0200]: ... attached C implementation ... likely to contain bugs. One is that specifying - to read from stdin instead of a named file is not implemented. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#667960: [PATCH] combine: let xor read a file only once. This is required to correctly work when reading from pipes. Closes: #667960
* Joey Hess [2012-04-07 14:57 -0400]:
Carsten Hey wrote:
+sub read_file_and_hashify {
+ my $file = shift;
+
+ my ($a_ref, $h_ref) = ([], {});
+ filemap $file, sub {
+ push @$a_ref, $_;
+ $h_ref-{$_} = 1;
+ };
+ return ($a_ref, $h_ref);
+}
This could be written using filemap.
It uses filemap, maybe I used an unfortunate indentation.
sub compare_or {
my ($file1, $file2) = @_;
@@ -105,8 +116,11 @@ sub compare_or {
sub compare_xor {
my ($file1, $file2) = @_;
- compare_not($file1, $file2);
- compare_not($file2, $file1);
+ my ($a1, $h1) = read_file_and_hashify $file1;
+ my ($a2, $h2) = read_file_and_hashify $file2;
+
+ foreach (@$a1) { print $_, \n unless exists $h2-{$_} }
+ foreach (@$a2) { print $_, \n unless exists $h1-{$_} }
This uses something like 4x the memory that it used before. It would be
easy to use only 3x[1]. With a good data structure, it should be
possible to only use 2x. Using an ordered hash would be one way. I have
no experience with Tie::IxHash, but it looks promising.
This 3x memory usage implementation is not the one you suggested.
I think your's should use less memory, but the difference should be
small (this is just for reference, and there is no need to read this
code).
| sub compare_xor {
| my ($file1, $file2) = @_;
|
| my ($lines2, $seen1, $seen2) = ([], {}, {});
| filemap $file2,
| sub {
| push @$lines2, $_;
| $seen2-{$_} = 1;
| };
| filemap $file1,
| sub {
| print $_\n unless exists $seen2-{$_};
| $seen1-{$_} = 1;
| };
| foreach (@$lines2) {
| print $_\n unless $seen1-{$_};
| }
| }
The above can easily be adapted to use only two times of the original
memory, even without an ordered hash:
| sub compare_xor {
| my ($file1, $file2) = @_;
|
| my ($lines2, $seen2) = ([], {});
| filemap $file2,
| sub {
| # Add all lines in file2 to @$lines2 and to %seen2
| # with value 1.
| push @$lines2, $_;
| $seen2-{$_} = 1;
| };
| # Note the usage of 'if' and 'if exists' and their semantic
| # difference when reading the remaining code of this sub.
| filemap $file1,
| sub {
| # Print all lines in file1 that are not in file2,
| # and mark lines that are in both files by setting
| # their value in %seen2 to 0.
| if (exists $seen2-{$_}) {
| $seen2-{$_} = 0;
| }
| else {
| print $_\n;
| }
| };
| foreach (@$lines2) {
| # Print all lines that are in file2 but not in file1.
| # The value of these lines in seen2 is set to 1.
| print $_\n if $seen2-{$_};
| }
| }
With an ordered hash, it should be possible to further reduce the memory
usage of the above.
Measuring the memory usage with GNU time results in (combine is the one
currently shipped in moreutils, ./combine{2..4} are the variants with
two to four times of memory usage):
Command being timed: ./combine4 /tmp/unsorted_1 xor /tmp/unsorted_2
Maximum resident set size (kbytes): 90800
Command being timed: ./combine3 /tmp/unsorted_1 xor /tmp/unsorted_2
Maximum resident set size (kbytes): 73920
Command being timed: ./combine2 /tmp/unsorted_1 xor /tmp/unsorted_2
Maximum resident set size (kbytes): 51744
Command being timed: combine /tmp/unsorted_1 xor /tmp/unsorted_2
Maximum resident set size (kbytes): 36576
I'll send an update after being able to measure the memory usage of
a simple implementation in C.
Regards
Carsten
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#667960: [PATCH] combine: let xor read a file only once. This is required to correctly work when reading from pipes. Closes: #667960
I noticed that moreutils includes isutf8. The same, but with
a different interface, can be archived with iconv -f UTF8 /dev/null
filename.
Currently combine file1 and file2 _ is valid syntax, as is _ file1
and file2. If you ever plan to add options, I think this must change
in some way, at least if an option is passed. Otherwise combine can't
know if _ -z or xor _ should process the files -z and xor, or the
files or and _.
Useful options are in my opinion -u (unique - if one pipes combine's
output through sort -u anyway one could also use comm instead), -z (zero
terminated entries) and -n (to print the line number instead of the
lines itself - this would solve all those please reimplement join
feature requests, but an exhaustive explanation would be too long for
now). An argument against adding -u is that the perl one-liner perl -ne
'print unless $seen{$_}++' archives the same.
* Joey Hess [2012-04-09 16:14 -0400]:
Carsten Hey wrote:
I'll send an update after being able to measure the memory usage of
a simple implementation in C.
I'd rather avoid dealing with custom hash tables in C.
All testing that has been done for the attached C implementation is
comparing the output of all for operations on the two test files
I created with the output of the combine shipped in moreutils, so it is
likely to contain bugs. For now I agree that the perl variant from my
former mail is the best option mentioned in this bug.
It reads the files into an array of C-strings. The hash table is
built by qsort()ing it and the lookup is done by using bsearch(). If
both, the lines in the original order and the sorted lines are needed,
the array with pointers to char needs to be copied and sorted, which is
quite cheap.
Without a more complex data structure, xor needs to read both files into
memory. All that is needed for such more complex data structures (which
are also needed for implementing some possible options and for
supporting embedded '\0' characters) is to additionally store some
integers for each entry, for example to store the entries length or to
mark an entry as seen.
With the same arguments I used to measure the memory usage of the
different perl variants it uses 22832 kbytes of memory, despite reading
both files into memory. The perl implementations needed at least 36576
kbytes.
Regards
Carsten
/*
Copyright (C) 2006 Joey Hess j...@kitenet.net
Copyright (C) 2012 Carsten Hey cars...@debian.org
This software is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty
of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see http://www.gnu.org/licenses/,
or, on Debian systems, the file '/usr/share/common-licenses/GPL-2'.
*/
#ifndef _XOPEN_SOURCE
#define _XOPEN_SOURCE 700
#endif
#ifndef _BSD_SOURCE
#define _BSD_SOURCE 1
#endif
#include err.h
#include errno.h
#include stdlib.h
#include stdio.h
#include string.h
#include wchar.h
static void *
xmalloc_error(void)
{
(void)fflush(stdout);
errx(EXIT_FAILURE, Memory allocation failed);
}
static void *
xmalloc(size_t sz)
{
void *rv = malloc(sz);
if (!rv)
xmalloc_error();
return rv;
}
static void *
xrealloc(void *ptr, size_t sz)
{
void *rv = realloc(ptr, sz);
if (!rv)
xmalloc_error();
return rv;
}
static void *
xmemdup(void *s, size_t n)
{
/* Add a trailing '\0' as long as support for embedded '\0'
* characters is not complete. */
void *rv = malloc(n + 1);
if (!rv)
xmalloc_error();
((char *)rv)[n] = '\0';
return memcpy(rv, s, n);
}
static FILE *
xfopen(const char *filename, const char *mode)
{
FILE *rv;
errno = 0;
rv = fopen(filename, mode);
if (!rv) {
int bak = errno;
(void)fflush(stdout);
errno = bak;
err(EXIT_FAILURE, filename);
}
return rv;
}
/* Write from stream 'in' to stream 'out' until EOF is reached and add
* a trailing delim character if appropriate. Return 0 on success.
*/
static int
file_paste(FILE *in, FILE *out, const char delim)
{
int c,
last = (int)~delim,
rv = -1;
(void)fwide(in, -1);
(void)fwide(out, -1);
flockfile(in);
flockfile(out);
while ((c = getc_unlocked(in)) != EOF)
if ((last = fputc_unlocked(c, out)) == EOF)
goto DONE;
if (last != (int)delim)
if (fputc_unlocked(delim, out) == EOF)
goto DONE;
if (ferror_unlocked(in))
goto DONE;
rv = 0;
DONE:
funlockfile(out);
funlockfile(in);
return rv;
}
static char **
file_to_array(const char *filename, size_t *n, const char delim)
{
#define ARRAY_APPEND(type, ptr, current_size, malloced_size, val) \
do
Bug#667960: moreutils: combine's xor does not handle named pipes correctly
Package: moreutils combine's xor does not handle named pipes correctly. The same bug is triggered if a file is read from stdin. I'll send a possible fix after knowing the bug number. Used zsh syntax in a nutshell: (cmd) creates a named pipe with cmd's output as content =(cmd) creates a real file with cmd's output as content These commands were run on Debian stable, but combine in stable and sid is the same (except for the used Perl version): $ : this is correct: $ combine =(seq 1 2) xor =(seq 2 3) 1 3 $ : these are equivalent, and both wrong: $ combine (seq 1 2) xor =(seq 2 3) 1 2 3 $ seq 1 2 | combine - xor =(seq 2 3) 1 2 3 $ : also wrong: $ combine =(seq 1 2) xor (seq 2 3) 1 $ combine (seq 1 2) xor (seq 2 3) 1 The reason for this is that compare_xor($$) runs compare_not($$) twice and compare_not($$) reads the content of both filenames passed as arguments to it. The first time a pipe is read, the contents of the file is returned and reading stops when EOF is read. The second time EOF is read, EOF is returned immediately, thus the file is assumed to be empty by compare_not($$). For example, if you run combine (seq 1 2) xor =(seq 2 3), combine should do the same as: combine =(seq 1 2) not =(seq 2 3) -- prints 1 combine =(seq 2 3) not =(seq 1 2) -- prints 3 but it does: combine =(seq 1 2) not =(seq 2 3) -- prints 1 combine =(seq 2 3) not =(:)-- prints 2 and 3 JFYI: The next Ubuntu LTS is going to be released soonish and they won't merge packages from Debian anymore unless they are asked to do so. Regards Carsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#667960: [PATCH] combine: let xor read a file only once. This is required to correctly work when reading from pipes. Closes: #667960
---
combine | 18 --
1 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/combine b/combine
index a695935..c139cf7 100755
--- a/combine
+++ b/combine
@@ -95,6 +95,17 @@ sub hashify {
return \%seen;
}
+sub read_file_and_hashify {
+ my $file = shift;
+
+ my ($a_ref, $h_ref) = ([], {});
+ filemap $file, sub {
+ push @$a_ref, $_;
+ $h_ref-{$_} = 1;
+ };
+ return ($a_ref, $h_ref);
+}
+
sub compare_or {
my ($file1, $file2) = @_;
@@ -105,8 +116,11 @@ sub compare_or {
sub compare_xor {
my ($file1, $file2) = @_;
- compare_not($file1, $file2);
- compare_not($file2, $file1);
+ my ($a1, $h1) = read_file_and_hashify $file1;
+ my ($a2, $h2) = read_file_and_hashify $file2;
+
+ foreach (@$a1) { print $_, \n unless exists $h2-{$_} }
+ foreach (@$a2) { print $_, \n unless exists $h1-{$_} }
}
sub compare_not {
--
1.7.2.5
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#645190: Bug#645191: update on waf binary data
I think we should drop ftpmaster from CC in further mails. * Yves-Alexis Perez [2012-03-17 09:36 +0100]: On sam., 2012-03-17 at 02:45 +0100, Carsten Hey wrote: waf scripts are not cleanly divided into python and data, but instead the python part contains also two two byte sequences (found using brute force whilst building the waf script). My original plan was to ship two scripts debian/waf-unpack and debian/waf-repack to provide an easy way to edit the waf sources and document this in README.source. Due to the above mentioned mix of header information and python source code this can not be done in a clean way, so there so there is nothing to review for ftpmaster. I don't completely understand this. What are those two bytes sequences you bruteforced? Afaict you don't call waf in your snippets (and I specifically asked you about that). The bug report mentioned that the waf script contains an embedded .tar.bz2. A short look at the script revealed that there is only one line where it could be embedded and that it replaces a two byte sequence with \n and an other one with \r. Finding out that the line's first character and the line's last do not belong to the .tar.bz2 wasn't that hard. All described can be done easily using sed and similar tools - and the reverse can also easily be done using sed and similar tools. This is what I did, I put the described in simple commands. The idea was to be able to extract the data from the waf script, modify it and then embed it again into the waf script - just using simple standard tools. The above was based on the assumption that these two two byte sequences are always the same because they can not occur in bzip2 compressed data for whatever reason. This assumption was wrong, waf creates the .tar.bz2 and then tries all possible two byte sequences until if finds some that do not occur in the .tar.bz2 and then sets the variables C1 and C2 in the python waf template to these values. If we would do this in sed and co. we would need to parse python, which doesn't seem to be an option. http://bugs.debian.org/660193 (search for the string waf) contains snippets, based on what Tolimar pointed to in his mail, you just need to paste into the midori package and some additional notes. The remaining part is IMHO to document this in README.source. One thing I forgot to mention in my mail to #660193 is that the reason to remove the blob from the used waf script is to ensure that the unpacked waf source is used. Well, in midori diff, I repack and ensure the new one and the old ones are the same to be sure I don't do anything bad. Now indeed it could be split in two parts, one run by maintainer, which would then hack in the waf sources themeselves, and one at build time, which would pick the extracted sources and make a new waf script. My point of all this was to provide an easy way to change the source code, but this can't be accomplished. You provided a way to extract the source to be able to review it, but not to change it. And changing the way waf is used at built time is not supported and might fail in bad ways too, so it's not really helpful to do things *against* what advised by waf upstream. Users might not be advised to use an extracted source, but #devs use $WAFDIR (this is a comment in the waf script shipped in midori), so using the extracted wafadmin directory isn't unsupported at all. $WAFDIR is the directory in which the extracted wafadmin directory is found. And I still consider the decision bad because the source *is* there and is tunable, even though it's not the easiest way in the world. But upstream(s) made a choice here, we can disagree (and I do) but at the end of the day, unless you want to fork, there's not much you can do. Use an trivial build system for trivial projects and ship waf unpacked for non-trivial packages is what we can do (midori is clearly non-trivial). Having an easy command to unpack and repack waf scripts would have been great, but this is not possible unless we would adapt the values of C1 and C2 in the waf script (and thus parsing python), which would lead to an ugly hack. Regards Carsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#654468: Bug#645191: update on waf binary data
* Carsten Hey [2012-03-23 23:39 +0100]: Having an easy command to unpack and repack waf scripts would have been great, but this is not possible unless we would adapt the values of C1 and C2 in the waf script (and thus parsing python), which would lead to an ugly hack. Alternatively, a template could be used to avoid parsing the waf script, but this would require way more work to maintain than just shipping the unpacked wafadmin directory. Carsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#660193: developers-reference: please suggest debian/rules target name for preparing source
* Russ Allbery [2012-03-16 19:05 -0700]: Charles Plessy ple...@debian.org writes: Le Fri, Feb 17, 2012 at 02:46:15PM +0100, Carsten Hey a écrit : In general, debian/README.source does not contain information how to run, for example, autoconf and friends to convert a clean VCS checkout into a source tree that can be built using dpkg-buildpackage (there are packages that require this). perhaps the Policy could be modified to allow such information in debian/README.source ? There is an open bug on this subject. http://bugs.debian.org/495233 I've always been a little surprised that people think that Policy doesn't allow such information in README.source ... This section is structured like this: if $condition README.source should explain: * enumeration about what should be explained remark regarding above explanation an other remark regarding above explanation mention possible additional content After scanning the first two paragraphs below of the enumeration for useful information, people might skip reading the last paragraph because they do expect it to only contain further information regarding the enumeration above. The section's last paragraph can be displayed in a browser in a way that easily could be mixed up with a page's footer out of the corner of one's eyes. There are two reasons for this (one of them alone wouldn't have this effect), one is that the sections last paragraph is also the last of this chapter (and thus on the displayed web page) and the other one is that, depending on the used browser font and window size, there can be two lines, both starting with the same long and partly uppercased string, resulting in a structure typically found in footers or copyright notices, but hardly in body text. A possible fix for both is to move the last paragraph up, so that the section starts with this paragraph (which would require minor wording changes). Carsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#660193: developers-reference: please suggest debian/rules target name for preparing source
* Henrique de Moraes Holschuh [2012-02-18 10:11 -0200]: On Fri, 17 Feb 2012, Carsten Hey wrote: The intention of this bug report is to unify the name of a target that might be used more often soon, and it is not sufficient to reach this goal if we rely on package maintainers to document the target they use in debian/README.source. I have nothing against separating the clean target into a prebuild target (that will have to run when the clean target is invoked for the first time at the very least). But I do wonder how useful this separate prebuild target would really be? You still need to run the clean target anyway to do anything useful... I think I made my point in this bug report not clear enough, but I found an other example [1] where this target could be used. I hope this makes the bug report more clear. Using the build tool waf in the way intended by it's upstream in a Debian package contradicts Debian's goal of being able to adapt source packages easily. Although not recommended, shipping the unpacked waf sources in a Debian source package is one possible way to handle this. The steps to unpack the waf sources can be put into a new debian/rules target that is only run on the maintainers system before running dpkg-buildpackage, either after doing a VCS checkout or whilst packaging a new upstream version: 73a74,85 override_dh_clean: find wafadmin -name *.pyc -delete dh_clean prebuild: test ! -d wafadmin ./waf --help /dev/null mv .waf-*/wafadmin . rm -f .waf-*/t.bz2 rmdir .waf-* sed -n -i -e '1,/^#==$$/ p' -e '/^#==$$/,$$ p' waf The target name in the normal diff above is 'prebuild', it could also have been 'extract-waf'. All this bug report is about is that in such cases maintainers should consider using prebuild as the target's name instead of inventing new ones. Footnote [2] contains additional notes only relevant if one wants to extract a waf file. Regards Carsten [1] additional to reducing build dependencies in essential packages and avoiding differences on different architectures on multiarch same packages [2] - This example requires some changes in debian/source/*, e.g.: debian/source/format:3.0 (quilt) debian/source/include-binaries:waf debian/source/options:auto-commit - Putting the extracted waf source into an additional upstream tarball instead of a diff might be an alternative to consider, this could be automated too. - New upstream versions might require adapting the filenames in debian/rules' targets override_dh_clean and prebuild. - I'm not sure if ftpmaster would be happy with the blob in the waf script if it is still would be shipped in the .orig.tar.gz, but IMHO providing a short shell or perl script to convert this blob to a tarball without relying on waf extracting itself should be sufficient to make them happy. - I would not consider the according waf bug to be fixed unless it documented in README.source in a proper way. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#645190: Bug#645191: update on waf binary data
waf scripts are not cleanly divided into python and data, but instead the python part contains also two two byte sequences (found using brute force whilst building the waf script). My original plan was to ship two scripts debian/waf-unpack and debian/waf-repack to provide an easy way to edit the waf sources and document this in README.source. Due to the above mentioned mix of header information and python source code this can not be done in a clean way, so there so there is nothing to review for ftpmaster. http://bugs.debian.org/660193 (search for the string waf) contains snippets, based on what Tolimar pointed to in his mail, you just need to paste into the midori package and some additional notes. The remaining part is IMHO to document this in README.source. One thing I forgot to mention in my mail to #660193 is that the reason to remove the blob from the used waf script is to ensure that the unpacked waf source is used. If requested I could provide a less hackish script to extract the tarball embedded in a waf script. It is finished, but it is probably useless because there is no reliable way to put a new tarball into a waf script without using ugly hacks or being waf itself. * Yves-Alexis Perez [2012-03-15 21:26 +0100]: To be honest, I didn't even wanted to spend any time on this, as I consider the decision bad. If a security update would require any changes in the packages build system, using waf the way upstream intended it to be used would cause the security team a lot of work and reviewing even simple changes related to the build system would be a mess to review by the release team during freeze. Some .jar files also contain their source, should we in your opinion start to just ship them instead of rebuilding them? (this was of course a rhetorical question) Regards Carsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#654468: Bug#645191: update on waf binary data
* Yves-Alexis Perez [2012-03-15 11:11 +0100]: On sam., 2012-03-10 at 20:24 +0100, Yves-Alexis Perez wrote: On sam., 2012-03-10 at 19:12 +0100, Carsten Hey wrote: * Carsten Hey [2012-03-10 18:43 +0100]: Actually I was not using a waf command but instead well known tools installed on every Debian system to extract the source code from a waf script and then to regenerate this waf script from the source (that could have been edited in the preferred form of modification in the meantime). tar xf and tar cf were missing though, but we all know how tar works. Yeah, good point. ftpmasters, any comment on this? (see few previous mail in any of the CC: bugs). Would something like that do: http://anonscm.debian.org/gitweb/?p=collab-maint/midori.git;a=commitdiff;h=23b89cca6b96266eea166b30ac8d1591ffbf7b2f I don't assume this diff would make ftpmaster entirely happy. I'll send a NMU diff against midori/sid that adapts the package in a way I hope to be acceptable by ftpmaster, but I'm not sure if I get to do this this evening. I hope to get a comment from ftpmaster after sending the NMU diff. Regards Carsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
