Bug#747629: Problem still exists in systemd 234-3
Hi. I just encountered this bug. I'm using systemd 234-3 on a fresh install. The advice here https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=747629#15 worked for me. Cheers, --Dave
Bug#831905: CVE-2016-5080
Package: asn1c There is a security bug regarding ASN1C by Objective Systems Inc. However, I believe that Debian's ASN1C is a different implementation by Lev Walkin. Please confirm that this package is not affected by CVE-2016-5080. Thanks, cheers, --Dave
Bug#813626: FAI_FLAGS: 'wait' happens before 'createvts'
Package: fai-server Version: 5.0.1 Hello. This bug is filed against fai-server, but actually I'm booting off the fai-cd64_small_5.0.1.iso from http://fai-project.org/fai-cd/. I boot from the CD and use grub to edit the command line. I add sshd,wait,debug to the default FAI_FLAGS of createvt,verbose. The system echos a message and sits in sleep 5 as seen starting at this line in lib/subroutines: https://github.com/faiproject/fai/blob/5.0.1/lib/subroutines#L874 But, at that point, it hasn't started bash on an extra virtual terminal yet... so I cannot edit anything. This is because the sleep 5 is inside task_confdir(), and the code that creates the virtual terminals lives inside task_setup(). Back in bin/fai, task confdir is called before task setup. (In fstart(), see https://github.com/faiproject/fai/blob/5.0.1/bin/fai#L165) I recommend simply moving the last lines of lib/subroutines: task_confdirs() to the bottom of task_setup(). I hope this helps. Cheers! --Dave
Bug#800039: kget depends on vlc
Package: kget Version: 4:15.08.0+dfsg-1 Severity: normal $ sudo apt-get install kget The command above fails because I respond 'no' when prompted to install 310 megs of packages including Kate and VLC. Cheers, --Dave -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init)
Bug#795440: cryptmount-setup fails and can't recover when user mistypes initial passphrase
Package: cryptmount Version: 5.1-1 Hi. The cryptmount-setup script fails immediately when I provide mismatched passwords (passphrases) during setup. So the user has try again, and type in all those configuration values again. Hark! A bug! cryptmount-setup remembered the name of the new filesystem from the first run, even though it didn't complete, and won't allow the user try again to create an encrypted filesystem with that name. A shell transcript follows. Bug observed at the end. hobbes@metalbaby:~$ sudo cryptmount-setup # [...] omitting some lines [...] Generating random key; please be patient... Enter new password for target scrambled: Confirm password: Password mismatch hobbes@metalbaby:~$ sudo cryptmount-setup -- cryptmount setup script This program will allow you to setup a secure filing-system that will be managed by cryptmount. You will be able to select basic features such as the location and size of the filesystem - if you want more advanced features, you should consult the cryptmount manual page. cryptmount version 5.1, (C)Copyright 2007-2014 RW Penney cryptmount comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions - see the file 'COPYING' in the source directory. -- Each cryptmount filesystem is identifed by a short name which is used when mounting or configuring that filesystem. This name should be a single word (without spaces), such as opaque. The following target names have already been used:scrambled Please enter a target name for your filesystem [opaque]: scrambled The target-name scrambled has already been used Please enter a target name for your filesystem [opaque]: Cheers, --Dave
Bug#785758: This is a test which should be ignored.
Package: nosuchpackage This is a test. If a human is reading this, I apologize for the wasted time! You see, I'm setting up my own local BTS, and process crashes on invalid Package: pseudo-headers. I can't tell what it's *supposed* to do, so I'm checking what Debian BTS does... :) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762507: 'Suggests: tinymice' -- 'Suggests: tinymce'
Package: picolisp Version: 3.1.7.3-1 Severity: minor Dear Kan-Ru Chen, The package picolisp suggests the package tinymice. I believe this is a typo. picolisp should suggest the package tinymce instead. I confirmed this to my own satisfaction by performing two internet searches. picolisp tinymice (154 hits, all about the Debian package) picolisp tinymce (3690 hits, all about using TinyMCE with PicoLisp) I hope this helps. Cheers, --Dave Lincoln, Nebraska -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages picolisp depends on: ii dpkg 1.17.13 ii libc62.19-11 ii libssl1.0.0 1.0.1i-2 picolisp recommends no packages. Versions of packages picolisp suggests: pn tinymice none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#728399: virtualbox-guest-utils: Shared folders don't work with Linux 3.11
This is fixed upstream (in version 4.2.18). See: https://www.virtualbox.org/changeset/48529/vbox https://www.virtualbox.org/ticket/12128 Hope this helps, --Dave p.s. Meanwhile, I will attempt to boot a previous kernel.. :) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#728399: virtualbox-guest-utils: Shared folders don't work with Linux 3.11
Pardon me, but I might have said something inaccurate. Please allow me to clarify. It's fixed in SVN, but it looks like release 4.2.18 happened days before that. (This might not matter for your purposes?) Cheers, --Dave -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#685298: Impossible to simultaneously install libtomcat7-java and libtomcat6-java
I'm in favor of option 2: don't put tomcat libs in /usr/share/java, much less unversioned ones. When was the last time anybody looked in /usr/share/java when they wanted to build or run anything? :) It seems to me that the real users of the tomcat* packages are developers. Sure, there could be some package foo-game that runs in (and depends on) tomcat. In that case, I think it's up to the foo-game maintainer to make sure her package works, and as a java developer, she's probably disinclined to look in /usr/share/java, too. (Of all the mailing lists in the world, this is the one where I'll find the most disagreement with the previous statement!) You see where I'm going here? To get Java to be a first class citizen in the Debian ecosystem is going to take more than deciding where to store some jars. ...And the more friendly we are to java developers in the meantime, the more help we'll have during that long journey. I hope this helps. Regarding the long road ahead, has anybody ever considered providing a Debian specific classloader? Thought experiment: How would you meet Debian needs and Java needs simultaneously if the only thing you had control of was the classloader? Cheers, --Dave -Original Message- From: Emmanuel Bourg [mailto:ebo...@apache.org] Sent: Friday, September 13, 2013 6:19 AM To: 685...@bugs.debian.org Cc: tony mancill; Loyall, David; Jakub Adam Subject: Re: Bug#685298: Impossible to simultaneously install libtomcat7-java and libtomcat6-java Hi, I started working on the tomcat8 package and I'd like to avoid the same conflict with tomcat7. What would be the best solution? 1. Change the name of the unversioned jars to tomcat8-xxx.jar. That would give the following links in /usr/share/java: tomcat8-catalina-ant.jar - tomcat-catalina-ant-8.0.0.jar tomcat8-catalina-tribes.jar - tomcat-catalina-tribes-8.0.0.jar tomcat8-annotations-api.jar - tomcat-annotations-api-8.0.0.jar tomcat8-api.jar - tomcat-api-8.0.0.jar tomcat8-catalina-ha.jar - tomcat-catalina-ha-8.0.0.jar tomcat8-catalina.jar - tomcat-catalina-8.0.0.jar tomcat8-coyote.jar - tomcat-coyote-8.0.0.jar tomcat8-i18n-es.jar - tomcat-i18n-es-8.0.0.jar tomcat8-i18n-fr.jar - tomcat-i18n-fr-8.0.0.jar tomcat8-i18n-ja.jar - tomcat-i18n-ja-8.0.0.jar tomcat8-jasper-el.jar - tomcat-jasper-el-8.0.0.jar tomcat8-jasper.jar - tomcat-jasper-8.0.0.jar tomcat8-juli.jar - tomcat-juli-8.0.0.jar tomcat8-util.jar - tomcat-util-8.0.0.jar 2. Move the jars and links in a subdirectory of /usr/share/java. /usr/share/java/tomcat8/tomcat-juli.jar - ./tomcat-juli-8.0.0.jar /usr/share/java/tomcat8/tomcat-util.jar - ./tomcat-util-8.0.0.jar 3. Don't put the unversioned links in /usr/share/java. If a reverse dependency requires a stable path for building it could use the Maven repository in /usr/share/maven-repo. The Maven based packages wouldn't be impacted, and the Ant based packages could use a path like: /usr/share/maven-repo/org/apache/tomcat/tomcat-jasper/8.x/tomcat- jasper-8.x.jar What do you think? Emmanuel Bourg -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#685298: Impossible to simultaneously install libtomcat7-java and libtomcat6-java
Can't we change libtomcat6-java and libtomcat7-java to keep those jars in /usr/share/tomcat6/ and /usr/share/tomcat7/ instead of /usr/share/java/ ? Having tomcat6 and tomcat7 on the same machine is a very common use case for Java developers. And eschewing The Eclipse Way in favor of The Debian Way is a very common use case for long time Debian users. :) Cheers, thanks, --Dave p.s. When the second tomcat is installed, the service will fail to start because port 8080 is in use by the first one. I vote to leave that behavior as-is. (Java devs will not see this as a problem.) We only need to ensure that 'failing to start the service' doesn't result in 'failing to finish package installation'. (We're probably already safe on that?) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704778: mongodb-server: dpkg fails with error when insufficent diskspace to start
Package: mongodb-server
Version: 1:2.4.1-2
Severity: normal
Dear Maintainer,
I attempted to install mongodb-server while having not much free diskspace.
Here is a transcript:
hobbes@metalbaby:~$ sudo apt-get install mongodb-server
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
mongodb-clients
The following NEW packages will be installed:
mongodb-clients mongodb-server
0 upgraded, 2 newly installed, 0 to remove and 103 not upgraded.
Need to get 50.5 MB of archives.
After this operation, 130 MB of additional disk space will be used.
Do you want to continue [Y/n]?
Get:1 http://ftp.us.debian.org/debian/ sid/main mongodb-clients amd64
1:2.4.1-2 [39.7 MB]
Get:2 http://ftp.us.debian.org/debian/ sid/main mongodb-server amd64
1:2.4.1-2 [10.8 MB]
Fetched 50.5 MB in 20s (2,524 kB/s)
Selecting previously unselected package mongodb-clients.
(Reading database ... 121809 files and directories currently installed.)
Unpacking mongodb-clients (from .../mongodb-clients_1%3a2.4.1-2_amd64.deb)
...
Selecting previously unselected package mongodb-server.
Unpacking mongodb-server (from .../mongodb-server_1%3a2.4.1-2_amd64.deb) ...
Processing triggers for man-db ...
Setting up mongodb-clients (1:2.4.1-2) ...
Setting up mongodb-server (1:2.4.1-2) ...
Adding system user `mongodb' (UID 108) ...
Adding new user `mongodb' (UID 108) with group `nogroup' ...
Not creating home directory `/home/mongodb'.
Adding group `mongodb' (GID 113) ...
Done.
Adding user `mongodb' to group `mongodb' ...
Adding user mongodb to group mongodb
Done.
[FAIL] Starting database: mongodb failed!
invoke-rc.d: initscript mongodb, action start failed.
dpkg: error processing mongodb-server (--configure):
subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
mongodb-server
E: Sub-process /usr/bin/dpkg returned an error code (1)
Now, I figure out why:
hobbes@metalbaby:~$ cat /var/log/mongodb/mongodb.log
Fri Apr 5 12:02:18.598 [initandlisten] MongoDB starting : pid=30843
port=27017 dbpath=/var/lib/mongodb 64-bit host=metalbaby
Fri Apr 5 12:02:18.598 [initandlisten] db version v2.4.1
Fri Apr 5 12:02:18.598 [initandlisten] git version: nogitversion
Fri Apr 5 12:02:18.598 [initandlisten] build info: Linux bob 3.2.0-4-amd64
#1 SMP Debian 3.2.39-2 x86_64 BOOST_LIB_VERSION=1_49
Fri Apr 5 12:02:18.598 [initandlisten] allocator: tcmalloc
Fri Apr 5 12:02:18.598 [initandlisten] options: { bind_ip: 127.0.0.1,
command: [ run ], config: /etc/mongodb.conf, dbpath: /var/lib/mongodb,
journal: true, logappend: true, logpath: /var/log/mongodb/mongodb.log,
unixSocketPrefix: /var/run/mongodb }
Fri Apr 5 12:02:18.615 [initandlisten] journal dir=/var/lib/mongodb/journal
Fri Apr 5 12:02:18.615 [initandlisten] recover : no journal files present,
no recovery needed
Fri Apr 5 12:02:18.615 [initandlisten]
Fri Apr 5 12:02:18.615 [initandlisten] ERROR: Insufficient free space for
journal files
Fri Apr 5 12:02:18.615 [initandlisten] Please make at least 3379MB
available in /var/lib/mongodb/journal or use --smallfiles
Fri Apr 5 12:02:18.615 [initandlisten]
Fri Apr 5 12:02:18.615 [initandlisten] exception in initAndListen: 15926
Insufficient free space for journals, terminating
Fri Apr 5 12:02:18.615 dbexit:
Fri Apr 5 12:02:18.615 [initandlisten] shutdown: going to close listening
sockets...
Fri Apr 5 12:02:18.615 [initandlisten] shutdown: going to flush diaglog...
Fri Apr 5 12:02:18.615 [initandlisten] shutdown: going to close sockets...
Fri Apr 5 12:02:18.616 [initandlisten] shutdown: waiting for fs
preallocator...
Fri Apr 5 12:02:18.616 [initandlisten] shutdown: lock for final commit...
Fri Apr 5 12:02:18.616 [initandlisten] shutdown: final commit...
Fri Apr 5 12:02:18.616 [initandlisten] shutdown: closing all files...
Fri Apr 5 12:02:18.616 [initandlisten] closeAllFiles() finished
Fri Apr 5 12:02:18.616 [initandlisten] journalCleanup...
Fri Apr 5 12:02:18.616 [initandlisten] removeJournalFiles
Fri Apr 5 12:02:18.617 [initandlisten] shutdown: removing fs lock...
Fri Apr 5 12:02:18.617 dbexit: really exiting now
So, then I clear up some disk space and run sudo apt-get install and
mongodb-server becomes properly installed, configured, and started. Great!
So I'd recommend maybe changing the logic that starts the server to not break
the package installation if the server fails to start. I am under the
impression that many different things could cause the server to fail to start
(ports in use, disk space as seen above, etc.)
Hope this helps!
Cheers,
--Dave
...default output from reportbug(1)
Bug#365530: progress
Today (2013) I see amd64 bins on the upstream site[1]. Cheers, --Dave [1] http://www.gnu.org/software/mit-scheme/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#645410:
+1 I am waiting on this. http://www.graphviz.org/mantisbt/view.php?id=2212 (fixed in 2.28.) I am trying to build from git://git.debian.org/git/collab-maint/graphviz.git using git-buildpackage... But the build fails for [unstable] and [upstream/2.28.0] doesn't contain debian magic. That's as far as I got. :) Cheers, thanks!
