Bug#770519: [Pkg-vsquare-devel] Bug#770519: Patches for outdated kernel versions
Hello Renzo,
(using English because of the cc)
On Fri, Nov 21, 2014 at 23:47:01 +0100, Moritz Muehlenhoff wrote:
Severity: serious
kernel-patch-viewos only provides patches for up to Linux 3.1.5.
it should be updated to support the standard kernel in jessie
or removed.
As far as I can tell from the SVN repository, we only have patches up to
kernel version 3.6-rc1. Is there any ViewOS patch available for kernel
3.16? If not, we have to drop the Debian package.
Thanks!
Ludovico
--
IRC: garden@{freenode,oftc} | 4096R/DA03B32626600662
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671695: [Pkg-vsquare-devel] Bug#671695: fuseiso9660: copies from fuseiso9660 mount aren't reliable
tag 671695 + moreinfo upstream thanks On Sat, May 05, 2012 at 21:24:10 -0400, nick black wrote: I am using fuseiso9660 for the creation of my modified debian-installer ISO. simple-cdd creates a standard debian unstable netboot installer ISO, which I then mount as a FUSE-capable user. I copy files from the FUSE mount into a new directory, from which I make a new CD (using grub-mkrescue). Hello, thank you for your report. The upstream is trying to find the problem and some more information would help. Do you still have by any chance one of the corrupted files? It would be useful to compare them against the good one. If you don't have the broken files anymore, can you provide one of the good files, or at least its size? Thank you! Ludovico -- l...@dovi.coIRC: garden@freenode OpenPGP: 1024D/63D2D5D907F89BB8 Jabber/gtalk: garde...@gmail.com -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671695: [Pkg-vsquare-devel] Bug#671695: Bug#671695: fuseiso9660: copies from fuseiso9660 mount aren't reliable
retitle 671695 fuseiso9660: breaks when using fuse in multi-threading mode tag 671695 - moreinfo thanks On Sun, Jun 24, 2012 at 17:37:09 +0200, Ludovico Gardenghi wrote: thank you for your report. The upstream is trying to find the problem and some more information would help. The issue is related to multi-threading. fuseiso9660 has been written when fuse did not provide multi-threading and contains some thread-unsafe code. Currently, the only way to fix this issue is to always use -s to force single-threaded operations. A new upstream release will be done shortly, which will disable multi-threading until all the components are made thread-safe. Ludovico -- l...@dovi.coIRC: garden@freenode OpenPGP: 1024D/63D2D5D907F89BB8 Jabber/gtalk: garde...@gmail.com -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#548099: broken on kfreebsd
On Tue, Feb 21, 2012 at 15:53:34 +0100, martin f krafft wrote: It seems reasonable to me to try to climb up the process tree until we meet a process with sshd in the command line (or, maybe better (?), with sshd in the proc/pid/exe symlink). Still not the cleanest of the solutions, but should be quite portable. Last I checked, /proc is *not* portable. Right, sorry: quite as in at least for the architectures we'd like to fix, and AFAIK, which I agree is a sensibly different meaning. The check I proposed seems to work fine at least on a recent Linux (2.6.3x), on kFreeBSD 8.2 (asdfasdf) and hurd (exodar). I haven't tested it with esotheric configurations. Looking for the tty in the sshd commandline did not prove very portable as well, so until a really portable way is found we could add another not-so-portable check. molly-guard is not a very complex tool, so I'd not be afraid to pollute it with stuff that will be too complex to remove in the future. molly-guard does not guarantee to be triggered each time you're connected via ssh (e.g. a screen or tmux started on a local console and reattached remotely will not contain SSH_* in the environment nor will the inside shell have a sshd-owned tty), IMHO if some more false negatives can be avoided, it could be worth adding a test. Bye, Ludovico -- l...@dovi.coIRC: garden@freenode OpenPGP: 1024D/63D2D5D907F89BB8 Jabber/gtalk: garde...@gmail.com -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639559: Doesn't listen at all
On Wed, Oct 12, 2011 at 20:37:30 +0100, Regis Boudin wrote: thanks for the report, I'm looking into the issue, hopefully will get it fixed soon. The .la files that have been removed in 1.2-24 for compliance with S-V 3.9.2 were in fact used by sbnc via lt_dlopen. I restored them cleaning the dependency_libs line. I attach the debdiff for my QA release for whoever wants to adopt sbnc. Ludovico -- l...@dovi.coIRC: garden@freenode OpenPGP: 1024D/63D2D5D907F89BB8 Jabber/gtalk: garde...@gmail.com diff -Nru sbnc-1.2/debian/changelog sbnc-1.2/debian/changelog --- sbnc-1.2/debian/changelog 2011-08-16 21:29:18.0 +0200 +++ sbnc-1.2/debian/changelog 2012-02-19 16:56:45.0 +0100 @@ -1,3 +1,12 @@ +sbnc (1.2-25) unstable; urgency=low + + * QA upload. + * Put back .la files (they are used by lt_dlopen), emptying the +dependency_libs setting. Closes: #639559. + * Add build-indep and build-arch targets to debian/rules. + + -- Ludovico Gardenghi gar...@debian.org Sun, 19 Feb 2012 16:56:06 +0100 + sbnc (1.2-24) unstable; urgency=low * QA upload. diff -Nru sbnc-1.2/debian/rules sbnc-1.2/debian/rules --- sbnc-1.2/debian/rules 2011-04-16 12:35:54.0 +0200 +++ sbnc-1.2/debian/rules 2012-02-19 16:56:45.0 +0100 @@ -21,7 +21,9 @@ --prefix=/ --exec-prefix=/ --with-tcl=/usr/lib/tcl8.5 touch configure-stamp -build: build-stamp +build: build-arch build-indep +build-arch: build-stamp +build-indep: build-stamp build-stamp: config.status dh_testdir $(MAKE) @@ -56,6 +58,8 @@ chrpath -d -k debian/temp/usr/lib/sbnc/libbnctcl.so # Replace leading '//' with '/' in the path. sed 's;//;/;g' -i debian/temp/usr/lib/sbnc/lib*.la + # Empty the 'dependency_libs' setting in .la files. + sed -i /dependency_libs/ s/'.*'/''/ debian/temp/usr/lib/sbnc/lib*.la dh_install binary-indep: build install diff -Nru sbnc-1.2/debian/sbnc.install sbnc-1.2/debian/sbnc.install --- sbnc-1.2/debian/sbnc.install 2011-08-16 21:29:41.0 +0200 +++ sbnc-1.2/debian/sbnc.install 2012-02-19 16:56:45.0 +0100 @@ -1,3 +1,4 @@ debian/temp/sbnc usr/sbin/ debian/temp/usr/lib/sbnc/libsbnc.so* usr/lib/sbnc/ +debian/temp/usr/lib/sbnc/libsbnc.la usr/lib/sbnc/ debian/temp/sbnc.ipc usr/share/sbnc/templates/ diff -Nru sbnc-1.2/debian/sbnc-tcl.install sbnc-1.2/debian/sbnc-tcl.install --- sbnc-1.2/debian/sbnc-tcl.install 2011-08-16 21:29:52.0 +0200 +++ sbnc-1.2/debian/sbnc-tcl.install 2012-02-19 16:56:45.0 +0100 @@ -1,3 +1,4 @@ debian/temp/usr/lib/sbnc/libbnctcl.so* usr/lib/sbnc/ +debian/temp/usr/lib/sbnc/libbnctcl.la usr/lib/sbnc/ debian/temp/scripts usr/lib/sbnc/ debian/temp/sbnc.tcl usr/share/sbnc-tcl/templates/
Bug#548099: broken on kfreebsd
Hello,
I was checking this bug during the Paris BSP which is taking place right
now. What about throwing in another check like the following one in
addition to the tty and SSH_CONNECTION ones?
is_child_of_sshd() {
pid=$$
ppid=$PPID
# Walk up to init.
while [ $pid -ne 1 ]; do
grep -q sshd /proc/$ppid/cmdline return 0
pid=$ppid
ppid=$(grep ^PPid: /proc/$pid/status | tr -dc 0-9)
done
return 1
}
[...]
if ! pgrep -f ^sshd.+${PTS#/dev/}\ /dev/null \
[ -z ${SSH_CONNECTION:-} ] \
! is_child_of_sshd; then
[...]
It seems reasonable to me to try to climb up the process tree until we
meet a process with sshd in the command line (or, maybe better (?),
with sshd in the proc/pid/exe symlink). Still not the cleanest of the
solutions, but should be quite portable.
Ludovico
--
l...@dovi.coIRC: garden@freenode
OpenPGP: 1024D/63D2D5D907F89BB8 Jabber/gtalk: garde...@gmail.com
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#610933: [Pkg-vsquare-devel] Bug#610933: libvdeplug3 declares a conflict with libvdeplug2
On Thu, Jan 19, 2012 at 13:58:01 -0600, Jonathan Nieder wrote: Oh, that seems reasonable. This seems to have been discussed recently on the debian-policy list (search for I don't think there's much gain in relaxing this): http://bugs.debian.org/556015#141 http://bugs.debian.org/556015#224 Thanks for the links. I wanted to make another upload for trying to build on kfreebsd and I took the opportunity to remove the split files and use a single debian/copyright. One lintian-override less. :-) Ludovico -- l...@dovi.coIRC: garden@freenode OpenPGP: 1024D/63D2D5D907F89BB8 Jabber/gtalk: garde...@gmail.com -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#610933: [Pkg-vsquare-devel] Bug#610933: libvdeplug3 declares a conflict with libvdeplug2
On Thu, Jan 19, 2012 at 05:06:30 -0600, Jonathan Nieder wrote: * Add patch for fixing wrong SONAME for libraries. -version-number had been used instead of version-info, this gave incorrect SONAMEs and broke compatibility between this version and the previous ones (althought there is no actual ABI incompatibility). Thanks, Ludovico! This is great. I had to modify the SONAME in Debian w.r.t. the current upstream SONAME, and I tried to do this in the safest way I could imagine, although it is not 100% conformant to the typical libtool current/revision/age progression (I bumped from 3:1:0 to 3:2:1). I discussed the thing a bit with some of the other upstream people (I am part of them) and it seemed safe enough -- we're going to update the upstream as well in the near future with the same patch I applied for Debian. I hope this won't generate havoc and chaos. Some tiny questions from looking over the diff: * If this header file is used to generate binaries meant to be used on other * distributions, it could be safe to redefine LIBVDEPLUG_DLOPEN_FILENAME with * the unversioned name. Do the various distros not agree on a soname for libvdeplug? I am aware that, for instance, the upstream of Virtualbox does a dlopen(libvdeplug.so), while the Debian package has a patch for dlopening libvdeplug.so.2. So I guess there may be other software out there who would like to redefine this. vde and its libraries has been used for creating stand-alone images of virtual machines (e.g. for education purposes) or other custom environments, so I added this possibility so to let other people use the libvdeplug_dyn.h header for building, on Debian, software that will be used with other distributions or in different situations. Moreover, given the -version-number vs -version-info problem I described in the changelog, there are people who will have to deal with the wrong libvdeplug.so.3 which comes from the current upstream SVN revision. I know all this is not proper/clean, but I'm not sure there is a really clean way to deal with this without uselessly breaking backward compatibility. It seemed cleaner than keeping 3:1:0 and creating symlinks .so.2 - .so.3 or similar. # There is a copyright file for each package, so the debian/copyright file is # not needed. I think ftpmasters tend to rely on debian/copyright documenting the copyright of the source package. Uhm, ok. I started creating an unified copyright file but I noticed I was duplicating information by hand -- then I thought it would have been better to make without debian/copyright rather than to have to keep debian/copyright in sync with debian/*.copyright manually, with the potential inconsistencies this could generate. But if that's required I can do it. Ludovico -- l...@dovi.coIRC: garden@freenode OpenPGP: 1024D/63D2D5D907F89BB8 Jabber/gtalk: garde...@gmail.com -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#554408: [Pkg-vsquare-devel] Bug#554408: fuse-umfuse-iso9660: diff for NMU version 0.2b-1.1
On Sun, Dec 18, 2011 at 14:05:15 +0100, gregor herrmann wrote: Dear maintainer, I've prepared an NMU for fuse-umfuse-iso9660 (versioned as 0.2b-1.1) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. Thanks for your job. I'm trying to update all the pkg-vsquare packages which need care -- so I hope to be able to update this one as well in decent times with the new upstream version. Ludovico -- l...@dovi.coIRC: garden@freenode OpenPGP: 1024D/63D2D5D907F89BB8 Jabber/gtalk: garde...@gmail.com -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629026: src:kernel-patch-viewos: Only supports historic kernels
On Sun, Jan 15, 2012 at 11:22:31 +0100, Ansgar Burchardt wrote: Moritz Muehlenhoff reported in June 2011 that kernel-patch-viewos only supports old kernels up to 2.2.26-rc6. As the package was not updated since then, I am wondering if it should be removed from Debian. We need indeed to package the latest upstream which includes support up to 3.1.5 (as of today). If there are no objections, I'll request removal in about two weeks. Please don't request the removal, we'll try to make the upload ASAP. Thank you, Ludovico -- l...@dovi.coIRC: garden@freenode OpenPGP: 1024D/63D2D5D907F89BB8 Jabber/gtalk: garde...@gmail.com -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#610933: [Pkg-vsquare-devel] Bug#610933: libvdeplug3 declares a conflict with libvdeplug2
Hello, On Mon, Jun 20, 2011 at 23:43:03 -0500, Jonathan Nieder wrote: Ping? I've had vde2 on hold because of this bug for several months now. IMHO if the package in experimental is not being maintained, it should be removed --- it will still be available from snapshot.debian.org. Thanks for the report and sorry for the delay. Indeed the conflict will be needed with the next release, as we're much probably going to move libvdeplug.so from the -dev package to the shared library one (since several virtualization tools which use VDE call dlopen with the non-versioned name, see #536373 for example). VDE version 2.3.2 is going to be released soon in unstable. Ludovico -- l...@dovi.coIRC: garden@freenode OpenPGP: 1024D/63D2D5D907F89BB8 Jabber/gtalk: garde...@gmail.com -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#610933: [Pkg-vsquare-devel] Bug#610933: libvdeplug3 declares a conflict with libvdeplug2
On Mon, Nov 28, 2011 at 05:34:31 -0600, Jonathan Nieder wrote: Indeed the conflict will be needed with the next release, as we're much probably going to move libvdeplug.so from the -dev package to the shared library one That violates policy §8.1 Run-time shared libraries and would make smooth upgrades of packages that use the shared library difficult. I understand that putting a .so symlink, in general, is against the policy. Yet I saw this sentence at the beginning of chapter 8: [...] the bare .so symlink is installed in the development package since it's only used when linking binaries or shared libraries. However, there are some exceptions for unusual shared libraries or for shared libraries that are also loaded as dynamic modules by other programs. This is the case with libvdeplug: it's both linked at compile time and dlopen()ed at runtime, depending on the software which uses it. Do you think it would still be a policy violation? (In any case, I still can't figure out what should be the *proper* way for a program for dlopening a .so while providing the version number... should it loop over all the (infinite :-)) possible SONAMEs who offer compatibility for the needed interface version? (since several virtualization tools which use VDE call dlopen with the non-versioned name, see #536373 for example). Would it be possible to make a different package, such as vde2, provide the non-versioned symlink, and such packages depend on it? It would be unpractical to put the .so symlink in the vde2 package, since then the -dev one should depend on vde2 (if I'm not wrong). Should we create a tiny package with only a single symlink in it? I haven't checked yet how other packagers solved the problem, so maybe the solution already exists :-)... Thanks, Ludovico -- l...@dovi.coIRC: garden@freenode OpenPGP: 1024D/63D2D5D907F89BB8 Jabber/gtalk: garde...@gmail.com -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#527518: [Pkg-vsquare-devel] Bug#527518: umview: FTBFS: Cannot find linux/dirent.h
tags 527518 + upstream pending thanks On Sat, Jun 06, 2009 at 18:36:11 -0500, Elías A. M. wrote: Add my patch. This issue has already been fixed in the SVN upstream. I'm working on the upstream release; as soon as it's done (maybe today?) I'll also make the correseponding Debian package. Thanks for your patch. :-) Ludovico -- gar...@acheronte.it#acheronte (irc.freenode.net) ICQ: 64483080 GPG ID: 07F89BB8 Jabber: garde...@gmail.com Yahoo: gardenghelle -- This is signature nr. 5059 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#490331: mm3d: FTBFS: checking Qt OpenGL... failure
On Fri, Jul 11, 2008 at 02:34:20PM +0200, Lucas Nussbaum wrote: During a rebuild of all packages in sid, your package failed to build on i386. Since nobody acted in a few months, I'm proposing here a patch for a NMU that fixes FTBFS on both architectures. As pointed out by Peter, mm3d moved to QT4, yet the Build-Dependencies are still stuck on QT3. I changed it to QT4. Moreover, older versions of libqt depended on a bunch of X11 libraries, that are linked both during the configure phase and the make phase of the package. Newer versions of libqt4-dev don't depend on that packages anymore, so I had to add explicit dependencies in the control file. I'm not sure if they're all needed now (dh_shlibdeps complains about useless dependancies), as some of them may had to be included only for satisfying libqt3 dependencies, but removing library deps from the configure and the Makefiles is a bit too invasive for a NMU so I chose to leave potentially useless dependencies and don't have to re-run autoconf/automake. I'm asking my AM to sponsor a delayed upload for this NMU. Ludovico -- [EMAIL PROTECTED]#acheronte (irc.freenode.net) ICQ: 64483080 GPG ID: 07F89BB8 Jabber: [EMAIL PROTECTED] Yahoo: gardenghelle -- This is signature nr. 4591 diff -u mm3d-1.3.7/debian/control mm3d-1.3.7/debian/control --- mm3d-1.3.7/debian/control +++ mm3d-1.3.7/debian/control @@ -2,7 +2,7 @@ Section: graphics Priority: optional Maintainer: Gürkan Sengün [EMAIL PROTECTED] -Build-Depends: debhelper (= 5), autotools-dev, libqt3-mt-dev +Build-Depends: debhelper (= 5), autotools-dev, libqt4-dev, libqt4-opengl-dev, libice-dev, libsm-dev, libx11-dev, libxext-dev, libxi-dev, libxmu-dev, libxt-dev Standards-Version: 3.8.0 Homepage: http://www.misfitcode.com/misfitmodel3d/ diff -u mm3d-1.3.7/debian/changelog mm3d-1.3.7/debian/changelog --- mm3d-1.3.7/debian/changelog +++ mm3d-1.3.7/debian/changelog @@ -1,3 +1,12 @@ +mm3d (1.3.7-1.1) unstable; urgency=low + + * Non-maintainer upload. + * Fix FTBFS bug due to wrong Build-Depends -- still QT3 but new upstream +moved to QT4. Maybe added some useless deps, but this should be fixed +upstream. (Closes: #490331) + + -- Ludovico Gardenghi [EMAIL PROTECTED] Mon, 20 Oct 2008 01:05:15 +0200 + mm3d (1.3.7-1) unstable; urgency=low * New upstream version. signature.asc Description: Digital signature
Bug#485752: dogtail: [DoS] use of /tmp/dogtail prevents use by multiple users
On Wed, Jun 11, 2008 at 10:18:29AM +0200, Yann Dirson (Debian) wrote:
Dogtail systematically create logfiles in /tmp/dogtail/. The 1st user to
run a script using dogtail (including the sniff gui) wins, and no other
user can use dogtail any more until that dir is manually removed.
The path for logfiles and datafiles can be set using the scratchDir,
logDir and dataDir in any configuration file.
However, using a (partially predictable) default under /tmp can lead to
security issues, so here I propose a patch to change the default to:
$HOME/dogtail/
if the HOME environment variable is defined, and to
/tmp/dogtail-username/
if the HOME variable is not set.
Just my 0.02${CURRENCY}.
Ludovico
--
[EMAIL PROTECTED]#acheronte (irc.freenode.net) ICQ: 64483080
GPG ID: 07F89BB8 Jabber: [EMAIL PROTECTED] Yahoo: gardenghelle
-- This is signature nr. 4524
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#485752: dogtail: [DoS] use of /tmp/dogtail prevents use by multiple users
Ahem. *Here* is the patch. :-)
Ludovico
--
[EMAIL PROTECTED]#acheronte (irc.freenode.net) ICQ: 64483080
GPG ID: 07F89BB8 Jabber: [EMAIL PROTECTED] Yahoo: gardenghelle
-- This is signature nr. 4525
diff -ur dogtail-0.6.1/dogtail/config.py dogtail-0.6.1.new/dogtail/config.py
--- dogtail-0.6.1/dogtail/config.py 2006-09-21 19:21:28.0 +0200
+++ dogtail-0.6.1.new/dogtail/config.py 2008-09-25 21:36:44.0 +0200
@@ -13,6 +13,15 @@
def _encoding():
return locale.getpreferredencoding().lower()
+def _homeDirOrNamedTmp(baseName):
+if 'HOME' in os.environ:
+# i.e. /home/foo/dogtail
+return '/'.join((os.environ['HOME'], baseName))
+else:
+# i.e. /tmp/dogtail-foo
+return '-'.join(('/'.join(('/tmp', baseName)), os.getlogin()))
+
+
class _Config(object):
Contains configuration parameters for the dogtail run.
@@ -100,12 +109,15 @@
__scriptName = staticmethod(_scriptName)
__encoding = staticmethod(_encoding)
+__homeDirOrNamedTmp = staticmethod(_homeDirOrNamedTmp)
+
+
defaults = {
# Storage
-'scratchDir' : '/tmp/dogtail/',
-'dataDir' : '/tmp/dogtail/data/',
-'logDir' : '/tmp/dogtail/logs/',
+'scratchDir' : '/'.join((_homeDirOrNamedTmp('dogtail'), '')),
+'dataDir' : '/'.join((_homeDirOrNamedTmp('dogtail'), 'data', '')),
+'logDir' : '/'.join((_homeDirOrNamedTmp('dogtail'), 'logs', '')),
'scriptName' : _scriptName(),
'encoding' : _encoding(),
'configFile' : None,
