Bug#536459: zsh: Ctrl-ARROW gives ';5A' escape sequence instead of moving by word

[Kernc]

The way it's solved for readline-dependent shells in Debian is by providing
several relevant bindings in /etc/inputrc:

# mappings for Ctrl-left-arrow and Ctrl-right-arrow for word moving
"\e[1;5C": forward-word
"\e[1;5D": backward-word
"\e[5C": forward-word
"\e[5D": backward-word
"\e\e[C": forward-word
"\e\e[D": backward-word

$if term=rxvt
"\e[8~": end-of-line
"\eOc": forward-word
"\eOd": backward-word
$endif


Something like this should cover it portably enough?

Bug#736388: universalindentgui: missing .desktop file

[Kernc]

Package: universalindentgui
Version: 1.2.0-1
Severity: normal

universalindentgui, a GUI application, is missing a desktop launcher in
/usr/share/applications that would make it available in FreeDesktop menus.

Please find exemplary minimal desktop file attached.

Thanks. :-)


universalindentgui.desktop
Description: application/desktop

Bug#586502:

[Kernc]

> > It appears that adding a snippet of Xorg.conf in
/usr/share/X11/xorg.conf.d/
> > (e.g. 99-nvidia-glx.conf) makes X aware of this other driver.
>
> Unfortunately this breaks the X configuration if nvidia-glx is installed
> but no hardware/kernel module is available.

I'm sure you will consider this idea out of whack, but what if there was a
simple init.d script that checked if nvidia driver as well as the hardware
are all present, and if so, created the appropriate, namespaced xorg.conf
file. Alternatively, it would remove it.

Something roughly like:

xorgconf="/etc/X11/xorg.conf.d/10-nvidia-glx-nvidia-driver.conf"
if ! nvidia_conditions_met; then rm $xorgconf; exit 0; fi 2>/dev/null
mkdir -p /etc/X11/xorg.conf.d
echo -e "# This file is deleted if CONDITIONS.
# Don't rely on it, don't modify. Create new one, warning, yadda yadda.
Section \"Device\"
Identifier \"My GPU\"
Driver \"nvidia\"
EndSection

# Other convenient, gracefully-fallbacking config (like TwinView etc.)!
" > $xorgconf

And this init.d script conveniently provided by this (or a more
appropriate) package, with debconf option to disable it.

?

Bug#698528: debian-installer: BusyBox's wget doesn't preseed from HTTPS

[Kernc]

Package: debian-installer
Version: 20121114
Severity: normal

Dear Maintainer,

When running automatic installation with preseed file, the installer
fails to download the preseed config file if provided from a HTTPS
location, e.g.
preseed/url=https://raw.github.com/kernc/linux-home/master/debfix-preseed.cfg

The limitation is that of BusyBox's wget, which doesn't handle
HTTPS.

Since original wget is part of base install and thus inherently
present on the medium, can't it somehow be used instead of the
BusyBox version?


-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#698727: debian-installer: /dev/sdb1 (USB stick) added to /etc/fstab with default options (user), preventing future NTFS auto-mounts

[Kernc]

Package: debian-installer
Version: 20121114
Severity: normal

Dear Maintainers,

While installing Wheezy b4 from USB drive, debian-installer (I think)
adds a line to /etc/fstab:

/dev/sdb1   /media/usb0   auto   rw,user,noauto   0   0

The existence of this line, specifically the 'user' option (I think),
prevents mounting of NTFS filesystems by ntfs-3g, which results
in a standard ntfs-3g error:
"""Error mounting: mount exited with exit code 1: helper failed with:
Unprivileged user can not mount NTFS block devices using the
external FUSE library. Either mount the volume as root, or rebuild
NTFS-3G with integrated FUSE support and make it setuid root.
Please see more information at
http://tuxera.com/community/ntfs-3g-faq/#unprivileged""";

Reported are other USB mounting issues as well:
https://www.google.com/search?q=(debian+OR+ubuntu)+mount+usb0+(ntfs+OR+"")+/etc/fstab

The fix is to comment-out or delete the fstab line and let the
automounting be done by udev, which is part of base install anyway.

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#685215: Apt pinning is broken

[Kernc]

Package: apt
Version: 0.9.7.4
Severity: important
Tags: confirmed

I took liberty to mark this as confirmed, as it very well is and will as
such hopefully jump at the willing contributors from the top of the
outstanding bugs list. Maintainers' sympathy kindly appreciated.

I know this is kind of TL;DR, but I don't have a blog, and this is a valid
issue report with accompanying observations and proposals. Please bear
with me...


Facing it now: apt pinning, other than general pinning on release
(i.e. "Package: * \n Pin: release..."), is **broken.**

