Bug#575367: newvserver: undocumented restriction on hostname
Selon Ola Lundqvist : > merge 575367 409862 > thanks > > Hi Yann > > On Thu, Mar 25, 2010 at 10:06:20AM +0100, Yann Dirson wrote: > > Package: vserver-debiantools > > Version: 0.6.4 > > > > # newvserver --hostname a [...] > > newvserver error: --hostname must be a hostname for the vserver > > > > looking at what could be wrong with one-char hostnames, I am still > > puzzled by the expression used with the "case" which deals with > > hostname parsing. > > > > If you insist on doing such a check (ie. you > > really feel "[a-z0-9]*([a-z0-9_])" is not enough), why not using > > "[a-z0-9]?(*([a-z0-9_])[a-z0-9])" ? > > Because then you can define the hostname '_a' which is not a valid > hostname. No, this is a sequence of mandatory "[a-z0-9]" and optional "*([a-z0-9_])[a-z0-9]" using "?(...)". > Also with this definition you can not have the hostname > 'test-host' as you have forgotten the '-' character. Right, I meant "[a-z0-9]?(*([a-z0-9_-])[a-z0-9])" > But if you add that it causes other problems. > > In any case you can see a more lengthy discussion at > bugs.debian.org/409862 about this issue. I have not yet got a > really good check description for this. It is close but not perfect. I'll see if I find time to read it. But at first glance I can't understand why it would be a problem, and why the debian tools would need to be more strict than the basic vserver tools. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#844296: libstdc++6-7-dbg: undeclared common file with libstdc++6-6-dbg
Package: libstdc++6-7-dbg Version: 7-20161112-1 Unpacking libstdc++6-7-dbg:amd64 (7-20161112-1) ... dpkg: error processing archive /tmp/apt-dpkg-install-K00oDb/18-libstdc++6-7-dbg_7-20161112-1_amd64.deb (--unpack): trying to overwrite '/usr/lib/x86_64-linux-gnu/debug/libstdc++.a', which is also in package libstdc++6-6-dbg:amd64 6.2.0-10 dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) Errors were encountered while processing: /tmp/apt-dpkg-install-K00oDb/18-libstdc++6-7-dbg_7-20161112-1_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1)
Bug#859147: network-manager: restart failure on upgrade
Package: network-manager Version: 1.6.2-3 When upgrading from 1.6.2-2: Setting up network-manager (1.6.2-3) ... Job for NetworkManager.service failed because a timeout was exceeded. See "systemctl status NetworkManager.service" and "journalctl -xe" for details. invoke-rc.d: initscript network-manager, action "restart" failed. ● NetworkManager.service - Network Manager Loaded: loaded (/lib/systemd/system/NetworkManager.service; enabled; vendor preset: enabled) Active: activating (auto-restart) (Result: timeout) since Thu 2017-03-30 23:43:52 CEST; 4ms ago Docs: man:NetworkManager(8) Process: 16706 ExecStart=/usr/sbin/NetworkManager --no-daemon (code=killed, signal=TERM) Main PID: 16706 (code=killed, signal=TERM) CPU: 1min 30.013s Mar 30 23:43:52 yantop systemd[1]: NetworkManager.service: Unit entered failed state. Mar 30 23:43:52 yantop systemd[1]: NetworkManager.service: Failed with result 'timeout'. dpkg: error processing package network-manager (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: network-manager === # cat /etc/network/interfaces # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). source /etc/network/interfaces.d/* # The loopback network interface auto lo iface lo inet loopback === # cat /etc/network/interfaces.d/LOCAL-lxc auto lxcbr0 iface lxcbr0 inet static address 10.100.0.1 bridge_ports none bridge_fd 0 bridge_maxwait 0 up iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE Any other information would be useful ?
Bug#859147: [Pkg-utopia-maintainers] Bug#859147: network-manager: restart failure on upgrade
Here is the relevant journalctl -alb excerpt, sending more details in private mail Mar 30 20:22:06 yantop systemd[1]: Stopping Network Manager Wait Online... Mar 30 20:22:06 yantop systemd[1]: Stopping Network Manager... Mar 30 20:22:06 yantop NetworkManager[4948]: [1490898126.5839] caught SIGTERM, shutting down normally. Mar 30 20:22:06 yantop NetworkManager[4948]: [1490898126.6660] device (wlan0): state change: unavailable -> unmanaged (reason 'unmanaged') [20 10 3] Mar 30 20:22:06 yantop NetworkManager[4948]: [1490898126.6663] device (wlan0): set-hw-addr: reset MAC address to B4:6D:83:58:53:31 (unmanage) Mar 30 20:22:06 yantop NetworkManager[4948]: [1490898126.6676] device (E0:98:61:62:F4:53): state change: disconnected -> unmanaged (reason 'unmanaged') [30 10 3] Mar 30 20:22:06 yantop NetworkManager[4948]: [1490898126.6761] device (44:00:10:24:8F:70): state change: disconnected -> unmanaged (reason 'unmanaged') [30 10 3] Mar 30 20:22:06 yantop NetworkManager[4948]: [1490898126.8186] exiting (success) Mar 30 20:22:07 yantop systemd[1]: Stopped Network Manager. Mar 30 20:22:07 yantop systemd[1]: Starting Network Manager... Mar 30 20:23:06 yantop systemd[1]: Starting Laptop Mode Tools - Battery Polling Service... Mar 30 20:23:06 yantop systemd[1]: Reloading Laptop Mode Tools. Mar 30 20:23:06 yantop systemd[1]: Started Laptop Mode Tools - Battery Polling Service. Mar 30 20:23:06 yantop laptop_mode[5372]: Laptop mode Mar 30 20:23:06 yantop laptop_mode[5372]: enabled, not active [unchanged] Mar 30 20:23:06 yantop systemd[1]: Reloaded Laptop Mode Tools. Mar 30 20:23:37 yantop systemd-journald[398]: Suppressed 1050 messages from /init.scope Mar 30 20:23:37 yantop systemd[1]: NetworkManager.service: Start operation timed out. Terminating. Mar 30 20:23:37 yantop systemd[1]: Failed to start Network Manager. Mar 30 20:23:37 yantop systemd[1]: Dependency failed for Network Manager Wait Online. Mar 30 20:23:37 yantop systemd[1]: NetworkManager-wait-online.service: Job NetworkManager-wait-online.service/start failed with result 'dependency'. Mar 30 20:23:37 yantop systemd[1]: NetworkManager.service: Unit entered failed state. Mar 30 20:23:37 yantop systemd[1]: NetworkManager.service: Failed with result 'timeout'. Mar 30 20:23:37 yantop systemd[1]: NetworkManager.service: Service hold-off time over, scheduling restart. Mar 30 20:23:37 yantop systemd[1]: Stopped Network Manager. Mar 30 20:23:37 yantop systemd[1]: Starting Network Manager... Mar 30 20:23:38 yantop systemd[1]: Reloading. Mar 30 20:23:39 yantop systemd[1]: Failed to set up mount unit: Invalid argument Mar 30 20:23:39 yantop systemd[1]: Failed to set up mount unit: Invalid argument Mar 30 20:23:39 yantop systemd[1]: Failed to set up mount unit: Invalid argument Mar 30 20:23:39 yantop systemd[1]: Failed to set up mount unit: Invalid argument - Mail original - > De: "Michael Biebl" > À: ydir...@free.fr, 859...@bugs.debian.org > Envoyé: Vendredi 31 Mars 2017 00:12:59 > Objet: Re: [Pkg-utopia-maintainers] Bug#859147: network-manager: restart > failure on upgrade > > Am 30.03.2017 um 23:50 schrieb ydir...@free.fr: > > > Any other information would be useful ? > > Can you attach the following information > journalctl -alb > systemd-cgls > > > > > > > > -- > Why is it that all of the instruments seeking intelligent life in the > universe are pointed away from Earth? >
Bug#859147: [Pkg-utopia-maintainers] Bug#859147: network-manager: restart failure on upgrade
Will test this soon. Oh, just noticed that the fan was indeed noisy... and top reports this: PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND 6019 root 20 0 237608 96996 2368 R 100.0 1.2 0:30.49 (kManager) I can't seem to find what a "kManager" process could be around here. There is but a common suffix with NetworkManager, but I admit I don't see why it would be truncated. Looking at /proc it just looks like a systemd thread, and it gets started and restarted again and again. - Mail original - > De: "Michael Biebl" > À: ydir...@free.fr > Cc: 859...@bugs.debian.org > Envoyé: Vendredi 31 Mars 2017 11:12:38 > Objet: Re: [Pkg-utopia-maintainers] Bug#859147: network-manager: restart > failure on upgrade > > Am 31.03.2017 um 11:08 schrieb ydir...@free.fr: > > Here is the relevant journalctl -alb excerpt, sending more details > > in private mail > > > > Mar 30 20:22:06 yantop systemd[1]: Stopping Network Manager Wait > > Online... > > Mar 30 20:22:06 yantop systemd[1]: Stopping Network Manager... > > Mar 30 20:22:06 yantop NetworkManager[4948]: > > [1490898126.5839] caught SIGTERM, shutting down normally. > > Mar 30 20:22:06 yantop NetworkManager[4948]: > > [1490898126.6660] device (wlan0): state change: unavailable -> > > unmanaged (reason 'unmanaged') [20 10 3] > > Mar 30 20:22:06 yantop NetworkManager[4948]: > > [1490898126.6663] device (wlan0): set-hw-addr: reset MAC address > > to B4:6D:83:58:53:31 (unmanage) > > Mar 30 20:22:06 yantop NetworkManager[4948]: > > [1490898126.6676] device (E0:98:61:62:F4:53): state change: > > disconnected -> unmanaged (reason 'unmanaged') [30 10 3] > > Mar 30 20:22:06 yantop NetworkManager[4948]: > > [1490898126.6761] device (44:00:10:24:8F:70): state change: > > disconnected -> unmanaged (reason 'unmanaged') [30 10 3] > > Mar 30 20:22:06 yantop NetworkManager[4948]: > > [1490898126.8186] exiting (success) > > Mar 30 20:22:07 yantop systemd[1]: Stopped Network Manager. > > Mar 30 20:22:07 yantop systemd[1]: Starting Network Manager... > > Mar 30 20:23:06 yantop systemd[1]: Starting Laptop Mode Tools - > > Battery Polling Service... > > Mar 30 20:23:06 yantop systemd[1]: Reloading Laptop Mode Tools. > > Mar 30 20:23:06 yantop systemd[1]: Started Laptop Mode Tools - > > Battery Polling Service. > > Mar 30 20:23:06 yantop laptop_mode[5372]: Laptop mode > > Mar 30 20:23:06 yantop laptop_mode[5372]: enabled, not active > > [unchanged] > > Mar 30 20:23:06 yantop systemd[1]: Reloaded Laptop Mode Tools. > > Mar 30 20:23:37 yantop systemd-journald[398]: Suppressed 1050 > > messages from /init.scope > > Mar 30 20:23:37 yantop systemd[1]: NetworkManager.service: Start > > operation timed out. Terminating. > > Your systemd instance seems to be in a confused state. I wonder if > that's related to laptop-mode-tools. > Try purging that package and reboot to reset the state. > > > -- > Why is it that all of the instruments seeking intelligent life in the > universe are pointed away from Earth? > >
Bug#859147: [Pkg-utopia-maintainers] Bug#859147: network-manager: restart failure on upgrade
Purged laptop-mode-tools, rebooted, no change. network-manager is properly started at boot time, service can be stopped, but not started again afterwards: systemd now has a "(kManager)" child at near-100% CPU. Found the culprit: I have a broken schroot configuration (talk about pending work and switching to other tasks...), where the chroot is under my home dir, which gets mounted in the chroot. Schroot does not detect the loop and recursively mounts all /home submounts, apparently until a 65535 mountpoint limit Thus I assume that systemd is attempting to mount something, and not dealing properly with the error ? - Mail original - > De: ydir...@free.fr > À: "Michael Biebl" > Cc: 859...@bugs.debian.org > Envoyé: Samedi 1 Avril 2017 10:49:08 > Objet: Re: [Pkg-utopia-maintainers] Bug#859147: network-manager: restart > failure on upgrade > > Will test this soon. > > Oh, just noticed that the fan was indeed noisy... and top reports > this: > > PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ > COMMAND > 6019 root 20 0 237608 96996 2368 R 100.0 1.2 0:30.49 > (kManager) > > I can't seem to find what a "kManager" process could be around here. > There > is but a common suffix with NetworkManager, but I admit I don't see > why it > would be truncated. Looking at /proc it just looks like a systemd > thread, and > it gets started and restarted again and again. > > - Mail original - > > De: "Michael Biebl" > > À: ydir...@free.fr > > Cc: 859...@bugs.debian.org > > Envoyé: Vendredi 31 Mars 2017 11:12:38 > > Objet: Re: [Pkg-utopia-maintainers] Bug#859147: network-manager: > > restart failure on upgrade > > > > Am 31.03.2017 um 11:08 schrieb ydir...@free.fr: > > > Here is the relevant journalctl -alb excerpt, sending more > > > details > > > in private mail > > > > > > Mar 30 20:22:06 yantop systemd[1]: Stopping Network Manager Wait > > > Online... > > > Mar 30 20:22:06 yantop systemd[1]: Stopping Network Manager... > > > Mar 30 20:22:06 yantop NetworkManager[4948]: > > > [1490898126.5839] caught SIGTERM, shutting down normally. > > > Mar 30 20:22:06 yantop NetworkManager[4948]: > > > [1490898126.6660] device (wlan0): state change: unavailable -> > > > unmanaged (reason 'unmanaged') [20 10 3] > > > Mar 30 20:22:06 yantop NetworkManager[4948]: > > > [1490898126.6663] device (wlan0): set-hw-addr: reset MAC address > > > to B4:6D:83:58:53:31 (unmanage) > > > Mar 30 20:22:06 yantop NetworkManager[4948]: > > > [1490898126.6676] device (E0:98:61:62:F4:53): state change: > > > disconnected -> unmanaged (reason 'unmanaged') [30 10 3] > > > Mar 30 20:22:06 yantop NetworkManager[4948]: > > > [1490898126.6761] device (44:00:10:24:8F:70): state change: > > > disconnected -> unmanaged (reason 'unmanaged') [30 10 3] > > > Mar 30 20:22:06 yantop NetworkManager[4948]: > > > [1490898126.8186] exiting (success) > > > Mar 30 20:22:07 yantop systemd[1]: Stopped Network Manager. > > > Mar 30 20:22:07 yantop systemd[1]: Starting Network Manager... > > > Mar 30 20:23:06 yantop systemd[1]: Starting Laptop Mode Tools - > > > Battery Polling Service... > > > Mar 30 20:23:06 yantop systemd[1]: Reloading Laptop Mode Tools. > > > Mar 30 20:23:06 yantop systemd[1]: Started Laptop Mode Tools - > > > Battery Polling Service. > > > Mar 30 20:23:06 yantop laptop_mode[5372]: Laptop mode > > > Mar 30 20:23:06 yantop laptop_mode[5372]: enabled, not active > > > [unchanged] > > > Mar 30 20:23:06 yantop systemd[1]: Reloaded Laptop Mode Tools. > > > Mar 30 20:23:37 yantop systemd-journald[398]: Suppressed 1050 > > > messages from /init.scope > > > Mar 30 20:23:37 yantop systemd[1]: NetworkManager.service: Start > > > operation timed out. Terminating. > > > > Your systemd instance seems to be in a confused state. I wonder if > > that's related to laptop-mode-tools. > > Try purging that package and reboot to reset the state. > > > > > > -- > > Why is it that all of the instruments seeking intelligent life in > > the > > universe are pointed away from Earth? > > > > >
Bug#855788: 855788 severity
FWIW, no such problem here. Is that high severity really warranted ?
Bug#857374: virtualenvwrapper: bash completion lacks testing for availability
Package: virtualenvwrapper Version: 4.3.1-2 When virtualenvwrapper is uninstalled but not purged, we get this each time bash completion is sourced: bash: /usr/share/virtualenvwrapper/virtualenvwrapper_lazy.sh: No such file or directory
Bug#776941: dh-kpatches: please help make builds reproducible
Well, the package is orphaned (although I never did an upload removing my name from the maintainer field, it has a proper WNPP bug). For some reason some people seem to be still using it :) - Mail original - > De: "Chris Lamb" > À: 776...@bugs.debian.org > Envoyé: Samedi 18 Février 2017 23:05:36 > Objet: Bug#776941: dh-kpatches: please help make builds reproducible > > > Would you consider applying this patch and uploading? > > Friendly ping on this :) > > > Best wishes, > > -- > ,''`. > : :' : Chris Lamb > `. `'` la...@debian.org / chris-lamb.co.uk >`- >
Bug#824958: QtQuick1 removal from the archive
tags 824958 + pending thanks Fixed in git - Mail original - > De: "Lisandro Damián Nicanor Pérez Meyer" > À: 824...@bugs.debian.org > Cc: ydir...@free.fr > Envoyé: Dimanche 22 Mai 2016 16:22:51 > Objet: Bug#824958: QtQuick1 removal from the archive > > On Sunday 22 May 2016 12:06:00 Bruno Coudoin wrote: > > Hi, > > > > We don't use QtQuick1 at all. > > Yann: in this case removing qtquick1-5-dev from build dependencies > should be > enough. > > -- > Hiroshima '45, > Chernobyl '86, > Windows '95. > Grafitti en Niceto Vega 5940, Buenos Aires. De una foto de Mario > Gallo. > > Lisandro Damián Nicanor Pérez Meyer > http://perezmeyer.com.ar/ > http://perezmeyer.blogspot.com/ >
Bug#807444: stormbaancoureur: doc mentions non-shipped example keybinding file
Package: stormbaancoureur Version: 2.1.6-1.1 Quoting README: >For keyboard controls, you can customize the key mapping by copying the file >.stormbaancoureur.keys.example to $HOME/.stormbaancoureur.keys and then >editting >it. Having this file in the package would be a must!
Bug#807447: 0ad: version 0.0.19 is out
Package: 0ad Version: 0.0.18-2 Severity: wishlist 0.0.19 was recently released, it would be great to have it :)
Bug#808221: okular: crashes with no clue when launched from a reconnected screen session
Package: okular Version: 4:15.08.3-1 When running from a screen(1) session that was created before logging out and logging in again, so various envvars are wrong, okular crashes and presents the bug-reporting dialog instead of presenting to the user the more informative "Session bus not found" that can be found in the backtrace: Application: Okular (okular), signal: Aborted Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [KCrash Handler] #6 0x7fc276f5b657 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:55 #7 0x7fc276f5ca2a in __GI_abort () at abort.c:89 #8 0x7fc277939f35 in qt_message_output (msgType=, buf=0x14e5918 "okular(32094)/kdeui (kdelibs): Session bus not found \nTo circumvent this problem try the following command (with Linux and bash) \nexport $(dbus-launch) ") at global/qglobal.cpp:2447 #9 0x7fc27911761c in QDebug::~QDebug (this=0x7ffc45ad6ff0, __in_chrg=) at /usr/include/qt4/QtCore/qdebug.h:85 #10 0x7fc2791fd83a in KApplicationPrivate::init (this=0x144d930, GUIenabled=GUIenabled@entry=true) at ../../kdeui/kernel/kapplication.cpp:516 #11 0x7fc2791fe232 in KApplication::KApplication (this=0x7ffc45ad7230, GUIenabled=true) at ../../kdeui/kernel/kapplication.cpp:352 #12 0x00409840 in main (argc=2, argv=0x7ffc45ad7348) at ../../shell/main.cpp:37 (fixing the envvars to match current session is sufficient to get it working again)
Bug#808586: weboob: network connection setting up bash completion
Package: weboob Version: 1.0-3 While starting up a (root) shell while on public wifi (wlan0 up but not logged into the captive portal), I get the following when starting up a root shell. Looks somewhat like if much too much things were being attempted in the context of initializing shell completion (which is already deadly slow) 2015-12-21 11:00:42,816:INFO:requests.packages.urllib3.connectionpool:1.0:connectionpool.py:207:_new_conn Starting new HTTP connection (1): updates.weboob.org 2015-12-21 11:00:43,107:INFO:requests.packages.urllib3.connectionpool:1.0:connectionpool.py:758:_new_conn Starting new HTTPS connection (1): controller.access.network Traceback (most recent call last): File "/usr/bin/weboob-config", line 27, in WeboobCfg.run() File "/usr/lib/python2.7/dist-packages/weboob/tools/application/console.py", line 212, in run super(ConsoleApplication, klass).run(args) File "/usr/lib/python2.7/dist-packages/weboob/tools/application/base.py", line 458, in run app = cls() File "/usr/lib/python2.7/dist-packages/weboob/tools/application/repl.py", line 115, in __init__ ConsoleApplication.__init__(self, ReplOptionParser(self.SYNOPSIS, version=self._get_optparse_version())) File "/usr/lib/python2.7/dist-packages/weboob/tools/application/console.py", line 91, in __init__ Application.__init__(self, option_parser) File "/usr/lib/python2.7/dist-packages/weboob/tools/application/base.py", line 147, in __init__ self.weboob = self.create_weboob() File "/usr/lib/python2.7/dist-packages/weboob/tools/application/base.py", line 112, in create_weboob return Weboob() File "/usr/lib/python2.7/dist-packages/weboob/core/ouiboube.py", line 350, in __init__ self.repositories = Repositories(workdir, datadir, self.VERSION) File "/usr/lib/python2.7/dist-packages/weboob/core/repositories.py", line 456, in __init__ self.update() File "/usr/lib/python2.7/dist-packages/weboob/core/repositories.py", line 621, in update self.update_repositories(progress) File "/usr/lib/python2.7/dist-packages/weboob/core/repositories.py", line 588, in update_repositories repository.retrieve_index(self.browser, repo_path) File "/usr/lib/python2.7/dist-packages/weboob/core/repositories.py", line 175, in retrieve_index self.parse_index(fp) File "/usr/lib/python2.7/dist-packages/weboob/core/repositories.py", line 220, in parse_index config.readfp(fp) File "/usr/lib/python2.7/ConfigParser.py", line 324, in readfp self._read(fp, filename) File "/usr/lib/python2.7/ConfigParser.py", line 512, in _read raise MissingSectionHeaderError(fpname, lineno, line) ConfigParser.MissingSectionHeaderError: File contains no section headers. file: , line: 1 'http://www.w3.org/TR/html4/loose.dtd";>\n'
Bug#826311: pcmanfm-qt: lacks icons
Package: pcmanfm-qt Version: 0.11.0-3 With all depends and recommends installed, I don't get any toolbar icons, nor any file icon in contents pane. Looks like a missing dependency. Eg, "strace -efile |& grep icon" shows it's trying to find lots of icons in /usr/share/icons/hicolor/, which apt-file search does not find in Debian.
Bug#826321: uscan: typo in manpage
Package: devscripts Version: 2.16.4 Tags: patch "passive" option for FTP is typoed as "passsive", evading search
Bug#826334: dget: removes existing dir by default without asking
Package: devscripts Version: 2.16.4 Severity: grave dget unpacks the downloaded source by default, even if the target directory was pre-existing. Moreover, it does not just unpack it above the pre-existing dir, but removes it first, together with all the other files it may contain !
Bug#826311: closed by Alf Gaida (Bug#826311: fixed in pcmanfm-qt 0.11.0-4)
Well, the problem of the selection of the theme is not that easy. I have themes adwaita, tango, oxygen installed. * when I open the prefs, adwaita is highlighted, but apparently not active, as I can get file icons after switching to another theme and then back. I originally thought the initial setup was "use de-provided", but in fact it seems to be "elementary". This is probably what should be the first recommended option, but it seems to be only available in experimental. To which we can add a couple more items: * unavailable default theme wrongly handled in GUI * if I select a theme it only shows icons for files, but none in toolbar, until I restart the program, after which I can switch and the icons get updated * razor-qt has a default theme selection, but it seems ignored - it may be a razor-qt bug, though * cannot select "de-provided" theme in GUI, even removing the config file gets me black to all-blank icons without a warning that something is wrong * oxygen is listed twice in the list (one appears as "default.kde4" in the config) You may want to forward this list of issues upstream, I don't think it's really worth to open new bug in Debian for all of them :) Best regards, Yann
Bug#796222: bug fixed in experimental
fixed 796222 1.0.5~20140831-1 thanks Just checked that this bug is not present any more in experimental, would be worth to upload it to unstable ?
Bug#826434: xul-ext-automatic-save-folder: new upstream beta
Package: xul-ext-automatic-save-folder Version: 1.0.5~20140831-1 A new beta was published in February 2016, and there is an official github repo now.
Bug#823748: tar: illegal hardware instruction breaks apt-get upgrade
Would it be related to gcc taking advantage of the drop of i565 support ? https://lists.debian.org/debian-devel-announce/2016/05/msg1.html
Bug#823755: pinpoint: segfaults on example
Package: pinpoint Version: 1:0.1.8-2 Severity: important X-debbugs-CC: pkg-gnome-maintain...@lists.alioth.debian.org Just running "pinpoint /usr/share/doc/pinpoint/examples/introduction.pin" shows the first slide, and if I just wait or hit a key, I get a segfault. The problem may be in the underlying libraries, but could simply be a case of buffer overflow. This machine uses gtk 3.20, and I could reproduce the crash on one that's still on 3.18. Both are using libxcursor 1:1.1.14-1+b1. (gdb) bt #0 __GI___pthread_mutex_lock (mutex=0x21) at ../nptl/pthread_mutex_lock.c:68 #1 0x7313e44a in XrmQGetResource (db=0x63ecc0, names=names@entry=0x7fffd560, classes=classes@entry=0x7fffd570, pType=pType@entry=0x7fffd55c, pValue=pValue@entry=0x7fffd580) at ../../src/Xrm.c:2549 #2 0x7311a796 in XGetDefault (dpy=dpy@entry=0x6284f0, prog=prog@entry=0x7fffeccba63d "Xcursor", name=name@entry=0x7fffeccba6cf "core") at ../../src/GetDflt.c:231 #3 0x7fffeccb7748 in _XcursorGetDisplayInfo (dpy=0x6284f0) at ../../src/display.c:151 #4 0x7fffeccb7789 in XcursorSupportsARGB (dpy=) at ../../src/display.c:297 #5 0x7fffeccba121 in XcursorNoticeCreateBitmap (dpy=0x21, pid=140737488344416, width=4294956400, height=332) at ../../src/xlib.c:132 #6 0x73114d01 in XCreatePixmap (dpy=0x6284f0, d=d@entry=245, width=width@entry=1, height=height@entry=1, depth=depth@entry=1) at ../../src/CrPixmap.c:61 #7 0x7245bbe4 in _gdk_x11_window_create_bitmap_surface (window=0x63f000, width=width@entry=1, height=height@entry=1) at /build/gtk+3.0-Ym2tpG/gtk+3.0-3.20.3/./gdk/x11/gdkwindow-x11.c:586 #8 0x7243ad82 in get_blank_cursor (display=0x635020) at /build/gtk+3.0-Ym2tpG/gtk+3.0-3.20.3/./gdk/x11/gdkcursor-x11.c:219 #9 _gdk_x11_display_get_cursor_for_type (display=0x635020, cursor_type=GDK_BLANK_CURSOR) at /build/gtk+3.0-Ym2tpG/gtk+3.0-3.20.3/./gdk/x11/gdkcursor-x11.c:270 #10 0x76da6776 in clutter_stage_gdk_set_cursor_visible (stage_window=0x671120, cursor_visible=) at gdk/clutter-stage-gdk.c:545 #11 0x76e0f384 in clutter_stage_hide_cursor (stage=0xb18d00) at clutter-stage.c:2724 #12 0x00408123 in ?? () #13 0x75806a53 in g_timeout_dispatch (source=0x142af50, callback=, user_data=) at /build/glib2.0-2CrUwg/glib2.0-2.48.0/./glib/gmain.c:4577 #14 0x75805fea in g_main_dispatch (context=0x65ac10) at /build/glib2.0-2CrUwg/glib2.0-2.48.0/./glib/gmain.c:3154 #15 g_main_context_dispatch (context=context@entry=0x65ac10) at /build/glib2.0-2CrUwg/glib2.0-2.48.0/./glib/gmain.c:3769 #16 0x75806390 in g_main_context_iterate (context=context@entry=0x65ac10, block=block@entry=1, dispatch=dispatch@entry=1, self=) at /build/glib2.0-2CrUwg/glib2.0-2.48.0/./glib/gmain.c:3840 #17 0x7580643c in g_main_context_iteration (context=context@entry=0x65ac10, may_block=may_block@entry=1) at /build/glib2.0-2CrUwg/glib2.0-2.48.0/./glib/gmain.c:3901 #18 0x76a86ccd in g_application_run (application=0x84d0f0, argc=0, argv=0x0) at /build/glib2.0-2CrUwg/glib2.0-2.48.0/./gio/gapplication.c:2381 #19 0x00405101 in ?? () #20 0x7521b610 in __libc_start_main (main=0x404f40, argc=2, argv=0x7fffda38, init=, fini=, rtld_fini=, stack_end=0x7fffda28) at libc-start.c:291 #21 0x004051d9 in ?? () a valgrind run would point to some unitialized mutex: ==8274== Use of uninitialised value of size 8 ==8274==at 0x745EA94: pthread_mutex_lock (pthread_mutex_lock.c:68) ==8274==by 0x9826449: XrmQGetResource (Xrm.c:2549) ==8274==by 0x9802795: XGetDefault (GetDflt.c:231) ==8274==by 0xFD57747: _XcursorGetDisplayInfo (display.c:151) ==8274==by 0xFD57788: XcursorSupportsARGB (display.c:297) ==8274==by 0xFD5A120: XcursorNoticeCreateBitmap (xlib.c:132) ==8274==by 0x97FCD00: XCreatePixmap (CrPixmap.c:61) ==8274==by 0xA5BABE3: _gdk_x11_window_create_bitmap_surface (gdkwindow-x11.c:586) ==8274==by 0xA599D81: get_blank_cursor (gdkcursor-x11.c:219) ==8274==by 0xA599D81: _gdk_x11_display_get_cursor_for_type (gdkcursor-x11.c:270) ==8274==by 0x5B95775: clutter_stage_gdk_set_cursor_visible (in /usr/lib/x86_64-linux-gnu/libclutter-1.0.so.0.2600.0) ==8274==by 0x5BFE383: clutter_stage_hide_cursor (in /usr/lib/x86_64-linux-gnu/libclutter-1.0.so.0.2600.0) ==8274==by 0x408122: ??? (in /usr/bin/pinpoint) ==8274== ==8274== Invalid read of size 4 ==8274==at 0x745EA94: pthread_mutex_lock (pthread_mutex_lock.c:68) ==8274==by 0x9826449: XrmQGetResource (Xrm.c:2549) ==8274==by 0x9802795: XGetDefault (GetDflt.c:231) ==8274==by 0xFD57747: _XcursorGetDisplayInfo (display.c:151) ==8274==by 0xFD57788: XcursorSupportsARGB (display.c:297) ==8274==by 0xFD5A120: XcursorNoticeCreateBitmap (xlib.c:132) ==8274==by 0x97FCD00: XCreatePixmap (CrPixmap.c:61) ==8274==by 0xA5BABE3: _gdk_x11_window_create_bitmap_surface (gdkwindow-x11.c:586) ==8274==by
Bug#821952: firefox-esr: undistinguishable from firefox in apps menu
Package: firefox-esr, firefox Version: 45.0.2esr-1, 45.0.2-1 Both firefox and firefox-esr can be installed at the same time, and when they are, we get 2 "Firefox" entries in the "Internet" apps menu, and even the tooltips are strictly identical. There should be a way to distinguish them. It is especially causing problems today, where a handful of plugins did not gain the "|firefox" alternative dep and still pull firefox-esr through iceaweal, preventing those that would like to only have "firefox" installed to do so.
Bug#822092: plantuml: debian/copyright lacks source info
Source: plantuml Version: 8024-2 Adding the source URL to the copyright file would help navigation in the PTS. BTW, Upstream-name is redundant when it is the same as the debian package name.
Bug#816501: plantuml failure on deployment diag
severity 816501 important
thanks
Hi Arnaud,
Thanks for this quick answer
- Mail original -
> Your examples work fine with last version of PlantUML:
> http://plantuml.com/plantuml/png/oyjFILLmLAZcKb18B2h9J4jCBb6eGEPK8dEgk6gvkF90Mfp0Mf9pyajJ59pXB1UGF8Jf2LNe3bQOLfIOcwgGc0ZNxm4Hpiz9IIrIC0GomQ96O56OScCm6onX0fL0SeifMA2M2u8XEipWB7EGJKuAkdP0XtY2A7S8vS45
> http://plantuml.com/plantuml/png/oyjFILLmLAZcKb18B2h9J4jCBb6eGEPK8dEgk6gvkF90Mfp0Mf9pyajJ59n1eeuAkhfs2avS
> Version 8024 that you are using is a bit old : could you upgrade to
> last version ?
This is the version currently packaged in Debian. I'm adding this information
to the existing bugreport signaling
a more recent version, and raising its severity
> 2016-04-21 0:08 GMT+02:00 < ydir...@free.fr > :
> > And another one, similar but apparently triggered by more complex
> > structure
>
> > @startuml
>
> > node A {
>
> > artifact x
>
> > artifact y
>
> > artifact z
>
> > }
>
> > node B {
>
> > cloud C
>
> > cloud D
>
> > }
>
> > cloud I
>
> > node G {
>
> > frame aa
>
> > }
>
> > node H {
>
> > folder 1
>
> > node 2 {
>
> > frame 3
>
> > node 4 {
>
> > artifact 5
>
> > }
>
> > }
>
> > frame 6
>
> > frame 7
>
> > }
>
> > B -> I
>
> > I -> G
>
> > I -> H
>
> > @enduml
>
Bug#822092: Acknowledgement (plantuml: debian/copyright lacks source info)
Also, upstream email and other fields could be filled - Mail original - > De: "Debian Bug Tracking System" > À: ydir...@free.fr > Envoyé: Jeudi 21 Avril 2016 10:15:05 > Objet: Bug#822092: Acknowledgement (plantuml: debian/copyright lacks source > info) > > Thank you for filing a new Bug report with Debian. > > This is an automatically generated reply to let you know your message > has been received. > > Your message is being forwarded to the package maintainers and other > interested parties for their attention; they will reply in due > course. > > Your message has been sent to the package maintainer(s): > Andrew Shadura > > If you wish to submit further information on this problem, please > send it to 822...@bugs.debian.org. > > Please do not send mail to ow...@bugs.debian.org unless you wish > to report a problem with the Bug-tracking system. > > -- > 822092: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822092 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems >
Bug#822094: plantuml: please add watch file
Package: plantuml Version: 8024-2 Tags: patch Here is a debian/watch so the PTS will be able to warn when a new version is out: version=4 http://sf.net/plantuml/ plantuml-(.+)\.tar\.gz debian
Bug#822094: Acknowledgement (plantuml: please add watch file)
In fact my first version matches an unwanted source, this one should be used instead: version=4 http://sf.net/plantuml/ plantuml-([\d.]+)\.tar\.gz debian
Bug#816501: plantuml failure on deployment diag
I confirm that version 8038 works. Packaging a new version was just trivial :)
Andrew, if you don't object, I can NMU the new version together with fixes for
the other problems,
and setup a collab-maint git repo for easier collaboration.
Best regards,
Yann
- Mail original -
> De: ydir...@free.fr
> À: "PlantUML PlantUML"
> Cc: 816...@bugs.debian.org, cont...@bugs.debian.org
> Envoyé: Jeudi 21 Avril 2016 10:17:52
> Objet: Re: plantuml failure on deployment diag
> severity 816501 important
> thanks
> Hi Arnaud,
> Thanks for this quick answer
> - Mail original -
> > Your examples work fine with last version of PlantUML:
>
> > http://plantuml.com/plantuml/png/oyjFILLmLAZcKb18B2h9J4jCBb6eGEPK8dEgk6gvkF90Mfp0Mf9pyajJ59pXB1UGF8Jf2LNe3bQOLfIOcwgGc0ZNxm4Hpiz9IIrIC0GomQ96O56OScCm6onX0fL0SeifMA2M2u8XEipWB7EGJKuAkdP0XtY2A7S8vS45
>
> > http://plantuml.com/plantuml/png/oyjFILLmLAZcKb18B2h9J4jCBb6eGEPK8dEgk6gvkF90Mfp0Mf9pyajJ59n1eeuAkhfs2avS
>
> > Version 8024 that you are using is a bit old : could you upgrade to
> > last version ?
>
> This is the version currently packaged in Debian. I'm adding this
> information to the existing bugreport signaling
> a more recent version, and raising its severity
> > 2016-04-21 0:08 GMT+02:00 < ydir...@free.fr > :
>
> > > And another one, similar but apparently triggered by more complex
> > > structure
> >
>
> > > @startuml
> >
>
> > > node A {
> >
>
> > > artifact x
> >
>
> > > artifact y
> >
>
> > > artifact z
> >
>
> > > }
> >
>
> > > node B {
> >
>
> > > cloud C
> >
>
> > > cloud D
> >
>
> > > }
> >
>
> > > cloud I
> >
>
> > > node G {
> >
>
> > > frame aa
> >
>
> > > }
> >
>
> > > node H {
> >
>
> > > folder 1
> >
>
> > > node 2 {
> >
>
> > > frame 3
> >
>
> > > node 4 {
> >
>
> > > artifact 5
> >
>
> > > }
> >
>
> > > }
> >
>
> > > frame 6
> >
>
> > > frame 7
> >
>
> > > }
> >
>
> > > B -> I
> >
>
> > > I -> G
> >
>
> > > I -> H
> >
>
> > > @enduml
> >
>
Bug#816501: plantuml failure on deployment diag
Ah, I used plantuml-8038.tar.gz here, tha may explain the difference :) - Mail original - > De: "PlantUML PlantUML" > À: "Andrew Shadura" > Cc: ydir...@free.fr, 816...@bugs.debian.org > Envoyé: Jeudi 21 Avril 2016 11:52:03 > Objet: Re: Bug#816501: plantuml failure on deployment diag > Hi, > The problem may be on our side: file plantuml-mit-8038.tar.gz may be > buggy (some files may be missing). > The GIT repository should be OK, but it's the GPL version. Don't know > if it's fine for you. > Regards, > Arnaud Roques > 2016-04-21 11:46 GMT+02:00 Andrew Shadura < and...@shadura.me > : > > On 21 April 2016 at 10:49, < ydir...@free.fr > wrote: > > > > I confirm that version 8038 works. Packaging a new version was > > > just > > > trivial > > > > :) > > > It failed to build from source for me, strangely enough. > > > > Andrew, if you don't object, I can NMU the new version together > > > with fixes > > > > for the other problems, > > > > and setup a collab-maint git repo for easier collaboration. > > > There's a git repository already. If you manage to make it build, > > > please go ahead and commit your stuff, I'll review and upload it > > > later. > > > I used plantuml-mit-8038.tar.gz. > > > -- > > > Cheers, > > > Andrew >
Bug#820428: lxc2 still broken
Just hit the same problem. The only solution/workaround mentionned here seems removing from the host two packages that are recommended by lxc, without a pointer to an external bugreport it the problem is not in Debian. I must say I'm quite puzzled. Can someone please give some more info, so people hitting this problem can get a clue ?
Bug#822172: pjproject: please package examples
Package: pjproject Version: 2.4.5~dfsg-4 Severity: wishlist pjsip-apps/src contains a couple of example apps (vidui, pygui, ...). It would be great to have them available as examples in the relevant dev package.
Bug#822172: Acknowledgement (pjproject: please package examples)
pygui does not seem uptodate (importing pjsua2 while the package builds pjsua). I was able to build vidgui (which is referenced from official wiki at http://trac.pjsip.org/repos/wiki/Video_Users_Guide) by: * building the package from source first (else qmake complains not to find toplevel build.mak, not sure how that can be handled in the package (providing a prebuilt binary would not help to experiment by changing the code). Copying the toplevel *.mak to the example dir and editing the example's include ? * even then I had to rereun the ld command after adding -lSDL2 -lX11
Bug#822264: plantuml: pdf generation requires batik
Package: plantuml Version: 8024-2 "plantuml -tpdf" fails with: java.lang.ClassNotFoundException: org.apache.batik.apps.rasterizer.SVGConverter I've tried to install libbatik-java, but it did not help.
Bug#822457: libjgraph-java: upstream URLs are broken
Package: libjgraph-java Version: 5.12.4.2+dfsg-2 Homepage from control file http://www.jgraph.com/ points to a site only providing commercial software. URL from copyright file redirects to jgraphx github repo, which is apparently something different.
Bug#822458: libjgraphx-java: new version and new upstream URL
Package: libjgraphx-java Version: 2.1.0.7-1 Homepage from control file and copyright file redirects to jgraphx github repo, which is at v3.5.1.2.
Bug#822665: bumblebee: reports wrong error message from Xorg log
Package: bumblebee Version: 3.2.1-10 When trying to use bumblebee those days, the reported failure is: $ optirun xterm [42519.843834] [ERROR]Cannot access secondary GPU - error: [XORG] (EE) /dev/dri/card0: failed to set DRM interface version 1.4: Permission denied [42519.843864] [ERROR]Aborting because fallback start is disabled. $ Looking in Xorg.8.log, we can see: [ 42519.553] (II) xfree86: Adding drm device (/dev/dri/card1) [ 42519.840] (II) xfree86: Adding drm device (/dev/dri/card0) [ 42519.840] (EE) /dev/dri/card0: failed to set DRM interface version 1.4: Permission denied [ 42519.841] (--) PCI:*(0:1:0:0) 10de:139b:1462:1139 rev 162, Mem @ 0xa200/16777216, 0xc000/268435456, 0xd000/33554432, I/O @ 0x4000/128, BIOS @ 0x/524288 ... [ 42519.843] (II) [drm] nouveau interface version: 1.3.1 [ 42519.843] (EE) Unknown chipset: NV117 [ 42519.843] (EE) No devices detected. [ 42519.843] (EE) Fatal server error: [ 42519.843] (EE) no screens found(EE) The "permission denied" is quite strange, as the device does have the ACL allowing RW for the current user. But anyway that card is already used by :0, could it be that the error code returned by the DRI device is just wrong (EPERM instead of EBUSY) ? Anyway, that error does not appear to be fatal to Xorg, which does list the second one as fatal, and incidentally that error message looks like a much more understandable reason
Bug#822665: bumblebee: reports wrong error message from Xorg log
No I just reported it to the bts as I saw it - Mail original - > De: "Luca Boccassi" > À: ydir...@free.fr, 822...@bugs.debian.org > Envoyé: Mardi 26 Avril 2016 11:28:29 > Objet: Re: Bug#822665: bumblebee: reports wrong error message from Xorg log > > Control: tags -1 upstream > > On Tue, 2016-04-26 at 10:17 +0200, ydir...@free.fr wrote: > > Package: bumblebee > > Version: 3.2.1-10 > > > > When trying to use bumblebee those days, the reported failure is: > > > > $ optirun xterm > > [42519.843834] [ERROR]Cannot access secondary GPU - error: [XORG] > > (EE) /dev/dri/card0: failed to set DRM interface version 1.4: > > Permission denied > > > > [42519.843864] [ERROR]Aborting because fallback start is disabled. > > $ > > > > Looking in Xorg.8.log, we can see: > > > > [ 42519.553] (II) xfree86: Adding drm device (/dev/dri/card1) > > [ 42519.840] (II) xfree86: Adding drm device (/dev/dri/card0) > > [ 42519.840] (EE) /dev/dri/card0: failed to set DRM interface > > version 1.4: Permission denied > > [ 42519.841] (--) PCI:*(0:1:0:0) 10de:139b:1462:1139 rev 162, Mem @ > > 0xa200/16777216, 0xc000/268435456, 0xd000/33554432, > > I/O @ 0x4000/128, BIOS @ 0x/524288 > > ... > > [ 42519.843] (II) [drm] nouveau interface version: 1.3.1 > > [ 42519.843] (EE) Unknown chipset: NV117 > > [ 42519.843] (EE) No devices detected. > > [ 42519.843] (EE) > > Fatal server error: > > [ 42519.843] (EE) no screens found(EE) > > > > The "permission denied" is quite strange, as the device does have > > the ACL allowing RW for the current user. > > But anyway that card is already used by :0, could it be that the > > error code returned by the DRI device is > > just wrong (EPERM instead of EBUSY) ? > > > > Anyway, that error does not appear to be fatal to Xorg, which does > > list the second one as fatal, > > and incidentally that error message looks like a much more > > understandable reason > > Hi, > > Yes unfortunately very often bumblebee errors are a bit misleading or > hard to interpret :-( > Have you reported this upstream? > > Kind regards, > Luca Boccassi >
Bug#787658: aptitude ignores available updates for a while after downgrades
Same here, it looks like only updating the package list again will bring those packages back into the "Upgradable" set. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#788525: git-remote-https segfault involving libgnutls
Package: libgnutls-deb0-28 Version: 3.3.15-5 Severity: grave Justification: breaks other package In my setup, a simple "git ls-remote https://github.com/irmen/Pyro4.git"; (or any https repo I had) would silently die, with only strace revealing git-remote-https segfaulting. gdb shows: Reading symbols from /usr/lib/git-core/git-remote-https...(no debugging symbols found)...done. [New LWP 26284] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/i386-linux-gnu/i686/cmov/libthread_db.so.1". Core was generated by `git-remote-https origin https://github.com/irmen/Pyro4.git'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0xb73e2788 in nettle_yarrow256_update () from /usr/lib/i386-linux-gnu/libnettle.so.4 (gdb) bt #0 0xb73e2788 in nettle_yarrow256_update () from /usr/lib/i386-linux-gnu/libnettle.so.4 #1 0xb7356641 in do_device_source (init=, event=0xbfadc770, ctx=0xb73becc0 ) at rnd.c:147 #2 0xb7356804 in wrap_nettle_rnd_init (ctx=0xb73beedc ) at rnd.c:241 #3 0xb72bf3e6 in _gnutls_rnd_init () at random.c:49 #4 0xb72b2d6d in gnutls_global_init () at gnutls_global.c:272 #5 0xb7293534 in lib_init () at gnutls_global.c:434 #6 0xb77d086e in call_init (l=, argc=argc@entry=3, argv=argv@entry=0xbfadc8e4, env=env@entry=0xbfadc8f4) at dl-init.c:78 #7 0xb77d0964 in call_init (env=0xbfadc8f4, argv=0xbfadc8e4, argc=3, l=) at dl-init.c:36 #8 _dl_init (main_map=0xb77e2930, argc=3, argv=0xbfadc8e4, env=0xbfadc8f4) at dl-init.c:126 #9 0xb77c2d3f in _dl_start_user () from /lib/ld-linux.so.2 (gdb) info threads Id Target Id Frame * 1Thread 0xb6e2c700 (LWP 26284) 0xb73e2788 in nettle_yarrow256_update () from /usr/lib/i386-linux-gnu/libnettle.so.4 (gdb) ... and when I downgrade to 3.3.8-6+deb8u1 from stable, the segfault does away. Anything to do with that nettle transition that should only affect unstable ? My testing install doesn't seem to have any stuff from unstable related to that... -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#788527: pyro4: new upstream available
Source: pyro4 Version: 4.23-2 Severity: normal Dear Maintainer, The version in sid is quite old now, and the online docs describe very useful features... that are simply not available in that old version. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#806168: gst-plugins-bad1.0: please ship gst-element-maker
Package: gst-plugins-bad1.0 Version: 1.6.1-1 http://gstreamer.freedesktop.org/data/doc/gstreamer/head/pwg/html/section-boiler-project-stamp.html states that "for creating elements the tool gst-element-maker from gst-plugins-bad is recommended these days". Today it seems it only appears in the source package, it would look like a good idea to ship it as part of the -dev package.
Bug#806546: repo: no doc nor link to doc
Package: repo Version: 1.12.22-1 Severity: wishlist Since there is apparently no doc shipped aside from "repo help", a link to upstream doc ought to be provided, in a README.Debian or in a manpage.
Bug#806792: gst-rtsp-server1.0: please ship examples directory
Package: gst-rtsp-server1.0 Version: 1.6.1-1 Severity: wishlist Starting with this package without an example is not easy, and there are examples in the source tree - please consider shipping them.
Bug#643997: aptitude: user-requested downgrade should not cause (so much of a) downgrade penalty for conflict resolution
Hi Manuel,
- Mail original -
> >The "downgrade" use-case surely needs some love those days thanks to
> >the moz foundation: I rapidly had a test of iceweasel 7 in unstable
> >(eager to get better ram usage ;), just to conclude that so many
> >extensions are not compatible.
> >
> >So let's try to get back to v6... iceweasel-dbg has a scrict dep,
> >what
> >are the first suggestions from aptitude ? Each of them summarized
> >below, one per paragraph.
> >
> >I originally thought it was just a problem of "downgrade" being
> >rated
> >too bad - and incidentally, when asked to explicitely downgrade,
> >aptitude should surely not inflict a downgrade-penalty to packages
> >that are broken by the downgrade. But even then, how to explain
> >that
> >version from squeeze is elected first, then version from
> >moz.d.n/wheezy, and that just downgrading -dbg to wheezy itself is
> >not
> >even ever considerered, whereas the priority of those packages is
> >highest ?
>
> From apt_preferences man page:
>
>APT then applies the following rules, listed in order of
>precedence, to determine which version of a package to
>install.
>
>· Never downgrade unless the priority of an available version
> exceeds 1000. ("Downgrading" is installing a less recent
> version of a package in place of a more recent version. Note
> that none of APT's default priorities exceeds 1000; such
> high
> priorities can only be set in the preferences file. Note
> also
> that downgrading a package can be risky.)
>
> So even if pin priority is higher, since none of them is higher than
> 1000, it's not supposed to facilitate downgrades in any way.
>
>
> More in general, downgrades are not supported, so I don't think that
> it
> should be a goal of aptitude or any other tool making this action
> very
> easy / convenient / appear risk-free by working as seamlessly as new
> installs or upgrades.
I understand, but for this a warning like we already have eg. for removal
of (essential?) packages should be enough.
> >[...]
> > Remove the following packages:
> >1) iceweasel-dbg
> >
> > Keep the following packages at their current version:
> >1) iceweasel [7.0.1-1 (now, unstable)]
> >
> > Upgrade the following packages:
> >5) iceweasel [7.0.1-1 (now, unstable) -> 8.0~b1-1
> >(experimental)]
> >
> > Downgrade the following packages:
> >6) iceweasel [7.0.1-1 (now, unstable) -> 3.5.16-6 (stable)]
> >
> >[here after a number of combinations involving downgrade to 3.5, I
> >had
> >to reject that line manually]
> >
> > Downgrade the following packages:
> >5) iceweasel [7.0.1-1 (now, unstable) -> 3.6.23-1 (wheezy)]
> >
> >then the dreaded...
> >
> >open: 5318; closed: 48906; defer: 141; conflict: 187
> >No solution found within the allotted time. Try harder? [Y/n]
> >open: 10316; closed: 72787; defer: 141; conflict: 187
> >No solution found within the allotted time. Try harder? [Y/n]
>
> Perhaps you can try the interactive resolver, it is quite useful in
> any
> situation where the resolver gets stuck and one wants to guide the
> resolution to a quick end.
I *am* using the interactive resolver all the time, it's just that it's
much harder to use demonstratively for a bugreport :)
And even interactively, having to explicitly refuse *several times* suggestions
that are *contrary* to what the user asked is still frustrating, and just does
not feel right.
Thinking about it with pinning in mind, maybe it would just be worth and
sufficient to use a large priority to versions explicitly requested by the user,
together with a bold "you're going to downgrade packages, to your own risk"
warning ?
Bug#643997: aptitude: user-requested downgrade should not cause (so much of a) downgrade penalty for conflict resolution
- Mail original -
> De: "Manuel A. Fernandez Montecelo"
> À: "Yann Dirson"
> Cc: 643...@bugs.debian.org
> Envoyé: Lundi 7 Décembre 2015 17:30:46
> Objet: Re: aptitude: user-requested downgrade should not cause (so much of a)
> downgrade penalty for conflict
> resolution
>
> 2015-12-07 15:17 GMT+00:00 :
> > Hi Manuel,
> >
> > - Mail original -
> >> >The "downgrade" use-case surely needs some love those days thanks
> >> >to
> >> >the moz foundation: I rapidly had a test of iceweasel 7 in
> >> >unstable
> >> >(eager to get better ram usage ;), just to conclude that so many
> >> >extensions are not compatible.
> >> >
> >> >So let's try to get back to v6... iceweasel-dbg has a scrict dep,
> >> >what
> >> >are the first suggestions from aptitude ? Each of them
> >> >summarized
> >> >below, one per paragraph.
> >> >
> >> >I originally thought it was just a problem of "downgrade" being
> >> >rated
> >> >too bad - and incidentally, when asked to explicitely downgrade,
> >> >aptitude should surely not inflict a downgrade-penalty to
> >> >packages
> >> >that are broken by the downgrade. But even then, how to explain
> >> >that
> >> >version from squeeze is elected first, then version from
> >> >moz.d.n/wheezy, and that just downgrading -dbg to wheezy itself
> >> >is
> >> >not
> >> >even ever considerered, whereas the priority of those packages is
> >> >highest ?
> >>
> >> From apt_preferences man page:
> >>
> >>APT then applies the following rules, listed in order of
> >>precedence, to determine which version of a package to
> >>install.
> >>
> >>· Never downgrade unless the priority of an available
> >>version
> >> exceeds 1000. ("Downgrading" is installing a less recent
> >> version of a package in place of a more recent version.
> >> Note
> >> that none of APT's default priorities exceeds 1000; such
> >> high
> >> priorities can only be set in the preferences file. Note
> >> also
> >> that downgrading a package can be risky.)
> >>
> >> So even if pin priority is higher, since none of them is higher
> >> than
> >> 1000, it's not supposed to facilitate downgrades in any way.
> >>
> >>
> >> More in general, downgrades are not supported, so I don't think
> >> that
> >> it
> >> should be a goal of aptitude or any other tool making this action
> >> very
> >> easy / convenient / appear risk-free by working as seamlessly as
> >> new
> >> installs or upgrades.
> >
> > I understand, but for this a warning like we already have eg. for
> > removal
> > of (essential?) packages should be enough.
> >
> >
> >> >[...]
> >> > Remove the following packages:
> >> >1) iceweasel-dbg
> >> >
> >> > Keep the following packages at their current version:
> >> >1) iceweasel [7.0.1-1 (now, unstable)]
> >> >
> >> > Upgrade the following packages:
> >> >5) iceweasel [7.0.1-1 (now, unstable) -> 8.0~b1-1
> >> >(experimental)]
> >> >
> >> > Downgrade the following packages:
> >> >6) iceweasel [7.0.1-1 (now, unstable) -> 3.5.16-6 (stable)]
> >> >
> >> >[here after a number of combinations involving downgrade to 3.5,
> >> >I
> >> >had
> >> >to reject that line manually]
> >> >
> >> > Downgrade the following packages:
> >> >5) iceweasel [7.0.1-1 (now, unstable) -> 3.6.23-1 (wheezy)]
> >> >
> >> >then the dreaded...
> >> >
> >> >open: 5318; closed: 48906; defer: 141; conflict: 187
> >> >No solution found within the allotted time. Try harder? [Y/n]
> >> >open: 10316; closed: 72787; defer: 141; conflict: 187
> >> >No solution found within the allotted time. Try harder? [Y/n]
> >>
> >> Perhaps you can try the interactive resolver, it is quite useful
> >> in
> >> any
> >> situation where the resolver gets stuck and one wants to guide the
> >> resolution to a quick end.
> >
> > I *am* using the interactive resolver all the time, it's just that
> > it's
> > much harder to use demonstratively for a bugreport :)
>
> Yes, that's true.
>
>
> > And even interactively, having to explicitly refuse *several times*
> > suggestions
> > that are *contrary* to what the user asked is still frustrating,
> > and just does
> > not feel right.
>
> Are you using R and A to accept or reject individual package
> solutions? That should help in this case, to avoid repeatedly
> getting
> suggestions that you don't want to accept.
Yes I do. But I still have to individually refuse all "upgrade" and
"keep" suggestions, which all come with higher priority than the very
downgrade I had requested. The typical case is that of a machine running
on "testing" (or even on "stable"), with sources.list entries for "unstable",
"experimental", (or "backports", "security" etc for "stable" boxes), etc to
facilitate targeted installation of newer versions when they are needed.
>
> > Thinking about it with pinning in mind, maybe it would just be
> > worth and
> > sufficient to use a large priority to versions e
Bug#643997: aptitude: user-requested downgrade should not cause (so much of a) downgrade penalty for conflict resolution
> 2011-10-01 15:59 Yann Dirson:
> >Package: aptitude
> >Version: 0.6.3-4
> >Severity: normal
> >
> >The "downgrade" use-case surely needs some love those days thanks to
> >the moz foundation: I rapidly had a test of iceweasel 7 in unstable
> >(eager to get better ram usage ;), just to conclude that so many
> >extensions are not compatible.
> >
> >So let's try to get back to v6... iceweasel-dbg has a scrict dep,
> >what
> >are the first suggestions from aptitude ? Each of them summarized
> >below, one per paragraph.
> >
> >I originally thought it was just a problem of "downgrade" being
> >rated
> >too bad - and incidentally, when asked to explicitely downgrade,
> >aptitude should surely not inflict a downgrade-penalty to packages
> >that are broken by the downgrade. But even then, how to explain
> >that
> >version from squeeze is elected first, then version from
> >moz.d.n/wheezy, and that just downgrading -dbg to wheezy itself is
> >not
> >even ever considerered, whereas the priority of those packages is
> >highest ?
>
> From apt_preferences man page:
>
>APT then applies the following rules, listed in order of
>precedence, to determine which version of a package to
>install.
>
>· Never downgrade unless the priority of an available version
> exceeds 1000. ("Downgrading" is installing a less recent
> version of a package in place of a more recent version. Note
> that none of APT's default priorities exceeds 1000; such
> high
> priorities can only be set in the preferences file. Note
> also
> that downgrading a package can be risky.)
>
> So even if pin priority is higher, since none of them is higher than
> 1000, it's not supposed to facilitate downgrades in any way.
>
>
> More in general, downgrades are not supported, so I don't think that
> it
> should be a goal of aptitude or any other tool making this action
> very
> easy / convenient / appear risk-free by working as seamlessly as new
> installs or upgrades.
Just seen a situation which would not have astonished me, were it not for
this clarification about pinning: on a mostly-testing machine, where upgrading
tulip to new 4.8.0 from unstable (I had a pre-upload locally-built version of
that package installed, with same version string, but I'm not sure that makes
any difference) pulls binutils from unstable, breaking a couple of
binutils-related versionned deps:
* the first suggestion is to remove tulip (the same kind of choice which puzzles
me with downgrade: it has been marked for upgrade, why on earth is the *first*
suggestion to do anything else than what was asked)
* then after I refused this choice for tulip, the next suggestion is to keep the
currently installed version (same remark)
* then the next one is to upgrade binutils (and -dev and -multiarch), which is
what I would have expected at first, BUT at the same time to DOWNGRADE
binutils-arm-linux-gnueabi to the version in "stable"
* refusing that downgrade it finally proposes to upgrade the latter to unstable
as well
That's the kind of situation to which I am routinely subject, and to which
unfortunately I usually don't pay that much attention any more. But your
remark about pinning being the mechanism getting in the way of voluntary
downgrades, which perfectly made sense at the time, now confuses me, as I
don't see how it could cause a downgrade to be prefered to an upgrade.
Maybe the reason is linked to the identical score of 500 reported
by apt-cache policy ?
Bug#802575: ikiwiki: missing dependency
Package: ikiwiki Version: 3.20141016.2 ikiwiki --setup /etc/ikiwiki/auto.setup * [new branch] master -> master Directory /home/wiki/O-Computersinternal is now a clone of git repository /home/wiki/O-Computersinternal.git Can't locate Date/Parse.pm in @INC (you may need to install the Date::Parse module) (@INC contains: /home/wiki/.ikiwiki /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.20.2 /usr/local/share/perl/5.20.2 /usr/lib/x86_64-linux-gnu/perl5/5.20 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.20 /usr/share/perl/5.20 /usr/local/lib/site_perl .) at (eval 116) line 2. BEGIN failed--compilation aborted at (eval 116) line 2. /etc/ikiwiki/auto.setup: ikiwiki --refresh --setup /home/wiki/O-Computersinternal.setup failed at /usr/share/perl5/IkiWiki/Setup/Automator.pm line 150.
Bug#802576: ikiwiki: history confuses admin name for wiki name
Package: ikiwiki Version: 3.20141016.2 When re-running "ikiwiki --setup /etc/ikiwiki/auto.setup", it attemtps to provide as default values those from a a previous run. However, the default value on second run for the wiki name seems to be taken from the admin name instead.
Bug#802575: Acknowledgement (ikiwiki: missing dependency)
In fact, even more packages seem to be necessary just to create a wiki: gcc, python, libc6-dev (ikiwiki.cgi.c needs stdio.h)
Bug#788849: accerciser: unhandled exception in QuickSelect "inspect accessible under mouse" for some widgets
Package: accerciser Version: 3.14.0-1 If eg. I'm inspecting a yelp window, Ctrl-alt-? over a button in the title bar does bring me to the correct item , but over a "next" button inside a help window, I get and exception: Traceback (most recent call last): File "/usr/lib/python3/dist-packages/accerciser/accessible_treeview.py", line 304, in _popOnIdle parent = self[iter][COL_ACC] File "/usr/lib/python3/dist-packages/gi/overrides/Gtk.py", line 1075, in __getitem__ return self.model.get_value(self.iter, key) TypeError: Couldn't find foreign struct converter for 'cairo.Context' Afterwards, the only side-effet I observed thus far is that the mouse pointer over the tree pane is left as "waiting cursor" -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#788849: accerciser: unhandled exception in QuickSelect "inspect accessible under mouse" for some widgets
> Please use reportbug to report bugs, as that gives us some useful information. I do when possible, it was just not an option from here :) > Do you have python3-gi-cairo installed? If not, does it help if you install > it? It was not installed, and installing it does fix the problem, thanks! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#648443: recommend libx11-doc
> libx11-dev is not installed by > default. As far as I'm concerned this is a non-bug. Policy says: `Recommends' This declares a strong, but not absolute, dependency. The `Recommends' field should list packages that would be found together with this one in all but unusual installations. Today it is quite common (and I would argue that it is the most common case) to install -dev packages just to be able to compile some software. Thus it is not unusual at all not to need -doc packages. And in fact the vast majority of Debian packages only has a Suggests: relationship between -dev and -doc packages, including several xorg packages (xcb, xaw...) In the context where Debian gets installed more and more on space-constrained/ embedded platforms, installing it by default is even less relevant.
Bug#803920: firmware-iwlwifi: please include ucode 3160-15
Package: firmware-iwlwifi Version: 20151018-2 This version is advertised as be necessary for kernels 4.2+ (whereas http://www.intel.com/support/fr/wireless/wlan/sb/cs-034398.htm lists already-included 3160-14 to be targeted to 4.2+) It is necessary for and does work for me with 4.3-rc7. https://wireless.wiki.kernel.org/en/users/Drivers/iwlwifi
Bug#803923: razorqt: can read whole text from kerneloops-applet
Package: razorqt, kerneloops-applet Version: 0.5.2-4, 0.12+git20140509-1 Severity: important Under razorqt, various notifications with a long text are truncated, and we can't see the end of the question we're asked. This is seen with eg the question asked after a diag information has been sent, which is followed by a (hidden) question with 3 choices offered. See attachment for a notification screenshot.
Bug#804024: lesspipe: please add support for OpenEmbedded .ipk files
Package: less Version: 458-3 Tags: patch .ipk files are restricted .deb archives for use by opkg, the dpkg-apt-like tool from OpenEmbedded. They just need to be listed in the known .deb suffixes: *.deb|*.udeb|*.ddeb|*.ipk) echo "$1:"; dpkg --info "$1"
Bug#804025: less: new upstream release
Package: less Version: 458-3 Version 481 has recently been released, as ready for general use.
Bug#804662: libsdl2: lacks origtarball filtering instructions
Package: libsdl2 Version: 2.0.2+dfsg1-7 The exact way of turning an upstream tarball into a -dfsg tree is not documented. Having this info would help, eg. when one wants to package a new upstream snapshot.
Bug#742873: Patch for #742873
tags 742873 + patch
thanks
Too bad it's too late for jessie...
>From 18bbc237763955c150da72daf9be2b9702fefb0a Mon Sep 17 00:00:00 2001
From: Yann Dirson
Date: Sat, 15 Nov 2014 16:45:50 +
Subject: [PATCH] Fix CVE-2013-1953
---
debian/changelog | 8
debian/patches/CVE-2013-1953.patch | 11 +++
debian/patches/series | 1 +
3 files changed, 20 insertions(+)
create mode 100644 debian/patches/CVE-2013-1953.patch
diff --git a/debian/changelog b/debian/changelog
index a12c511..42fdfc8 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+autotrace (0.31.1-16+nmu1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Fix buffer overflow (Closes: #742873, CVE-2013-1953), patch from
+https://bugzilla.redhat.com/show_bug.cgi?id=951257.
+
+ -- Yann Dirson Sat, 15 Nov 2014 16:45:25 +0100
+
autotrace (0.31.1-16) unstable; urgency=low
* Bumped Standards-Version to 3.9.2
diff --git a/debian/patches/CVE-2013-1953.patch
b/debian/patches/CVE-2013-1953.patch
new file mode 100644
index 000..bcf12f6
--- /dev/null
+++ b/debian/patches/CVE-2013-1953.patch
@@ -0,0 +1,11 @@
+--- autotrace-0.31.1/input-bmp.c.orig 2002-10-10 22:44:08.0 +0200
autotrace-0.31.1/input-bmp.c.orig 2013-06-28 10:24:58.336056959 +0200
+@@ -166,7 +166,7 @@ input_bmp_reader (at_string filename,
+ /* 36 */
+ Maps = 4;
+ }
+- else if (Bitmap_File_Head.biSize <= 64) /* Probably OS/2 2.x */
++ else if (Bitmap_File_Head.biSize >= 40 && Bitmap_File_Head.biSize <= 64) /*
Probably OS/2 2.x */
+ {
+ if (!ReadOK (fd, buffer, Bitmap_File_Head.biSize - 4))
+ {
diff --git a/debian/patches/series b/debian/patches/series
index cb1473f..f559677 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -10,3 +10,4 @@ output-pdf.c.patch
output-pstoedit.c.patch
output-pstoedit.h.patch
README.patch
+CVE-2013-1953.patch
--
2.1.3
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#813051: flashgot: should better advertize audio streaming capabilities
Package: xul-ext-flashgot Version: 1.5.6.12+dfsg-1 Severity: wishlist As described on [1] flashgot is able to expose audio-only streams for eg. youtube videos, and to feed them to media players for streaming. The package description would gain from getting the feature mentioned (I knew about that package, and was surprised to see it appear as solution in my search results), and the package itself would gain by having relevant audio players ((s)mplayer as mentioned in [2]) declared so they become automatically selectable when installed. [1] http://askubuntu.com/questions/54379/vlc-for-flash-video/169410#169410 [2] http://stackoverflow.com/a/32613680
Bug#810320: pitivi: manpage is wrong
Package: pitivi Version: 0.95-1 Manpage mentions interesting options such as --import, but those seem not to exist in this version.
Bug#567576: patch
tags 567576 + patch thanks Puzzled to hit this bug (in the GUI version), while there seems to be a patch around since 2012
Bug#818232: Acknowledgement (qgo: Unable to type via VNC, keys not matching)
reassign -1 libqt5gui5 thanks Sounds like a good idea, thanks for your investigation :) - Mail original - > De: "Linus Lüssing" > À: 818...@bugs.debian.org > Envoyé: Mardi 22 Mars 2016 10:53:56 > Objet: Bug#818232: Acknowledgement (qgo: Unable to type via VNC, keys not > matching) > > Okay, happens with other Qt5 applications, like musescore, dolphin > or ktimer, too. Qt4 applications are unaffected (for instance > mumble). > > This report should probably be moved to libqt5gui5 then? >
Bug#816451: icedtea-netx: requires jre8 but still alternatively depends on jre7
Package: icedtea-netx Version: 1.6.2-2 Severity: serious On upgrade, jre8 is not pulled, as existing jre7 fulfills the "openjdk-8-jre | openjdk-7-jre" dependency
Bug#817255: cleancss: depends on material in /usr/share/doc
Package: cleancss
Version: 1.0.12-1
Severity: serious
Removing /usr/share/doc should be allowed, as per policy 12.3.
but:
var packageConfig =
fs.readFileSync('/usr/share/doc/node-clean-css/package.json');
Bug#817907: libcrcutil-doc: advertises non-existant header as main entry point
Package: libcrcutil-doc Version: 1.0-3 README.gz says: use "interface.h" which hides all the details of the implementation. ... but there is no such header in -dev Additionally, the README also says: Please see "usage.cc" which provides an example how to use crcutil_interface::CRC class. ... which hints that the doc package should include examples
Bug#809767: videoob: failure to download from arte+7
Package: weboob
Version: 1.0-3
(at least some of) the arte+7 videos do not download - the relevant wget
commandline is unfortunately not reported even in debug mode:
videoob> backends only arte
videoob> search requin
1 — Dans le sillage des requins (4/4) : Au-delà des apparences (arte)
0:43:11 (0/Not available)
2 — Dans le sillage des requins (3/4) : Les coulisses d'un tournage (arte)
0:43:05 (0/Not available)
3 — Dans le sillage des requins (2/4) : La vie secrète (arte)
0:43:13 (0/Not available)
4 — Dans le sillage des requins (1/4) : Les prédateurs (arte)
0:42:50 (0/Not available)
videoob:/search> info 4
id: 051893-001_PLUS7-F@arte
title: Dans le sillage des requins (1/4) : Les prédateurs
url:
http://artehls-vh.akamaihd.net/i/am/tvguide/default/051893-001-A_2_VF-STF_AMM-Tvguide_XQ.7382511.smil/index_3_av.m3u8
ext: m3u8
description: Filmée sous la banquise, dans des mangroves, des épaves ou des
récifs de corail, une série référence sur les requins qui dévoile leur immense
diversité à travers le monde. Dans cet épisode, une séance de chasse d'un
groupe de grands requins blancs filmée sous l'eau, dans les airs et au ralenti.
rating: 0
nsfw: False
thumbnail:
http://www.arte.tv/papi/tvguide/images/1524261/W940H530/051893-001-A_weltderhaie1_03-1449795008399.jpg
duration: 0:42:50
videoob:/search> logging debug
videoob:/search> download 4
2016-01-03 20:55:40,639:DEBUG:backend.arte:1.0:backend.py:422:fillobj Fill
with fields: ['url']
2016-01-03 20:55:40,641:DEBUG:backend.arte.browser:1.0:browser.py:235:openurl
Opening URL
"('http://arte.tv/papi/tvguide/videos/stream/F/051893-001_PLUS7-F/M3U8/ALL.json',)",
{}
2016-01-03 20:55:40,772:DEBUG:backend.arte.browser:1.0:browser.py:235:openurl
Opening URL
"('http://artehls-vh.akamaihd.net/i/am/tvguide/default/051893-001-A_2_VF-STF_AMM-Tvguide_XQ.7382511.smil/master.m3u8',)",
{}
2016-01-03
20:55:40,908:INFO:requests.packages.urllib3.connectionpool:1.0:connectionpool.py:207:_new_conn
Starting new HTTP connection (1): artehls-vh.akamaihd.net
2016-01-03
20:55:40,976:DEBUG:requests.packages.urllib3.connectionpool:1.0:connectionpool.py:387:_make_request
"GET
/i/am/tvguide/default/051893-001-A_2_VF-STF_AMM-Tvguide_XQ.7382511.smil/index_3_av.m3u8
HTTP/1.1" 200 35374
wget: missing URL
Usage: wget [OPTION]... [URL]...
Try `wget --help' for more options.
Bug#872223: tex-common: fails to configure, fmtutils reports errors about missing files
Package: tex-common Version: 6.07 I'll spare you the full logs, the end seems to make things quite clear: fmtutil [INFO]: /var/lib/texmf/web2c/luatex/dviluatex.fmt installed. fmtutil [WARNING]: inifile xmltex.ini for xmltex/pdftex not found. fmtutil [WARNING]: inifile jadetex.ini for jadetex/pdftex not found. fmtutil [WARNING]: inifile pdfjadetex.ini for pdfjadetex/pdftex not found. fmtutil [WARNING]: inifile pdfxmltex.ini for pdfxmltex/pdftex not found. fmtutil [INFO]: Disabled formats: 3 fmtutil [INFO]: Successfully rebuilt formats: 15 fmtutil [INFO]: Failed to build: 4 (pdftex/xmltex pdftex/jadetex pdftex/pdfjadetex pdftex/pdfxmltex) fmtutil [INFO]: Total formats: 22 fmtutil [INFO]: exiting with status 4 This box is mostly-stretch with a number of packages from buster, so it may just be some dependency missing after the move of those packages into texlive-htmlxml. I have texlive-htmlxml 2017.20170808-1 from stretch here. If it is what tex-common dislikes, it probably needs a Conflicts declaration ?
Bug#872223: tex-common: fails to configure, fmtutils reports errors about missing files
reassign 872223 dpkg
severity 872223 grave
thanks
Well, probably not a missing Conflicts, as downgrading tex-common to the stretch
version does not fix the problem. Really a problem with missing files that
should
not be missing.
In fact, despite having the package installed, there is no such .ini files on
my system. packages.d.o shows that texlive-htmlxml from stretch should have
them, but for some reason they do not appear on my system:
root@home:~# apt-cache policy texlive-htmlxml
texlive-htmlxml:
Installed: 2016.20170123-5
Candidate: 2016.20170123-5
Version table:
2017.20170808-1 900
500 ftp://ftp.debian.org/debian unstable/main amd64 Packages
500 ftp://ftp.debian.org/debian unstable/main i386 Packages
900 ftp://ftp.debian.org/debian testing/main amd64 Packages
900 ftp://ftp.debian.org/debian testing/main i386 Packages
*** 2016.20170123-5 990
990 ftp://ftp.debian.org/debian stretch/main amd64 Packages
990 ftp://ftp.debian.org/debian stretch/main i386 Packages
100 /var/lib/dpkg/status
root@home:~# grep jadetex /var/lib/dpkg/info/texlive-htmlxml.list
/usr/share/doc/texlive-doc/otherformats/jadetex
/usr/share/doc/texlive-doc/otherformats/jadetex/base
/usr/share/texlive/texmf-dist/tex/jadetex
/usr/share/texlive/texmf-dist/tex/jadetex/base
root@home:~# cp /var/lib/dpkg/info/texlive-htmlxml.list /tmp
root@home:~# aptitude reinstall texlive-htmlxml
... and then the configuration fails with another missing file:
! LaTeX Error: File `ulem.sty' not found.
Type X to quit or to proceed,
or enter new name. (Default extension: sty)
Enter file name:
! Emergency stop.
l.27 \RequirePackage
{fancyhdr}^^M
! ==> Fatal error occurred, no output PDF file produced!
Transcript written on pdfjadetex.log.
fmtutil [ERROR]: running `pdftex -ini -jobname=jadetex -progname=jadetex
*jadetex.ini
2017-08-01 11:00:49 status half-configured tex-common:all 6.07
2017-08-01 11:00:50 status installed tex-common:all 6.07
...
2017-08-01 23:32:55 configure texlive-generic-recommended:all 2016.20170123-5
2017-08-01 23:32:55 status unpacked texlive-generic-recommended:all
2016.20170123-5
2017-08-01 23:32:55 status half-configured texlive-generic-recommended:all
2016.20170123-5
2017-08-01 23:32:55 status installed texlive-generic-recommended:all
2016.20170123-5
...
2017-08-01 23:32:58 configure texlive-htmlxml:all 2016.20170123-5
2017-08-01 23:32:58 status unpacked texlive-htmlxml:all 2016.20170123-5
2017-08-01 23:32:58 status half-configured texlive-htmlxml:all 2016.20170123-5
2017-08-01 23:32:58 status installed texlive-htmlxml:all 2016.20170123-5
...
2017-08-01 23:35:15 trigproc tex-common:all 6.07
2017-08-01 23:35:15 status half-configured tex-common:all 6.07
2017-08-01 23:35:49 startup packages configure
2017-08-01 23:35:49 configure tex-common:all 6.07
2017-08-01 23:35:49 status half-configured tex-common:all 6.07
-rw-r--r-- 1 root root 2020 Aug 1 10:42
/var/lib/dpkg/info/texlive-generic-recommended.list
Older logs show:
2017-07-14 22:33:44 configure texlive-generic-recommended:all 2017.20170629-1
2017-07-14 22:33:44 status unpacked texlive-generic-recommended:all
2017.20170629-1
2017-07-14 22:33:44 status half-configured texlive-generic-recommended:all
2017.20170629-1
2017-07-14 22:33:44 status installed texlive-generic-recommended:all
2017.20170629-1
...
2017-07-14 23:26:00 configure texlive-htmlxml:all 2017.20170629-1
2017-07-14 23:26:00 status unpacked texlive-htmlxml:all 2017.20170629-1
2017-07-14 23:26:00 status half-configured texlive-htmlxml:all 2017.20170629-1
2017-07-14 23:26:00 status installed texlive-htmlxml:all 2017.20170629-1
...
2017-07-14 23:26:41 trigproc tex-common:all 6.07
2017-07-14 23:26:41 status half-configured tex-common:all 6.07
2017-07-14 23:27:04 status installed tex-common:all 6.07
I know that we do not really support package downgrading, but still, that stuff
really looks like a bad dpkg bug, right ?
A shame we do not git-version all .list files to track down when something goes
wrong like that...
Bug#864825: gammaray: crashes target program on attach
Package: gammaray Version: 2.7.0-1 severity: grave When attaching to any Qt5 or Qt4 process, the target process crashes. Here with a freshly-launched kwrite for demonstration: #0 0x7f21b4fd96ad in poll () at ../sysdeps/unix/syscall-template.S:84 #1 0x7f21af8429f6 in g_main_context_poll (priority=, n_fds=1, fds=0x7f2194003020, timeout=, context=0x7f2194000990) at ././glib/gmain.c:4228 #2 g_main_context_iterate (context=context@entry=0x7f2194000990, block=block@entry=1, dispatch=dispatch@entry=1, self=) at ././glib/gmain.c:3924 #3 0x7f21af842b0c in g_main_context_iteration (context=0x7f2194000990, may_block=1) at ././glib/gmain.c:3990 #4 0x7f21b58ed06b in QEventDispatcherGlib::processEvents(QFlags) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #5 0x7f21b58969ca in QEventLoop::exec(QFlags) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #6 0x7f21b56c40f3 in QThread::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #7 0x7f21b88b26d5 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5DBus.so.5 #8 0x7f21b56c8da8 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #9 0x7f21b151e494 in start_thread (arg=0x7f21a0dfc700) at pthread_create.c:333 #10 0x7f21b4fe2aff in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97 Thread 1 (Thread 0x7f21a5b0a580 (LWP 31110)): [KCrash Handler] #4 0x7f219a2d65b1 in GammaRay::Server::listen() () from /usr/lib/libgammaray_core-qt5_7-x86_64.so.2.7.0 #5 0x7f219a294bd1 in GammaRay::Probe::delayedInit() () from /usr/lib/libgammaray_core-qt5_7-x86_64.so.2.7.0 #6 0x7f21b58c5499 in QObject::event(QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #7 0x7f21b617bb8c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #8 0x7f21b6183341 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #9 0x7f21b58989e0 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #10 0x7f21b589b16d in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #11 0x7f21b58ecc43 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #12 0x7f21af8427f7 in g_main_dispatch (context=0x7f219c0016f0) at ././glib/gmain.c:3203 #13 g_main_context_dispatch (context=context@entry=0x7f219c0016f0) at ././glib/gmain.c:3856 #14 0x7f21af842a60 in g_main_context_iterate (context=context@entry=0x7f219c0016f0, block=block@entry=1, dispatch=dispatch@entry=1, self=) at ././glib/gmain.c:3929 #15 0x7f21af842b0c in g_main_context_iteration (context=0x7f219c0016f0, may_block=1) at ././glib/gmain.c:3990 #16 0x7f21b58ed04f in QEventDispatcherGlib::processEvents(QFlags) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #17 0x7f21b58969ca in QEventLoop::exec(QFlags) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #18 0x7f21b589f13c in QCoreApplication::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #19 0x557eafc8198f in main ()
Bug#864826: gammaray: 2.8.0 is out
Package: gammaray Version: 2.7.0-1 Severity: wishlist https://github.com/KDAB/GammaRay/releases
Bug#861974: libcurl4-openssl-dev multi-architecture incompatibility also affects gnutls version
The same problem happens when trying to install amd64 and i386 versions of the libcurl4-gnutls-dev package.
Bug#873642: weboob-qt: misses dependency on python-pyqt5.qtmultimedia
Package: weboob-qt Version: 1.2-1 Severity: serious without it, qvideoob fails with: $ qvideoob Traceback (most recent call last): File "/usr/bin/qvideoob", line 24, in from weboob.applications.qvideoob import QVideoob File "/usr/lib/python2.7/dist-packages/weboob/applications/qvideoob/__init__.py", line 1, in from .qvideoob import QVideoob File "/usr/lib/python2.7/dist-packages/weboob/applications/qvideoob/qvideoob.py", line 24, in from .main_window import MainWindow File "/usr/lib/python2.7/dist-packages/weboob/applications/qvideoob/main_window.py", line 30, in from .video import Video File "/usr/lib/python2.7/dist-packages/weboob/applications/qvideoob/video.py", line 23, in from PyQt5.QtMultimedia import QMediaContent, QMediaPlayer ImportError: No module named QtMultimedia
Bug#875912: Remove gcompris?
No problem, we can request its removal and go for transition. I'd suggest we wait for new gcompris-qt maintainer to finalize his first upload, and then request removal of old gcompris. - Mail original - > De: "Jeremy Bicha" > À: "submit" > Envoyé: Vendredi 15 Septembre 2017 22:49:19 > Objet: Bug#875912: Remove gcompris? > > Package: gcompris > Version: 15.10-1 > > gcompris is no longer being developed because it has been replaced by > gcompris-qt. The developers refuse to make any more gcompris > releases > since they don't want there to be confusion about what project is > being developed. > > Therefore, I suggest converting gcompris into a transitional package > depending on gcompris-qt. (Because the version numbering was reset, > that transitional package can't easily be shipped in the gcompris-qt > source.) > > Thanks, > Jeremy Bicha >
Bug#876122: spam accumulating in debian-embedded archive
Package: lists.debian.org The last 5 months of debian-embedded archive is essentially spam. At least some of them are rejected by my ISP's MTA with a 500, and that causes reports from the list server that mails to me are bouncing, which is quite uncomfortable :)
Bug#847996: edid-decode: wrongly interprets 13-byte strings as non-conforming
Package: edid-decode Version: 0.1~git20140128.afcf2a2e-1 The spec states that only when the "Alphanumeric Data String Descriptor Definition" is less than 13 bytes, should it be followed by 0x0A and further padded with 0x20. Thus, a 13-byte string without a 0x0A is valid, but edid-decode rejects it. Note that other fields have the same description, eg. "Display Product Serial Number Descriptor Definition"
Bug#832797: sgt-puzzles: missing menu entries
Package: sgt-puzzles Version: 20160429.b31155b-1 At least sgt-undead is not in the /usr/share/menu/ declaration - and since for some reason (too many entries?) lxqt does not list all games from desktop files, the only way to launch it from lxqt seems to be from cmdline.
Bug#848668: emacs25: please include .desktop file for emacsclient
Package: emacs25 Severity: wishlist Tags: patch Today eg. firefox proposes to open a text file in emacs, but since it only finds apps through desktop files, it won't propose emacsclient. Attached the one I'm using now, quickly modified from emacs25.desktop emacsclient25.desktop Description: application/desktop
Bug#849072: lightdm: add-seat badly documented, apparently deprecated
Package: lightdm Version: 1.18.2-2 While "dm-tool add-nested-seat" does work, it is not suitable for all uses, and "dm-tool add-seat" looks like the way to launch a real new X session. However: * manpage mentions the syntax is "dm-tool add-seat TYPE" without giving any clue as to what TYPE should be * https://answers.launchpad.net/lightdm/+question/176458 and https://bbs.archlinux.org/viewtopic.php?id=185297 hint about "xlocal/xremote" as possible types * all TYPEs I tried resulted in this error: # dm-tool add-seat xlocal Unable to add seat: GDBus.Error:org.freedesktop.DBus.Error.InvalidArgs: AddSeat is deprecated Looks like the message comes from lightdm itself! if (g_strcmp0 (method_name, "AddSeat") == 0) g_dbus_method_invocation_return_error (invocation, G_DBUS_ERROR, G_DBUS_ERROR_INVALID_ARGS, "AddSeat is deprecated"); else if (g_strcmp0 (method_name, "AddLocalXSeat") == 0) At least the manpage should tell it's not supposed to work anymore, and explain how to replace the feature. * switch-to-greater works, unless one wants to open a new session as a user already logged in * with add-local-x-seat we can get things to work with: I tried: # X :1 & # dm-tool add-local-x-seat 1 ... which does work, but with several inconveniences: * we have to find out by hand which tty was selected - I get tty2 or tty3 (despite a getty running there), instead of expected tty8, ie. the tty constraints obeyed by lightdm do not apply * dm-tool switch-to-user is of no use to discover this tty with several sessions for the same user
Bug#834790: aptitude hangs at "Loading cache" when unable to download package list
Just hit the same problem after adding a valid sources.list entry without having imported the repo signing key, and I can confirm it'the behaviour is really awkward - and reading suggestions that letting the user lose time until he figures out he has to restarti aptitude would be a valid way out instead of displaying a proper message to the user - that just makes me very uncomfortable, it's just not the level of software quality I have been expecting around here :) Regards, -- Yann
Bug#833741: patch/nmu ?
tags 833741 + patch thanks Is there any reason not to apply that patch ?
Bug#833741: Patch updated for 1.8.3
Updated Bob's patch, which was against 1.8.1, to 1.8.3.
This fixes both RC bugs, uploading a NMU hoping it's not too late...
diff --git a/debian/changelog b/debian/changelog
index e94d50a..965efd3 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,17 @@
+pepperflashplugin-nonfree (1.8.4) unstable; urgency=medium
+
+ [ Bob Proulx ]
+ * Patched to use Adobe upstream rather than Google.
+ * Inspired by the patch provided in Bug#833741#15 by Kristian Klausen
+but rewritten. Closes: #833741.
+ * Adds in 32-bit support.
+
+ [ Yann Dirson ]
+ * Non-maintainer upload.
+ * Updated patch for 1.8.3
+
+ -- Yann Dirson Sat, 14 Jan 2017 18:57:25 +0100
+
pepperflashplugin-nonfree (1.8.3) unstable; urgency=medium
* update-pepperflashplugin-nonfree:
diff --git a/debian/control b/debian/control
index 3e35edf..0e4f28d 100644
--- a/debian/control
+++ b/debian/control
@@ -13,6 +13,6 @@ Pre-Depends: ca-certificates
Suggests: chromium, ttf-mscorefonts-installer, ttf-dejavu, ttf-xfree86-nonfree, hal
Conflicts: libflash-mozplugin, chromium (<< 37.0.2062.120-4)
Description: Pepper Flash Player - browser plugin
- This package will download Chrome from Google, and unpack it to make the
+ This package will download Chrome from Adobe, and unpack it to make the
included Pepper Flash Player available for use with Chromium. The end user
- license agreement is available at Google.
+ license agreement is available at Adobe.
diff --git a/debian/install b/debian/install
index c4a3e4d..2b54a10 100644
--- a/debian/install
+++ b/debian/install
@@ -1,3 +1,2 @@
update-pepperflashplugin-nonfree usr/sbin/
-pubkey-google.txt usr/lib/pepperflashplugin-nonfree/
debian/etc/chromium.d/pepperflashplugin-nonfree etc/chromium.d/
diff --git a/debian/postinst b/debian/postinst
index 531d6dd..f7c7051 100644
--- a/debian/postinst
+++ b/debian/postinst
@@ -5,6 +5,9 @@ set -e
case "$1" in
configure)
update-pepperflashplugin-nonfree --install --fast || true
+ # Clean up the old Google debs as we are now using Adobe tar.gz files.
+ rm -rf /var/cache/pepperflashplugin-nonfree/*.deb
+ rm -rf /var/cache/pepperflashplugin-nonfree/latest-stable-verified.txt
;;
abort-upgrade|abort-remove|abort-deconfigure)
diff --git a/update-pepperflashplugin-nonfree b/update-pepperflashplugin-nonfree
index 62aceb8..39784c6 100755
--- a/update-pepperflashplugin-nonfree
+++ b/update-pepperflashplugin-nonfree
@@ -17,12 +17,6 @@
set -e
-return_0() {
- return 0
-}
-
-trap "return_0" 0
-
die_hard() {
echo "ERROR: $1" >&2
echo "More information might be available at:" >&2
@@ -30,7 +24,7 @@ die_hard() {
exit 1
}
-[ `id -u` = "0" ] || die_hard "must be root"
+[ "$(id -u)" = "0" ] || die_hard "must be root"
show_usage() {
echo "Usage:"
@@ -43,18 +37,16 @@ show_usage() {
exit 1
}
-getopt_temp=`getopt -o iusfvq --long install,uninstall,status,fast,verbose,quiet,beta,unstable,unverified \
- -n 'update-pepperflashplugin-nonfree' -- "$@"` || show_usage
-eval set -- "$getopt_temp" || show_usage
+getopt_temp=$(getopt -o iusfvq --long install,uninstall,status,fast,verbose,quiet \
+ -n 'update-pepperflashplugin-nonfree' -- "$@") || show_usage
+eval set -- "$getopt_temp"
ACTION=none
fast=no
verbose=no
quiet=no
-variant=stable
-verified=yes
-while [ true ]
+while [ $# -gt 0 ]
do
case "$1" in
-i|--install)
@@ -81,18 +73,6 @@ do
quiet=yes
shift
;;
- --beta)
- variant=beta
- shift
- ;;
- --unstable)
- variant=unstable
- shift
- ;;
- --unverified)
- verified=no
- shift
- ;;
--)
shift
break
@@ -109,106 +89,34 @@ done
[ "$verbose" != "yes" ] || echo "options : $getopt_temp"
-latestfile=latest-$variant-verified.txt
-[ "$verified" != "no" ] || latestfile=latest-$variant.txt
-
-UNPACKDIR=`mktemp -d /tmp/pepperflashplugin-nonfree.XX` || die_hard "mktemp failed"
-echo "$UNPACKDIR" | grep -q "^/tmp/pepperflashplugin-nonfree\." || die_hard "paranoia"
-cd "$UNPACKDIR" || die_hard "cd failed"
-
-[ "$verbose" != "yes" ] || echo "temporary directory: $UNPACKDIR"
-
-do_cleanup() {
- [ "$verbose" != "yes" ] || echo "cleaning up temporary directory $UNPACKDIR ..."
- cd /
- echo "$UNPACKDIR" | grep -q "^/tmp/pepperflashplugin-nonfree\." || die_hard "paranoia"
- rm -rf "$UNPACKDIR"
-}
-
-die_hard_with_a_cleanup() {
- return_0
- do_cleanup
- die_hard "$1"
-}
-
-trap "die_hard_with_a_cleanup interrupted" INT
+wgetquiet='-q'
+wgetfast='-t 3 -T 15'
+wgetprogress='-v --progress=dot:default'
+[ "$quiet" != "no" ] || wgetquiet=""
+[ "$fast" != "no" ] || wgetfast=""
+wgetoptions="$wgetquiet $wgetfast $wgetprogress"
+
+arch=""
+case $(dpkg --print-architecture) in
+ amd64) arch="x86_64" ;;
+ i?86) arch="i386" ;;
+ *)
+ die_hard "unsupported architectures" ;;
+esac
cachedir=/var/cache/pepperflashplugin-nonfree
-wgetquiet=' -q '
-wgetfast='-t 3 -T 15 '
-wgetalways=' -nd -P . '
-wgetprogress=' -v --progress=dot:default '
-
-if [ "$ACTION" = "--install" -o "$ACTION" = "--status
Bug#849856: input-utils: outdated upstream URL, new upstream release
Package: input-utils Version: 1.0-1.1 Contents behind upstream URL in copyright in watch files is apparently a set of CVS snapshot not updated any more. There is a 1.2 release at https://www.kraxel.org/releases/input/ Homepage at https://www.kraxel.org/blog/linux/input/
Bug#836068: tightvnc: version 1.3.10
Package: tightvnc Version: 1.3.9-8 Severity: wishlist Although develelopment seems to have stopped in this software, the latest version on http://www.tightvnc.com/download-old.php is more recent than ours.
Bug#836265: [Aptitude-devel] Bug#836265: aptitude: keeps reselecting sysvinit
- Mail original - > I don't see sysvinit being Essential anymore in unstable: > > → apt-cache show sysvinit | fgrep -i Essential > This package depends on init, which is an essential package that > → > > Any chance that you have stable/jessie in your sources.list, too? Yes: wheezy, jessie, testing, unstable, experimental. > If so, the bug might be that aptitude considers any version essential > even if only a non-candidate version is marked as essential. Looks like. "apt-cache show" confirms that 2.88dsf-41+deb7u1 is Essential but that 2.88dsf-59 and 2.88dsf-59.7 are not, whereas aptitude shows "Essential: yes" for all of them.
Bug#836265: aptitude: keeps reselecting sysvinit
- Mail original -
> De: "Sven Joachim"
> À: ydir...@free.fr
> Cc: "Axel Beckert" , 836...@bugs.debian.org
> Envoyé: Jeudi 1 Septembre 2016 12:24:59
> Objet: Re: Bug#836265: aptitude: keeps reselecting sysvinit
>
> On 2016-09-01 11:58 +0200, ydir...@free.fr wrote:
>
> > - Mail original -
> >> I don't see sysvinit being Essential anymore in unstable:
> >>
> >> → apt-cache show sysvinit | fgrep -i Essential
> >> This package depends on init, which is an essential package that
> >> →
> >>
> >> Any chance that you have stable/jessie in your sources.list, too?
> >
> > Yes: wheezy, jessie, testing, unstable, experimental.
>
> Actually only the wheezy version of sysvinit is essential, and you
> might
> want to remove that suite from your sources.list (mixing oldstable
> and
> unstable is not supported).
I only have a couple of non-essential packages from wheezy for some
tests, I will end up removing them completely at some point. But
having the sources.list entry still allows for getting info really quickly
and I'll likely keep it around for some time.
> >> If so, the bug might be that aptitude considers any version
> >> essential
> >> even if only a non-candidate version is marked as essential.
>
> Note that apt behaves the same way, see #216768. See also the
> changelog
> entry for 0.8.1-1:
>
> ,
> | aptitude (0.8.1-1) unstable; urgency=low
> | [...]
> | - Bug fixes:
> | * Install new Essential or Required packages with the
> | commands
> | "full-upgrade" (command line) and MarkUpgradable ('U' in
> | the curses
> | interface) (Closes: #555896, #757028)
> `
I see, but here it's not even the case of a new Essential package.
I agree that new aptitude does not have to support wheezy->jessie
upgrade, so it's not a very serious bug, just annoying :)
Bug#836265: [Aptitude-devel] Bug#836265: aptitude: keeps reselecting sysvinit
- Mail original - > De: "David Kalnischkies" > À: ydir...@free.fr, 836...@bugs.debian.org > Envoyé: Jeudi 1 Septembre 2016 16:20:55 > Objet: Re: [Aptitude-devel] Bug#836265: aptitude: keeps reselecting sysvinit > > On Thu, Sep 01, 2016 at 02:10:14PM +0200, ydir...@free.fr wrote: > > > >> I don't see sysvinit being Essential anymore in unstable: > > > >> > > > >> → apt-cache show sysvinit | fgrep -i Essential > > > >> This package depends on init, which is an essential package > > > >> that > > > >> → > > > >> > > > >> Any chance that you have stable/jessie in your sources.list, > > > >> too? > > > > > > > > Yes: wheezy, jessie, testing, unstable, experimental. > > > > > > Actually only the wheezy version of sysvinit is essential, and > > > you > > > might want to remove that suite from your sources.list (mixing > > > oldstable and unstable is not supported). > > > > I only have a couple of non-essential packages from wheezy for some > > tests, I will end up removing them completely at some point. But > > So you even have packages installed on your system which depend > (implicitly) on the essential package set they were released with, > which > includes sysvinit. Your system is therefore broken at the moment and > libapt tools are trying to fix that. > > The packages happen not to use that old-essential package (maybe, who > knows without checking), but they could at any point in time. Perhaps > they malfunction already and you just haven't noticed yet… You have > to > thank your tools that they try to help you to the best of their > abilities! :) Sure for the general case, but (to just take my situation as an example) I doubt that a couple of video libs and tools have such a tight coupling the essential packages. I'm still feeling that I know what I'm doing :)
Bug#836777: perceptualdiff: does not catch disk-full condition, creates 0-size diffs
Package: perceptualdiff Version: 1.2-2 -output will always create a file, but when the disk is full its size is 0 and we don't get an error message.
Bug#833630: scalpel: performance decreases with running time
Package: scalpel Version: 1.60-1 Severity: important Running scalpel on a 1TB drive with 100 patterns of 1024 bytes each: * ETA some time after starting stabilized around 11h (as I recall it, but this number is superfluous, the next ones talk loud enough) * after 11h run it has done 63% and the ETA is still in 6h * after 9h more it has done 68% and ETA is now up to 9h That does not quite match everyone's idea of high performance, there has to be a problem.
Bug#632689: scalpel: upstream changed
Looking for 2.0 source, one rapidly notices that the upstream Homepage is not valid any more. Digging a bit: * Fedora seems to have an upstream tarball at http://pkgs.fedoraproject.org/lookaside/pkgs/scalpel/scalpel-2.0.tar.gz/b0da813bf34941e79209d7fafe86a6e6/ * http://fossies.org/linux/misc/scalpel-2.0.tar.gz/ points to https://github.com/sleuthkit/scalpel, which appears to be 2.0 + some patches, but was last changed in 2014
Bug#833638: foremost: does not completely honor build opts
Package: foremost Version: 1.5.7-5 Tags: patch Only adding flags to the default -O2 will not allow build option "noopt" to work. From faa2c13f600818fc2aac0c293ff55a2935265041 Mon Sep 17 00:00:00 2001 From: Yann Dirson Date: Sun, 7 Aug 2016 13:46:04 +0200 Subject: [PATCH] Fix build to honor flags set by dh --- debian/changelog| 7 +++ debian/patches/fix-hurd-and-kfreebsd-build.patch| 8 +--- debian/patches/fix-hurd-max-path.patch | 8 +--- debian/patches/fix-lintian-hardening-warnings.patch | 16 +--- debian/patches/series | 1 + 5 files changed, 19 insertions(+), 21 deletions(-) diff --git a/debian/changelog b/debian/changelog index c92258a..133fc97 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +foremost (1.5.7-5.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix build to honor flags set by dh. + + -- Yann Dirson Sun, 07 Aug 2016 13:18:25 +0200 + foremost (1.5.7-5) unstable; urgency=medium * Update maintainer email address. diff --git a/debian/patches/fix-hurd-and-kfreebsd-build.patch b/debian/patches/fix-hurd-and-kfreebsd-build.patch index 10d11e6..93434bb 100644 --- a/debian/patches/fix-hurd-and-kfreebsd-build.patch +++ b/debian/patches/fix-hurd-and-kfreebsd-build.patch @@ -1,8 +1,10 @@ Fixed hurd-i386, kfreebsd-i386 and kfreebsd-amd64 build by adding its respective rules to Makefile. a/Makefile -+++ b/Makefile -@@ -76,6 +76,8 @@ +Index: debian-pkg-foremost/Makefile +=== +--- debian-pkg-foremost.orig/Makefile debian-pkg-foremost/Makefile +@@ -74,6 +74,8 @@ mac: goals netbsd: unix openbsd: unix freebsd: unix diff --git a/debian/patches/fix-hurd-max-path.patch b/debian/patches/fix-hurd-max-path.patch index 8016ea9..22ebec3 100644 --- a/debian/patches/fix-hurd-max-path.patch +++ b/debian/patches/fix-hurd-max-path.patch @@ -1,7 +1,9 @@ Fix FTBFS of hurd-i386 by defining the missing PATH_MAX macro. a/Makefile -+++ b/Makefile -@@ -76,7 +76,10 @@ +Index: debian-pkg-foremost/Makefile +=== +--- debian-pkg-foremost.orig/Makefile debian-pkg-foremost/Makefile +@@ -74,7 +74,10 @@ mac: goals netbsd: unix openbsd: unix freebsd: unix diff --git a/debian/patches/fix-lintian-hardening-warnings.patch b/debian/patches/fix-lintian-hardening-warnings.patch index 0d5af69..3c49163 100644 --- a/debian/patches/fix-lintian-hardening-warnings.patch +++ b/debian/patches/fix-lintian-hardening-warnings.patch @@ -1,18 +1,4 @@ -Add hardening flags to compilation. Fix a format string in order to do -so. a/Makefile -+++ b/Makefile -@@ -37,7 +37,9 @@ - WINCC = $(RAW_CC) $(RAW_FLAGS) -D__WIN32 - - # Generic "how to compile C files" --CC = $(RAW_CC) $(RAW_FLAGS) -D__UNIX -+CC = $(RAW_CC) $(RAW_FLAGS) -D__UNIX $(shell dpkg-buildflags --get CFLAGS)\ -+ $(shell dpkg-buildflags --get CPPFLAGS) \ -+ $(shell dpkg-buildflags --get LDFLAGS) - .c.o: - $(CC) -c $< - +Fix a format string in order to add hardening flags. --- a/extract.c +++ b/extract.c @@ -2145,7 +2145,7 @@ diff --git a/debian/patches/series b/debian/patches/series index 7308fb4..a6b8af7 100644 --- a/debian/patches/series +++ b/debian/patches/series @@ -2,3 +2,4 @@ fix-config-file-path.patch fix-lintian-hardening-warnings.patch fix-hurd-and-kfreebsd-build.patch fix-hurd-max-path.patch +fix-make-flags.patch -- 2.8.1
Bug#833639: foremost: cryptic/suspicious error message about config parsing and corrupts memory when lines are longer than 1024 bytes
Package: foremost Version: 1.5.7-5 Severity: important When forging a config file with 100 big (1024-bytes) patterns, I get the message "ERROR: In line 2 of the configuration file." That: * does not tell what the problem is * is suspect because there is no reason why line 1 would have worked and not line 2, they have the same structure. Nevertheless a 1-line config file does not report the error. * does not give a clue about whether line 3 and later are even looked at Furthermore, the config-parsing code issuing this message is quite strangely formulated. What happens is that read buffer is sized by MAX_STRING_LENGTH, which is defined to be 1024, but the code does not check that it indeed got a line, and strtok (which sucks) will happily corrupt memory after the buffer. Which luckily I didn't have the time to suffer from, but well... Furthermore, this MAX_STRING_LENGTH is at the same time the max length for a line, and the max length for suffix, header, and footer. A bit of nonsense, I would say.
Bug#833642: foremost: hardcoded limit of 50 patterns is not enforced, segfault
Package: foremost Version: 1.5.7-5 Severity: important main.h: s_spec search_spec[50]; /*ARRAY OF BUILTIN SEARCH TYPES*/ Feeding a config with a large number of entries causes a buffer overflow. It segfaults for my large config, but someone with 51 entries could have funny surprises...
Bug#632689: scalpel: upstream changed
Taking a look at the 2.0 source code from the sleuthkit repo, we can see a small issue with that version: It looks like it uses PASCAL-style prefix-length strings to store patterns, which prevents to use patterns larger than 256 bytes. Why on earth not using a struct to keep the size in an explicit field !? - Mail original - > De: ydir...@free.fr > À: 632...@bugs.debian.org > Envoyé: Dimanche 7 Août 2016 11:36:17 > Objet: scalpel: upstream changed > > Looking for 2.0 source, one rapidly notices that the upstream > Homepage > is not valid any more. > > Digging a bit: > * Fedora seems to have an upstream tarball at > > http://pkgs.fedoraproject.org/lookaside/pkgs/scalpel/scalpel-2.0.tar.gz/b0da813bf34941e79209d7fafe86a6e6/ > * http://fossies.org/linux/misc/scalpel-2.0.tar.gz/ points to > https://github.com/sleuthkit/scalpel, which appears to be 2.0 + > some patches, but > was last changed in 2014 > >
Bug#833649: scalpel: no check for overflow while reading patterns
Package: scalpel Version: 1.60-1 Severity: important Although the buffer used to hold a line is larger than in the original foremost code, it still does not check that the buffer really holds a complete line, and strtok will happily corrupt data outside of the buffer when a line is large enough. Checking the output of fgets ought to be sufficient to catch the problem and tell the user to increase MAX_STRING_LENGTH. See #833639 for the foremost bug. Also note that 2.0 is no better in this respect. Also note that processSearchSpecLine hardcodes a 6 in the tokenarray malloc call, instead of using NUM_SEARCH_SPEC_ELEMENTS.
Bug#833630: scalpel: performance decreases with running time
Another test, more closely monitored, with the same set of 100 1024-bytes patterns, carving a 1TB SATA drive, with defines updated to avoid buffer overflows: +--- scalpel-1.60.orig/scalpel.h scalpel-1.60/scalpel.h +@@ -143,11 +143,10 @@ void setProgramName(char *s); + + + #define SCALPEL_BLOCK_SIZE 512 +-#define MAX_STRING_LENGTH4096 +-#define MAX_NEEDLES 254 ++#define MAX_STRING_LENGTH5000 + #define NUM_SEARCH_SPEC_ELEMENTS6 + #define MAX_SUFFIX_LENGTH 8 +-#define MAX_FILE_TYPES100 ++#define MAX_FILE_TYPES600 + + #define MAX_FILES_PER_SUBDIRECTORY1000 + elapsed %done ETA 1h 10.5% 8:28 2h 16.4% 10:12 3h 27.4% 7:59 4h 37.7% 6:32 5h 55.1% 4:03 # inflexion point 6h 62.4% 3:36 7h20 63.6% 4:14 8h 64.2% 4:30 9h 65.0% 4:50 10h 65.8% 5:09 16h2571.6% 6:32
Bug#841765: enet: new version available
Package: enet Version: 1.3.12+ds-2 1.3.13 was apparently released some time ago. http://enet.bespin.org/download/
Bug#831825: clarification request
severity 831825 important tags 831825 + unreproducible moreinfo reassign 831825 gcompris-qt thanks Let's lower the severity as it seems not to impact all users. Trying to reproduce, I'm puzzled by the description, as gcompris does not have a bottom-left menu, although gompris-qt has one. I'm thus assuming it is a gcompris-qt bug and reassigning. Best regards, Yann
Bug#835046: apt-listchanges: complains about InfoFD after upgrade
Package: apt-listchanges Version: 3.3 After an upgrade in aptitude, which notified me of changes in the config file, and for which the config file was properly replaced by the new version, I get the following when I request installation of a new package from the same aptitude session: apt-listchanges: APT_HOOK_INFO_FD environment variable is incorrectly defined (Dpkg::Tools::Options::/usr/bin/apt-listchanges::InfoFD should be greater than 2). E: Sub-process /usr/bin/apt-listchanges --apt || test $? -ne 10 returned an error code (1) E: Failure running script /usr/bin/apt-listchanges --apt || test $? -ne 10 Press Return to continue, 'q' followed by Return to quit. I apparently have to exit/restart aptitude so that the apt.conf files get refreshed, and then I'm able to install packages again.
Bug#820583: flashplugin-nonfree: should notify when an update is not yet available, not just reinstall current version
Package: flashplugin-nonfree Version: 1:3.6.1+b1 Severity: important After noticing announcement of a CVE, it's rather normal to very where one machine stands: # update-flashplugin-nonfree --status Flash Player version installed on this system : 11.2.202.577 Flash Player version available on upstream site: 11.2.202.616 And then: # update-flashplugin-nonfree --install # echo $? 0 But in fact... # update-flashplugin-nonfree --status Flash Player version installed on this system : 11.2.202.577 Flash Player version available on upstream site: 11.2.202.616 While --verbose shows that in fact it's just reinstalling the current version: # update-flashplugin-nonfree --install --verbose options : --install --verbose -- temporary directory: /tmp/flashplugin-nonfree.N52OJlswDN importing public key ... selected action = --install installed version = 11.2.202.577 upstream version = 11.2.202.616 wgetoptions= -nd -P . -v --progress=dot:default downloading http://people.debian.org/~bartm/flashplugin-nonfree/D5C0FC14/fp.11.2.202.616.sha512.amd64.pgp.asc ... URL transformed to HTTPS due to an HSTS policy --2016-04-10 11:43:08-- https://people.debian.org/~bartm/flashplugin-nonfree/D5C0FC14/fp.11.2.202.616.sha512.amd64.pgp.asc Resolving people.debian.org (people.debian.org)... 5.153.231.30, 2001:41c8:1000:21::21:30 Connecting to people.debian.org (people.debian.org)|5.153.231.30|:443... connected. HTTP request sent, awaiting response... 404 Not Found 2016-04-10 11:43:08 ERROR 404: Not Found. wget failed to download http://people.debian.org/~bartm/flashplugin-nonfree/D5C0FC14/fp.11.2.202.616.sha512.amd64.pgp.asc downloading http://people.debian.org/~bartm/flashplugin-nonfree/D5C0FC14/fp10.sha512.amd64.pgp.asc ... URL transformed to HTTPS due to an HSTS policy --2016-04-10 11:43:08-- https://people.debian.org/~bartm/flashplugin-nonfree/D5C0FC14/fp10.sha512.amd64.pgp.asc Resolving people.debian.org (people.debian.org)... 5.153.231.30, 2001:41c8:1000:21::21:30 Connecting to people.debian.org (people.debian.org)|5.153.231.30|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 1250 (1.2K) [text/plain] Saving to: ‘./fp10.sha512.amd64.pgp.asc’ 0K . 100% 193M=0s 2016-04-10 11:43:08 (193 MB/s) - ‘./fp10.sha512.amd64.pgp.asc’ saved [1250/1250] verifying PGP fp10.sha512.amd64.pgp.asc ... copying /var/cache/flashplugin-nonfree/install_flash_player_11_linux.x86_64.tar.gz ... verifying checksum install_flash_player_11_linux.x86_64.tar.gz ... wgetoptions= -nd -P . -v --progress=dot:default -O /tmp/flashplugin-nonfree.N52OJlswDN/install_flash_player_11_linux.x86_64.tar.gz downloading https://fpdownload.adobe.com/get/flashplayer/pdc/11.2.202.577/install_flash_player_11_linux.x86_64.tar.gz ... verifying checksum install_flash_player_11_linux.x86_64.tar.gz ... unpacking install_flash_player_11_linux.x86_64.tar.gz ... verifying checksum contents of install_flash_player_11_linux.x86_64.tar.gz ... moving libflashplayer.so to /usr/lib/flashplugin-nonfree ... setting permissions and ownership of /usr/lib/flashplugin-nonfree/libflashplayer.so ... Flash Player version: 11.2.202.577 moving install_flash_player_11_linux.x86_64.tar.gz to /var/cache/flashplugin-nonfree ...