Per-package pinning doesn't work intuitively (countless forum posts around,
several bug reports below), version pinning suffers serious bugs (doesn't
work, doesn't glob() properly [4])...

This important bug spans 9 years (since 2003), several directly-related bug
reports:

 [1] http://bugs.debian.org/254820 ,
 [2] http://bugs.debian.org/387218 ,
 [3] http://bugs.debian.org/443565 ,
 [4] http://bugs.debian.org/454080 ,
 [5] http://bugs.debian.org/554773 ,
 [6] http://bugs.debian.org/620249 ,

several directly-related bug reports that were nonchalantly demoted to
wishlist-items (?!) by Matt Zimmerman:

 [7] http://bugs.debian.org/216688 ,
 [8] http://bugs.debian.org/239247 ,
 [9] http://bugs.debian.org/242738 ,
[10] http://bugs.debian.org/276602 ,
[11] http://bugs.debian.org/483147 ,
[12] http://bugs.debian.org/312589 ,

and many "apt-cache policy", general pinning and its documentation related
bugs:

[13] http://bugs.debian.org/166032 ,
[14] http://bugs.debian.org/308445 ,
[15] http://bugs.debian.org/301464 ,
[16] http://bugs.debian.org/405262 ,
[17] http://bugs.debian.org/557637 ,
[18] http://bugs.debian.org/602094 ,
[19] http://bugs.debian.org/623706 ,
[20] http://bugs.debian.org/673760 . (...)



All these (and possibly other, merged) bug reports, and countless forum
posts [21] desperately say one thing:

  ** Fix `apt-pkg/policy.cc` and rewrite documentation pertaining it! **

Let's do it once and for all?


I don't know who first 'invented' pinning as implemented now, but she
most certainly did it wrong, mainly by making it counter-intuitive.
The argument that "just RTFM, the specification is such and is correct," in
spite of being unable to satisfy a most common use case —that is, simple
package pinning— is a non-argument!


The problem lies in assigning priorities. The per-package/version priorities
aren't even priorities in the general sense, but rather some kind of minimum
priority required, as detailed in Carlo Wood's comprehensive pinning
documentation & errata [22], the author of which reported [2]. This
limitation is a serious usability issue.

Furthermore, one cannot even use an external EDSP/CUDF dependency solver and
expect coherent results, with APT::Solver::Strict-Pinning set to "false" or
otherwise, since package (or version) pins aren't even properly propagated
into EDSP/CUDF dumps, that because policy.cc simply doesn't account for
those pins correctly.

I kindly ask you to spare the discouragement warnings in this instance:
apparently there are valid use cases for pinning ([1-12, 21])!


The problematic policy.cc code may be extremely hard to fix if one is not
well versed in C++ (which I'm not), especially with so few convenience
dependencies, but fuck me if somebody is not up to the challenge.

Whoever fixes this does not only get to enjoy a crate of virtual beer (and
eternal satisfaction by the houri, acknowledged contribution one can put
in her résumé, etc. other immaterial pleasures), but I vow to
Flattr/PayPal/Kickstarter $50 myself, and I am only a poor student.

Since this is not a release-critical bug, there's enough time for testing
until the next freeze.


[21] http://www.google.com/search?q=apt+pinning+doesn't+work
[22] http://carlo17.home.xs4all.nl/howto/debian.html#errata


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#685215: Apt pinning is broken

[Kernc]

Since I opened this new bug, I'd like to add my specific use case as well:

Naturally, I want my system stable. Perhaps some time into the release
cycle, I want my user apps updated for the sake of new features, so I pull
them from testing. Chromium and Iceweasel, perhaps with more stable
(supposedly) upstream development, I want on the bleeding edge.
Perhaps I want to stay on Gnome 2 before I move to Xfce for good.
Thus, I end with the following apt preferences:

-- /etc/apt/preferences --

Explanation: I want the base of my system stable.
Package: *
Pin: release a=stable
Pin-Priority: 503

Package: *
Pin: release a=testing
Pin-Priority: 502

Package: *
Pin: release a=unstable
Pin-Priority: 501

Explanation: In some apps, I prefer features over stability.
Package: gimp libreoffice pidgin vlc
Pin: release a=testing
Pin-Priority: 505

Explanation: Other apps may be stable by design. Or I don't really care. D:
Package: chromium iceweasel
Pin: release a=unstable
Pin-Priority: 505

Explanation: But under no condition ever install default gnome (3) package.
Package: gnome
Pin: version 3*
Pin-Priority: -1

-- end /etc/apt/preferences --

But hey!, you say, that gimp and pidgin pull a hell of a long dependency
chain from testing as well...

True. But my kernel, my init scripts, daemons, desktop, ... likely all
remain stable.

With above preferences, with all that software initially installed, running
apt-get upgrade, I should end with gimp, libreoffice, pidgin, and vlc from
testing, unstable chromium and iceweasel, and gnome3 (likely with some of
its apps) nowhere to be seen.

Except that that doesn't work because all those package pins have dependencies
in their respective releases and those dependencies aren't pinned highly
enough as well, so, unless packages were initially installed with -t switch,
apt determines upgrade request to be unsolvable.

(BTW, I'd like to report that the external dependency solver called 'apt'
seems to pay no regard to the APT::Solver::Strict-Pinning setting.)

But that's what external dependency solvers are for! Using the above apt
configuration line, I can tell my sophisticated solver (really just a greedy
one) to get dependencies top-down: What it can satisfy from stable, from
stable; what it can't satisfy from stable but can from testing, from testing,
and the remaining from unstable, all according to the specified release pins.

Behold, awe the Debian mixed system, the truly Universal OS that is itself a
multi-level rolling release.



Argument

What you're saying above can be easily achieved with pinning as implemented
now, and a careful use of apt-get command line, namely `-t` switch or
`pkgname/release` parameter.

Counter-argument

Say package A (from testing) depends on packages B, C, D, E, F, G. The
versions of these dependencies are such that versions of B, C, D, and E
could be satisfied from stable, but F and G need to be from testing as well.
All release pins as in above preferences.
Either:
$ sudo apt-get install A/testing
fails, because F and G are pinned to stable, but those two can't satisfy the
requirement of A. Or:
$ sudo apt-get -t testing install A
works, but it pulls all those packages from testing, possibly and
unnecessarily (!) making the system less stable.
Ergo, to satisfy above "prefer stable, but adapt if needed" requirement, an
external solver (with Strict-Pinning=false) is required to operate on a
working pinning implementation.
(The alternative is to install each dependency separately, which then really
turns the process into a PITA.)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#685215: Apt pinning is broken

[Kernc]

Namely, what I, as a user, would like only is that pinning per package
(wildcarded) name or version works, and that those more specific pins are
propagated to EDSP/CUDF dumps, i.e. in the EDSP dump, the APT-Pin field for
"package=chromium,version=whatever-is-available-in-unstable" stanza says
505 (as per above /etc/apt/preferences) instead of 501 as it does now.

If I got it wrong, and the current implementation is indeed correct, I'd
very much care for having the broad ideas behind it explained to me.
(Though I doubt it as maintainers have before admitted to behavior being
kind of fuzzy.)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#685215: Apt pinning is broken

[Kernc]

I'd like to propose a new policy view.
This is the current output of "apt-cache policy" (modified from [22]):

-- apt-cache policy  --

:
  Installed: 
  Candidate: 
  Package-Pin: 
  Version table:
 ***  
 
 
  
 
 

-- end apt-cache policy package-name --

The breakdown of the three dubious fields is this:


  This field marks the version that corresponds to the first-matched more
  specific rule (e.g. with "Package: " and/or "Pin: version
  3*"). This version has the priority .
  IMHO, this field is completely redundant.


  This field is the Pin-Priority that corresponds with the first-matched
  more specific form ("Package: " and/or "Pin: version 3*").
  This field too, IMHO, is a design flaw, is redundant and should be removed.


  This field corresponds to the Pin-Priority of the whole
  release/archive/origin set with wildcard "Package: *" (called a general
  form in the manual).

I kindly challenge your views on two IMHOs above.

I propose a a new "apt-cache policy" output:

-- new apt-cache policy  --

:
  Installed: 
  Candidate: 
  [Package-Pin: general|specific]
  Version table:
 *** 
 
 
 
 
 

-- end new apt-cache policy  --

Package-Pin property is marked optional, and it only tells whether the
package is being pinned at all and whether the pin is only a general form
(release-wide) pin, or a more specific pin for that package/version is in
effect.

The breakdown of the dubious field here is:


  The cumulative all-things-considered priority of package 
  (set with specific form pin stanza), version
   (set with specific form pin stanza) from
   (set with general form pin stanza or APT::Default-Release).

Thus, a single priority is set for each triplet 
(which is supposed to be but absolutely not the case currently, and
is instead more like what cupt does). Among the highest
 the one with the highest
 wins and becomes the Candidate.

As presented in the follow-up algorithm pseudo code, this is easily achieved
if the policy regarding rules being first-match is reversed and
instead the last general rule wins and is overwritten by the last relevant
specific rule (if such exists).

Everything else regarding priorities and policy remains as currently
documented.


Backward-compatibility notice & Disclaimer
--
AFAIK, current implementation didn't allow for complicated apt_preferences
setups that could have break under this "new" policy.
I don't know how else these priorities are used internally throughout the apt
suite, and who else relies on "apt-cache policy" output being exactly as is.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#685215: Apt pinning is broken

[Kernc]

I'd like to propose an algorithm that, if I'm not mistaken, results in above
policy.

Presuppositions
---
A general form rule or stanza is one that has "Package: *" AND "Pin:
".

A specific form rule or stanza is one that has "Package: " OR
"Pin: version" where  is a space-separated list of glob() or
regular expressions.

Above is in accordance with current documentation.

Algorithm
-
Input = list of actionable packages, e.g. the space-separated list of
packages passed to apt-get install/remove/... along with all dependencies

Preferences = parse all Dir::Etc::preferences and Dir::Etc::preferencesparts,
sorting all general forms before all specific forms. Preferences must also
contain rules for APT::Default-Release or matching command-line switch.

for package in Input:
  for rule in Preferences.general_form_rules:
if contains(rule.source, package):
  set_priority(, rule.priority)

  # more specific rules may overwrite general ones
  for rule in Preferences.specific_form_rules:
if (rule.is_version_pin &&
versions_match(package, rule.version)):
  if matches(package, rule.name):
for source in get_sources_for(package,
  versions_match(package,
 rule.version)):
  set_priority(, rule.priority)
else:  # not rule.is_version_pin
  if matches(package, rule.name):
set_priority(, rule.priority)

  package.candidate = max_version(max_priority(package))


  # the rest is as currently implemented...
  if (package.candidate.version < package.installed_version &&
  package.candidate.priority < 1000):
error 'need priority over 1000 to downgrade'
  ...


I'd like to comment briefly on some of the above functions:
package_version_in(pkg, src) --- returns the version of pkg in src
versions_match(pkg, ver) --- returns pkg versions that matches ver glob if any
get_sources_for(pkg, ver) --- returns sources that contain pkg with version
in ver
matches(pkg, name) --- name can be a list of glob-like expressions

This is my take on what the algorithm roughly could look like. I agree it
looks kind of scripty, and I don't know exactly how easily this translates to
C++. Further, I'm not sure the algorithm works with all apt actions besides
simple install or upgrade. But I promise to implement an external solver
working as proposed in comment #2 if someone fixes the policy so that
EDSP/CUDF dump contains appropriate package pins.

I believe that with above-like algorithm, and some further documentation
effort, the bugs listed in OP can be finally marked as fixed, apt leading
Debian, as it always has, to an even brighter future.

But I fully admit to having little knowledge about apt inner working, Debian
packaging, Debian packaging policy, Debian release cycle, etc., I just want
to help the issue get resolved. :-)

Please contribute your views, questions, concerns, ideas...
And my $50 offer remains wide open. Please feel free to chip in.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#682024: apt-get: custom --solver stub crashes apt-get in glibc

[Kernc]

Package: apt
Version: 0.9.7.1
Severity: minor
File: /usr/bin/apt-get

Dear Maintainer,

I created an external apt-cudf solver specification as per apt-cudf
instructions.
My "solver" (as of yet, a stub) is:

-- minimal_progressive.py solver --
#!/usr/bin/env python

import sys

def main():
if len(sys.argv) != 4:
return 1
cudf_in = open(sys.argv[1])
cudf_out = open(sys.argv[2], 'w')
cudf_in.read()  # read the whole piped input
cudf_out.write('Error:')  # write something irrelevant
return 1  # return with error

if __name__ == '__main__':
sys.exit(main())

-- end minimal_progressive.py --

I run apt-get and get the following output (reproducible):

-- start output --

user@debian:~$ sudo apt-get -s upgrade --solver minimal_progressive

Reading package lists... Done
Building dependency tree
Reading state information... Done
*** glibc detected *** apt-get: malloc(): memory corruption: 0x081a4ab0 ***
=== Backtrace: =
/lib/i386-linux-gnu/i686/cmov/libc.so.6(+0x6e3f1)[0xb744c3f1]
/lib/i386-linux-gnu/i686/cmov/libc.so.6(+0x711d4)[0xb744f1d4]
/lib/i386-linux-gnu/i686/cmov/libc.so.6(__libc_malloc+0x5c)[0xb7450ddc]
/usr/lib/i386-linux-gnu/libstdc++.so.6(_Znwj+0x25)[0xb75cd555]
[0x81a84c0]
=== Memory map: 
08048000-08076000 r-xp  08:01 4901   /usr/bin/apt-get
08076000-08077000 r--p 0002d000 08:01 4901   /usr/bin/apt-get
08077000-08078000 rw-p 0002e000 08:01 4901   /usr/bin/apt-get
0819d000-081be000 rw-p  00:00 0  [heap]
b500-b5021000 rw-p  00:00 0
b5021000-b510 ---p  00:00 0
b516-b541d000 rw-p  00:00 0
b541d000-b7236000 rw-p  08:01 136112 /var/cache/apt/pkgcache.bin
b7236000-b73ad000 r--p  08:01 5068
/usr/lib/locale/locale-archive
b73ad000-b73b rw-p  00:00 0
b73b-b73bf000 r-xp  08:01 3184
/lib/i386-linux-gnu/libbz2.so.1.0.4
b73bf000-b73c rw-p f000 08:01 3184
/lib/i386-linux-gnu/libbz2.so.1.0.4
b73c-b73d7000 r-xp  08:01 3198
/lib/i386-linux-gnu/libz.so.1.2.7
b73d7000-b73d8000 r--p 00016000 08:01 3198
/lib/i386-linux-gnu/libz.so.1.2.7
b73d8000-b73d9000 rw-p 00017000 08:01 3198
/lib/i386-linux-gnu/libz.so.1.2.7
b73d9000-b73da000 rw-p  00:00 0
b73da000-b73dc000 r-xp  08:01 42
/lib/i386-linux-gnu/i686/cmov/libdl-2.13.so
b73dc000-b73dd000 r--p 1000 08:01 42
/lib/i386-linux-gnu/i686/cmov/libdl-2.13.so
b73dd000-b73de000 rw-p 2000 08:01 42
/lib/i386-linux-gnu/i686/cmov/libdl-2.13.so
b73de000-b7534000 r-xp  08:01 56
/lib/i386-linux-gnu/i686/cmov/libc-2.13.so
b7534000-b7535000 ---p 00156000 08:01 56
/lib/i386-linux-gnu/i686/cmov/libc-2.13.so
b7535000-b7537000 r--p 00156000 08:01 56
/lib/i386-linux-gnu/i686/cmov/libc-2.13.so
b7537000-b7538000 rw-p 00158000 08:01 56
/lib/i386-linux-gnu/i686/cmov/libc-2.13.so
b7538000-b753b000 rw-p  00:00 0
b753b000-b7557000 r-xp  08:01 18
/lib/i386-linux-gnu/libgcc_s.so.1
b7557000-b7558000 rw-p 0001b000 08:01 18
/lib/i386-linux-gnu/libgcc_s.so.1
b7558000-b757c000 r-xp  08:01 50
/lib/i386-linux-gnu/i686/cmov/libm-2.13.so
b757c000-b757d000 r--p 00023000 08:01 50
/lib/i386-linux-gnu/i686/cmov/libm-2.13.so
b757d000-b757e000 rw-p 00024000 08:01 50
/lib/i386-linux-gnu/i686/cmov/libm-2.13.so
b757e000-b765e000 r-xp  08:01 31
/usr/lib/i386-linux-gnu/libstdc++.so.6.0.17
b765e000-b765f000 ---p 000e 08:01 31
/usr/lib/i386-linux-gnu/libstdc++.so.6.0.17
b765f000-b7663000 r--p 000e 08:01 31
/usr/lib/i386-linux-gnu/libstdc++.so.6.0.17
b7663000-b7664000 rw-p 000e4000 08:01 31
/usr/lib/i386-linux-gnu/libstdc++.so.6.0.17
b7664000-b766c000 rw-p  00:00 0
b766c000-b766e000 r-xp  08:01 70
/lib/i386-linux-gnu/i686/cmov/libutil-2.13.so
b766e000-b766f000 r--p 1000 08:01 70
/lib/i386-linux-gnu/i686/cmov/libutil-2.13.so
b766f000-b767 rw-p 2000 08:01 70
/lib/i386-linux-gnu/i686/cmov/libutil-2.13.so
b767-b7795000 r-xp  08:01 4289
/usr/lib/i386-linux-gnu/libapt-pkg.so.4.12.0
b7795000-b7797000 r--p 00125000 08:01 4289
/usr/lib/i386-linux-gnu/libapt-pkg.so.4.12.0
b7797000-b7799000 rw-p 00127000 08:01 4289
/usr/lib/i386-linux-gnu/libapt-pkg.so.4.12.0
b77a3000-b77a4000 rw-p  00:00 0
b77a4000-b77ab000 r--s  08:01 12504
/usr/lib/i386-linux-gnu/gconv/gconv-modules.cache
b77ab000-b77ad000 rw-p  00:00 0
b77ad000-b77ae000 r-xp  00:00 0  [vdso]
b77ae000-b77ca000 r-xp  08:01 1239   /lib/i386-linux-gnu/
ld-2.13.so
b77ca000-b77cb000 r--p 0001b000 08:01 1239   /lib/i386-linux-gnu/
ld-2.13.so
b77cb000-b77cc000 rw-p 0001c000 08:01 1239   /lib/i386-linux-gnu/
ld-2.13.so
bfd39000-bfd7e000 rw-p  00:00 0  [stack]

-- end output --

Despite my not following the CUDF protocol (haven't come that far yet), I
don't think apt-get should exactly crash in glibc.



-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "i386";
APT::Build-Essential "";
APT::Bui

Bug#682024: apt-get: custom --solver stub crashes apt-get in glibc

[Kernc]

Ok, this is due to my virtual machine running out of memory. I'm so sorry.
:s

Please mark as Invalid.

Bug#433945:

[Kernc]

With Avahi bug #311, I understand it was agreed the bug was on
Lennart to fix.

Still, I would just like to reiterate that in 2013 on some misconfigured
public hotspots the avahi-daemon-check-dns.sh indeed doesn't stop
the daemon, which makes the hotel hotspot unavailable to the unaware
travelling novice.

For the particular server I have in mind, no DNS records exist for domain
'local':
$ nslookup
> server
Default server: 10.5.50.1
Address: 10.5.50.1#53
>
> hotspot.plaza.local
Server:10.5.50.1
Address:10.5.50.1#53

Non-authoritative answer:
Name:hotspot.plaza.local
Address: 10.5.50.1
>
> plaza.local
Server:10.5.50.1
Address:10.5.50.1#53

Non-authoritative answer:
Name:plaza.local
Address: 192.168.120.97
Name:plaza.local
Address: 192.168.120.99
>
> local
Server:10.5.50.1
Address:10.5.50.1#53

** server can't find local: SERVFAIL
> >

And /etc/resolv.conf holds:
$ cat /etc/resolv.conf
domain hotspot.plaza
search hotspot.plaza

OS X indeed has no trouble connecting.

Bug#700162: libgksu2-0: should default to sudo if no root password (see bug #481689)

[Kernc]

Package: libgksu2-0
Version: 2.0.13~pre1-6
Severity: serious
Tags: patch
Justification: 0.

Dear Maintainer,

Since 2008, if root account has no password or is locked
(e.g. by `passwd -d root`, using sudo accounts), then certain
desktop gksu invocations fail (unetbootin from the menu, wicd, ...).
They fail because the GConf key /apps/gksu/sudo-mode
is not set by default. More info in Debian gksu bug #481686
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=481689

I provide a patch for libgksu-2.0.postinst script that
fixes this issue (after each gksu installation).

This bug has been present since lenny, there's no reason
not to fix it for wheezy. I'm marking this bug serious on
RC_policy justification that it "makes unrelated software on
the system break."

While the short postinst patch may fix the problem, this is
really just a hack.

Rather, I think opinionated, libgksu should have the
'can-root-even-log-in?' check **hard-coded** (and if root
can't log in, provide sudo behavior). Think about it, if root
cannot log in, who is going to do administrative tasks if not
sudo users?


-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libgksu2-0 depends on:
ii  gconf23.2.5-1+build1
ii  libatk1.0-0   2.4.0-2
ii  libc6 2.13-37
ii  libcairo2 1.12.2-2
ii  libfontconfig12.9.0-7
ii  libfreetype6  2.4.9-1
ii  libgconf2-4   3.2.5-1+build1
ii  libgdk-pixbuf2.0-02.26.1-1
ii  libglib2.0-0  2.33.12+really2.32.4-3
ii  libgnome-keyring0 3.4.1-1
ii  libgtk2.0-0   2.24.10-2
ii  libgtop2-72.28.4-3
ii  libpango1.0-0 1.30.0-1
ii  libstartup-notification0  0.12-1
ii  libx11-6  2:1.5.0-1
ii  xauth 1:1.0.7-1

Versions of packages libgksu2-0 recommends:
ii  sudo  1.8.5p2-1

libgksu2-0 suggests no packages.

-- no debconf information


default_to_sudo_if_no_root_password.patch
Description: Binary data

Bug#481689: Still an issue on Wheezy

[Kernc]

After four+ years, this is still a bug on vanilla wheezy and it makes
certain
desktop system utilities not work out-of-the-box.
It is partially (hopefully) fixed by the patch in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700162

Bug#696718:

[Kernc]

God, Wolfram, I love you! :D
This bug had pestered me for two days.

What is the (permanent) proposed solution?
Couldn't grub be made to always include couple of most standard modules?

Bug#714508: [Bash-completion-devel] Bug#714508: bash terminates on completion if "set -o errexit" (set -e) is set

[Kernc]

On Sun, Jul 7, 2013 at 12:34 PM, Ville Skyttä  wrote:

>
> setting set -e in a normal interactive shell for anything but testing
> purposes is asking for trouble
>

I'm sure you are correct. But I'm sourcing interactively a functions.sh
script that sets -e, and after it, any completion request terminates my
terminal. Is setting -e only on the parent sourcing script a convention
'fix' for this case?

Bug#713051: bash: in /etc/skel/.bashrc, check if bash_completion has already run before

[Kernc]

Package: bash
Version: 4.2+dfsg-0.1
Severity: minor

Dear Maintainer,

By default, bash ships with bash_completion
disabled in /etc/bash.bashrc,
enabled in /etc/skel/.bashrc

If, when, an administrator decides to uncomment (enable) bash_completion in
bash.bashrc,
the script runs twice for users with unmodified .bashrc.

If a test is added to /etc/skel/.bashrc, like so:
if [ ! $BASH_COMPLETION_COMPAT_DIR ]; then
#... whole of bash_completion code
fi

The script doesn't run twice.

$ time [ ! $BASH_COMPLETION_COMPAT_DIR ] && . /etc/bash_completion

real0m0.000s
user0m0.000s
sys 0m0.000s

$ time . /etc/bash_completion

real0m0.187s
user0m0.092s
sys0m0.024s

It's a sane proposed default.


-- System Information:
Debian Release: 7.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Versions of packages bash recommends:
ii  bash-completion  1:2.0-1

-- Configuration Files:
/etc/bash.bashrc changed [not included]

-- no debconf information

Bug#420666:

[Kernc]

Yes, we recommend our users to keep their personal executables, like
scripts, in ~/.local/bin.
In hidden .local mainly because they need them available on the command
line (on $PATH),
and NOT USEFULLY VISIBLE in desktop file managers.

Bug#488588:

[Kernc]

This is a very sane proposal. This way the administrator (which is these
days the user herself) isn't necessarily bugged about package maintainer's
file being newer than hers. ?#/&

Bug#714726:

[Kernc]

severity 714726 important
merge 714726 509574
tags 714726 patch
thank you

This bug is almost 5 years old and has been duplicated several times:
http://bugs.debian.org/509574

I'm fairly naive, but it looks to me that wheezy-backports doesn't
report the suite correctly as stable-backports, and also
wheezy-proposed-updates doesn't report Suite=stable-proposed-updates,
as it obviously should according to the wiki:
https://wiki.debian.org/StableProposedUpdates
and the output I get:
W: Conflicting distribution: http://http.debian.net
stable-proposed-updates Release (expected stable-proposed-updates but
got wheezy-proposed-updates)
W: Conflicting distribution: http://http.debian.net stable-backports
Release (expected stable-backports but got wheezy-backports)

This is obviously broken. Symlinking repositories is more than fine
(bind-mounting would be better), but Release files, if with different
content, should be recreated always, obviously!

Why couldn't this make it into wheezy-updates?

Whoever is pinning, should be pinning
  Pin: release n=wheezy-backports
or
  Pin: release a=stable-backports
and not
  Pin: release a=wheezy-backports
as I understood apt_preferences(5).

Can somebody please shed some light on this?
Why does suite vs. codename work for all other archive sources except
stable-backports and stable-proposed-updates?
What happened to codename rc-buggy? Experimental is not in line with
the rest of the sources, missing it's toy like that.
Can somebody please show me way to the source code where this bug manifests?

...

Ok, I hacked a little what may be correct. It is the same hack by Mark
Hymers, just extended for the missing archives.

Is there any reason not to push this to mirrors now? :-)


dak-correct-suite.patch
Description: Binary data

Bug#718317: apt-cudf: doesn't include any source preference in the Request stanza

[Kernc]

Package: apt-cudf
Version: 3.0.2-3
Severity: normal

Dear Maintainer,

When apt-get is run with custom --solver, e.g. like this:

$ apt-get --solver custom_solver install xfce4-panel/testing   ,

the resulting CUDF scenario starts with the following request stanza:

Request: EDSP 0.4
Install: xfce4-panel:i386
Strict-Pinning: no

This is the whole of it, and there is no mention of the fact,
that the user explicitly requested installation from Suite=testing.

Also, why doesn't apt's EDSP specify a Preamble stanza with
Suite defined as suggested here: http://mancoosi.org/cudf/primer/ ?

Should this issue really be reassigned to apt?

-- System Information:
Debian Release: 7.0
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'testing')


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#693069:

[Kernc]

Hi Thomas,

You mention herethat
you built a *.deb but your GitHub repo appears untouched and this ITP
is still in progress? What gives?

Will you let the inexperienced package such fine piece of timely software?
:-P

Bug#693069:

[Kernc]

On Wed, Aug 28, 2013 at 8:21 PM, Thomas Koch  wrote:

> please nag me again if I don't manage to get it out in the next days!
>

Great, noted. Thanks! :-)

Bug#693069:

[Kernc]

On Wed, Aug 28, 2013 at 8:21 PM, Thomas Koch wrote:

> please nag me again if I don't manage to get it out in the next days!
>

Any news?

We'd love to feature Rurple-ng, I think, in our youngsters' curriculum:
http://course.coderdojo.si :-)

Bug#714508: bash terminates on completion if "set -o errexit" (set -e) is set

[Kernc]

Package: bash-completion
Version: 1:2.0-1
Severity: normal
Tags: upstream

Dear Maintainers,

When "set -o errexit" is set, bash exits on some TAB-completition.

Bash exits on:

$ set -e
$ cd 

Bash does not exit on:

$ set -e
$ c

But instead correctly shows possible options.

Bash exiting on TAB key seems wrong. If bash_completion isn't sourced in,
everything works fine (except completion:D).

Should bash_completion be made "set -e"-proof?


-- System Information:
Debian Release: 7.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages bash-completion depends on:
ii  bash  4.2+dfsg-0.1
ii  dpkg  1.16.10

bash-completion recommends no packages.

bash-completion suggests no packages.

-- no debconf information

Bug#759377: "TypeError: TreePath does not support indexing" when installing new printer

[Kernc]

Package: system-config-printer
Version: 1.4.3-4~bpo70+1
Severity: important
Tags: patch

Dear Maintainer,

Installing a new printer through the interface, at the final step of
selecting the
(correctly recognized and pre-selected printer (e.g. Xerox Phaser 3140), the
wizard doesn't proceed -- it can be Closed, but Forward doesn't do anthing,
particularly it doesn't install the printer!

Running `system-config-printer --debug` reveals the following Python error:

Traceback (most recent call last):
  File "/usr/share/system-config-printer/newprinter.py", line 912, in
on_btnNPForward_clicked
self.nextNPTab()
  File "/usr/share/system-config-printer/newprinter.py", line 1459, in
nextNPTab
self.ppd = self.getNPPPD()
  File "/usr/share/system-config-printer/newprinter.py", line 3786, in
getNPPPD
nr = model.get_path(iter)[0]
TypeError: 'TreePath' object does not support indexing

I did manage to fix it by changing the offending line (and another similar
line
futher below in the file) to:

  nr = int(str(model.get_path(iter)))

Not sure if it has something to do with Gtk3's PyGObject introspection (et
al.)
incompletely migrated into stable or whether it's a genuine overlooked bug,
I'm tagging it patch.


-- System Information:
Debian Release: 7.6

Versions of packages system-config-printer depends on:
ii  gir1.2-gdkpixbuf-2.0   2.26.1-1
ii  gir1.2-glib-2.01.32.1-1
ii  gir1.2-gtk-3.0 3.4.2-7
ii  gir1.2-notify-0.7  0.7.5-1
ii  gir1.2-packagekitglib-1.0  0.7.6-3
ii  gir1.2-pango-1.0   1.30.0-1
ii  gnome-icon-theme   3.4.0-2
ii  python 2.7.3-4+deb7u1
ii  python-cairo   1.8.8-1+b2
ii  python-cups1.9.63-1~bpo70+1
ii  python-cupshelpers 1.4.3-4~bpo70+1
ii  python-dbus1.1.1-1
ii  python-gi  3.2.2-2
ii  python-gobject-2   2.28.6-10
ii  python-libxml2 2.8.0+dfsg1-7+wheezy1

Versions of packages system-config-printer recommends:
pn  cups-pk-helper  
ii  gir1.2-gnomekeyring-1.0 3.4.1-1
ii  python-smbc 1.0.6-1+b1
ii  system-config-printer-udev  1.4.3-4~bpo70+1

Versions of packages system-config-printer suggests:
pn  python-gnomekeyring  
pn  sessioninstaller 

-- no debconf information

Bug#814316: Fetch flashplugin-nonfree archive from Macromedia directly?

[Kernc]

Bart,

Thank you for maintaining this package for so long. Possibly hundreds of
thousands depend on in to maintain a working Flash player. Thanks!

Given how this bug really pops up a lot [1], and given how its severity is
always grave (because it's mostly a huge security issue), have you or would
you consider patches that adapted the update script to fetch the tar.gz
from the upstream site directly? The upstream download site _is_ available
over HTTPS [2]. Could this be acceptable?

[1]:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;package=flashplugin-nonfree
[2]:
https://www.ssllabs.com/ssltest/analyze.html?d=fpdownload.macromedia.com

Bug#776708:

[Kernc]

A daily cron job does sound like a good idea.

Additionally, Flash archive seems to be available over HTTPS [1], so the
intermediary access to p-d-o [2] isn't really necessary.

[1]:
https://www.ssllabs.com/ssltest/analyze.html?d=fpdownload.macromedia.com
[2]: http://people.debian.org/~bartm/flashplugin-nonfree/D5C0FC14/

Provided we trust Adobe either way, is GPG better than HTTPS in assuring
the user's download is legit?

Bug#520619:

[Kernc]

The request is not unpopular.

https://bugs.launchpad.net/ubuntu/+source/pigz/+bug/523309
http://askubuntu.com/questions/62607/whats-the-best-way-to-use-parallel-bzip2-and-gzip-by-default
http://serverfault.com/questions/270814/fastest-way-to-extract-tar-gz

Besides alternatives, `Provides: gzip` could be set.

Are patches welcome?

Bug#497038: speed-up of list/show

[Kernc]

show/list subcommands could additionally be sped up by checking if the
package in question is installed, and if so, using uncompressed
/var/lib/dpkg/info/[package].list instead.

Bug#815186: libfile-mimeinfo-perl: mimeopen should ship a *.desktop file

[Kernc]

Package: libfile-mimeinfo-perl
Version: 0.27-1
Severity: normal

Dear Maintainers!

/usr/bin/mimeopen, working fabulously for downloaded files of
application/octet-stream mime type, should include a
/usr/share/applications/mimeopen.desktop file like the following:

[Desktop Entry]
Type=Application
Version=1.0
Name=mimeopen
GenericName=Open with default application
Comment=Mime-type and file extension-aware file opener
Exec=mimeopen -n %F
Icon=system-run
Terminal=false
MimeType=application/octet-stream

This will allow e.g. Iceweasel to exploit mimeopen's stated ability to open
application/octet-stream files (which browsers often receive when
appropriate response headers are not sent) and the latter will open
the file with preferred application without problem.

Since one can't really sensibly associate application/octet-stream with
any single application, the attached file most elegantly solves the issue
of Iceweasel proposing to open, for one ffs example, downloaded PDF
files in VLC or tar.gz archives in audacious!

Thanks!


mimeopen.desktop
Description: application/desktop

Bug#813607: RFP: earlyoom -- Early out-of-memory daemon for Linux

[Kernc]

Package: wnpp
Severity: wishlist

* Package name: earlyoom
  Version : 0.~git
  Upstream Author : rfjakob 
* URL : https://github.com/rfjakob/earlyoom
* License : N/A (open-source)
  Description : Early out-of-memory (OOM) daemon for Linux


When the swapping starts, instead of sitting in front of the unresponsive
system, listening to the grinding disk for minutes, I usually just press
the reset button and get back to what I was doing more quickly, regardless
even of the workspace I just lost.