Re: Libfuse interoperability/ABI broken.
On 3/11/24 14:32, Andrea Bolognani wrote: > On Thu, Mar 07, 2024 at 07:47:23PM +0100, Bernd Schubert wrote: >> Hi all, >> >> this is certainly not kind of the mail I was hoping for as a new libfuse >> maintainer. >> >> As you can see from the title and from discussion below (sorry this is >> not typical ML discussion style), we have a bit of of problem with >> libfuse ABI compatibility. > > [...] > >>>> On 3/7/24 16:43, Ashley Pittman wrote: >>>>> I’ve spotted an issue with the linked commit, the fuse_file_info struct >>>>> should have been modified by adding new entries just before the padding, >>>>> with this commit then members after the new entry will be moved creating >>>>> a change in the ABI for members after this. >>>>> >>>>> https://github.com/libfuse/libfuse/commit/a5eb7f2a0117ab43119ef5724cf5f4f2f181804a >>>>> >>>>> This affects the flush, nonseekable, flock_release, cache_readdir and >>>>> noflush flags, each one of which could be set or cleared accidentally >>>>> with one of the flags before or after it depending on what version of >>>>> libfuse the application is compiled and linked with. >>>>> >>>>> This isn’t a failure mode that I’ve experience before when using linux so >>>>> I don’t have a playbook to work from in how to correct this but >>>>> essentially fuse3 releases up to and including 3.13 have one ABI and 3.13 >>>>> to 3.16 have a different ABI. > > Not strictly related to the change at hand, but since we're > discussing recent-ish changes that negatively affected backwards > compatibility in libfuse I will mention this too: > > https://bugs.debian.org/1031802 > > It has been reported downstream a year ago, but I'm not sure if it > ever got upstream's attention. Now it should have :) > Arg thanks, I don't think that was ever posted. Clearly my fault, I had added that symbol when I noticed it is missing. Going to follow up in the debian report. Thanks, Bernd
Re: Libfuse interoperability/ABI broken.
Hi Amir,
thanks for your help!
On 3/9/24 03:46, Amir Goldstein wrote:
> On Thu, Mar 7, 2024 at 8:47 PM Bernd Schubert
> wrote:
>>
>> Hi all,
>>
>> this is certainly not kind of the mail I was hoping for as a new libfuse
>> maintainer.
>>
>> As you can see from the title and from discussion below (sorry this is
>> not typical ML discussion style), we have a bit of of problem with
>> libfuse ABI compatibility.
>>
>> While scanning through git history, Ashley found a commit that was adding
>> members in the middle of struct - doesn't break API, but binary
>> compatibility. That commit already landed a year ago in these releases:
>>
>> git tag --contains a5eb7f2a0117ab43119ef5724cf5f4f2f181804a
>> fuse-3.14.1
>> fuse-3.15.0
>> fuse-3.15.1
>> fuse-3.16.1
>> fuse-3.16.2
>>
>>
>> Obviously this needs improved testing for, but right now we wonder what
>> would be the preferred action to avoid issues.
>>
>> a) We could fix it and move bits to the right place. Fixes everything
>> compiled with old versions, but breaks everything compiled with the
>> versions above
>>
>> b) Increase the .so version - enforces recompilation of all binaries.
>> Intrusive, especially for distributions, but probably safest.
>>
>> c) Other ideas?
>>
>
> Heuristically, you can detect most of the shifted flags at runtime
> because...
>
>>
>>
>> I don't think there is anything in libfuse that would allow us to
>> detect which version of libfuse a library was linked to.
>>
>
> I think we do know for sure if fs was linked with libfuse < 3.12
> without fuse_loop_mt_312?
> so only left to detect 3.12..3.14 vs. 3.14..3.16
Hmm, I guess I miss something, but how would I know if it was linked
with fuse_loop_mt_312? That needs an elf reader? Assuming we would put
this into the library, somehow, how does this work with stripped binaries?
bschubert2@imesrv6 example>nm passthrough_ll | head -n1
03b4 r __abi_tag
bschubert2@imesrv6 example>strip passthrough_ll
bschubert2@imesrv6 example>nm passthrough_ll | head -n1
nm: passthrough_ll: no symbols
>
>>
>> The commit shifted these members in struct fuse_file_info {
>>
>> struct fuse_file_info {
>> ...
>> /** Can be filled by open/create, to allow parallel direct writes on
>> this
>> * file */
>> unsigned int parallel_direct_writes : 1; --> introduced the shift
>
> Not expected in flush/release, so can be heuristically interpreted as flush
>
>>
>> /** Indicates a flush operation. Set in flush operation, also
>> maybe set in highlevel lock operation and lowlevel release
>> operation. */
>> unsigned int flush : 1;
>>
>
> Not expected in open/create, so can be heuristically interpreted as
> nonseekable
>
>> /** Can be filled in by open, to indicate that the file is not
>> seekable. */
>> unsigned int nonseekable : 1;
>>
>
> Not expected in release, so can be heuristically interpreted as flock_release
>
>> /* Indicates that flock locks for this file should be
>>released. If set, lock_owner shall contain a valid value.
>>May only be set in ->release(). */
>> unsigned int flock_release : 1;
>>
>
> Not expected in opendir, so can be heuristically interpreted as cache_readdir
>
>> /** Can be filled in by opendir. It signals the kernel to
>> enable caching of entries returned by readdir(). Has no
>> effect when set in other contexts (in particular it does
>> nothing when set by open()). */
>> unsigned int cache_readdir : 1;
>>
>
> Ignored in open, but based on the comment above, it may be
> implied that some fs may set it in open() reply
>
>> /** Can be filled in by open, to indicate that flush is not needed
>> on close. */
>> unsigned int noflush : 1;
>
> noflush is just an optimization, which the kernel ignores anyway
> when writeback cache is enabled, so no harm done if it is wrongly
> interpreted as readdir_cache in open() and ignored.
> It is also quite recent (3.11) so not very likely used.
>
>> };
>>
>> I.e. setting flush would actually set parallel_direct_writes
>> (note: with binaries compiled against older libfuse versions)
>>
>
> It would be suspicious if fs sets parallel_direct_writes flush at
> flush() or release(), so that can be used as a hint of old ABI
> interpr
Re: Libfuse interoperability/ABI broken.
Hi all,
this is certainly not kind of the mail I was hoping for as a new libfuse
maintainer.
As you can see from the title and from discussion below (sorry this is
not typical ML discussion style), we have a bit of of problem with
libfuse ABI compatibility.
While scanning through git history, Ashley found a commit that was adding
members in the middle of struct - doesn't break API, but binary
compatibility. That commit already landed a year ago in these releases:
git tag --contains a5eb7f2a0117ab43119ef5724cf5f4f2f181804a
fuse-3.14.1
fuse-3.15.0
fuse-3.15.1
fuse-3.16.1
fuse-3.16.2
Obviously this needs improved testing for, but right now we wonder what
would be the preferred action to avoid issues.
a) We could fix it and move bits to the right place. Fixes everything
compiled with old versions, but breaks everything compiled with the
versions above
b) Increase the .so version - enforces recompilation of all binaries.
Intrusive, especially for distributions, but probably safest.
c) Other ideas?
I don't think there is anything in libfuse that would allow us to
detect which version of libfuse a library was linked to.
The commit shifted these members in struct fuse_file_info {
struct fuse_file_info {
...
/** Can be filled by open/create, to allow parallel direct writes on
this
* file */
unsigned int parallel_direct_writes : 1; --> introduced the shift
/** Indicates a flush operation. Set in flush operation, also
maybe set in highlevel lock operation and lowlevel release
operation. */
unsigned int flush : 1;
/** Can be filled in by open, to indicate that the file is not
seekable. */
unsigned int nonseekable : 1;
/* Indicates that flock locks for this file should be
released. If set, lock_owner shall contain a valid value.
May only be set in ->release(). */
unsigned int flock_release : 1;
/** Can be filled in by opendir. It signals the kernel to
enable caching of entries returned by readdir(). Has no
effect when set in other contexts (in particular it does
nothing when set by open()). */
unsigned int cache_readdir : 1;
/** Can be filled in by open, to indicate that flush is not needed
on close. */
unsigned int noflush : 1;
};
I.e. setting flush would actually set parallel_direct_writes
(note: with binaries compiled against older libfuse versions)
For the high level API it is probably less critical, in struct fuse_config
these fields are shifted:
struct fuse_config {
...
/**
* Allow parallel direct-io writes to operate on the same file.
*
* FUSE implementations which do not handle parallel writes on
* same file/region should NOT enable this option at all as it
* might lead to data inconsistencies.
*
* For the FUSE implementations which have their own mechanism
* of cache/data integrity are beneficiaries of this setting as
* it now open doors to parallel writes on the same file (without
* enabling this setting, all direct writes on the same file are
* serialized, resulting in huge data bandwidth loss).
*/
int parallel_direct_writes;
/**
* The remaining options are used by libfuse internally and
* should not be touched.
*/
int show_help;
char *modules;
int debug;
};
I don't think there is a security concern, but probably more a
data safety issue. So I included open mailing lists.
Thanks,
Bernd
On 3/7/24 19:02, Ashley Pittman wrote:
>
> Simply bumping the .so number and forcing a rebuild would certainly work. It
> would probably be the safest option but also put the highest cost on users,
> although I think for this kind of bug then a manual step of verifying the
> versions are correct is needed so forcing a build failure isn’t a bad option.
> It would massively increase the visibility if this if nothing else.
>
> Perhaps we should bring in the distro package maintainers here for their
> guidance/input? Like I say I’ve not had experience of this type of issue
> before but I’m sure the distros will have.
>
> Ashley.
>
>> On 7 Mar 2024, at 16:05, Bernd Schubert wrote:
>>
>> Hi Ashley,
>>
>> thanks for spotting and embarrassing as I had been involved in
>> development that feature.
>>
>> Hard to decide if revert it right - issue is, if we revert, everything
>> linked with the new version would broken as well. And it is now already
>> a year...
>>
>> I think we can only increase the .so version and send out a warning
>> (mailing list, distributions).
>>
>> In order to avoid it in the future, we can probably add some compile
&
Accepted unionfs-fuse 1.0-1 (source amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 12 Jul 2015 20:14:57 +0200 Source: unionfs-fuse Binary: unionfs-fuse Architecture: source amd64 Version: 1.0-1 Distribution: unstable Urgency: medium Maintainer: Bernd Schubert bernd.schub...@fastmail.fm Changed-By: Bernd Schubert bernd.schub...@fastmail.fm Description: unionfs-fuse - Fuse implementation of unionfs Closes: 614771 742033 778156 Changes: unionfs-fuse (1.0-1) unstable; urgency=medium . * New upstream release * Fix extended attributes (Closes: #742033) * New option for relaxed permissions (-o relaxed_permissions) (Closes: #614771) * Fix gcc-5 compilation (Closes: #778156) * Don't primarily use unionfs-fuse anymore, but just 'unionfs'. The name clash I was afraid of never happened, there is no other program called unionfs. For debian compatibility create a symlink unionfs-fuse - unionfs * lintian fixes (BSD license file, compiler flags) Checksums-Sha1: 8a3ca59b20d1e1b3a6126a6ef7b408eaab432e80 1764 unionfs-fuse_1.0-1.dsc f35e5a3f0e033291981766f50cd9895d23fae649 48149 unionfs-fuse_1.0.orig.tar.gz 84f66e0d53f707deb3376c92ee0ccae108d0a679 5536 unionfs-fuse_1.0-1.debian.tar.xz cecd3041eaa197d1955cdda9c7b690ece667e259 45530 unionfs-fuse_1.0-1_amd64.deb Checksums-Sha256: afc2d2a1ec278c51fb3281058150da23108eaf0e1553d6a893347ca19ad859f5 1764 unionfs-fuse_1.0-1.dsc 2ee80bd0634a61adb2159212e155d607a0a82ad659214ae6edb353039609 48149 unionfs-fuse_1.0.orig.tar.gz d76b145ce439615c4574637959b5945aa4fcb6ebe3d8da034b8e419b0bb77062 5536 unionfs-fuse_1.0-1.debian.tar.xz 604c6f7971d5294da623e99862bf9ba4209f8167b91191be69b6f991b3fd201d 45530 unionfs-fuse_1.0-1_amd64.deb Files: 1e11393477be0d48ee310c0a0555eebf 1764 misc optional unionfs-fuse_1.0-1.dsc 598590fb452129c413572ed79824c68a 48149 misc optional unionfs-fuse_1.0.orig.tar.gz 5497726788d9eb5a6836a428883ec042 5536 misc optional unionfs-fuse_1.0-1.debian.tar.xz 494dbada8b69bf7a5e77644e0a794649 45530 misc optional unionfs-fuse_1.0-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJVpntZAAoJED0Hh6qvbGHdwI0QAKHfM8DRn980sB6SWIBZfAw9 41kLxekHmhpA+6NoiJ1lFIYDjhZWVSe7r1OzPcGm7gjK1xL9B9WpuIvVRafLQy7e zzl7GcqcMEP5+/M+A0iG8y2PKkC7b8eexaSJx959BTCNBbNyb0p0O7vtcm845vf9 NAo7I+KBkmcr6vVe3pccIKhK6w4j+Jr0/04AoPjWg6L5Uy1u+G50nMy/zWfDR9o3 bXF8C/COEr8Zllnrw6kHdzwkkCYQcABcBvowg/u++CjToFBUTcohXugvDCmNVNCl qNxqcllXXrdjLfCltcodK1fqeQpjGHnvC2SqkEoqO6zz5I3AbtvOP+Z7YtTtiEjI Zvh1qgt+awlxZd7L6Cz7lTTb2syNK9nWtybXJl0wRcicPqZhghvH6FdbU6d+UgDb dOvXgL1K9YavpSzH6Z1tikMqEWhguHZF0wZOfdccC/yQzH1ucQgd3lPf+Ll6Srck P2sEiDOVGwOSq0gkTsjVZW0+NKk9AD4sXdAmVSt0nnB0Xn7oBbLy3I63EPeZffRI p9Iw98ulCEGq4IPzX20hZP3/l3R1BKVHQfGxPtg0/Yi9EaNcDc4hXSejuGSQGKMB vIgw9GDGYDmRXVgMvTS1VgM6fqOVp7EAzgQkFI+ohShca57Ys8FHqhoDvvWqj7cO GckgDGmYtHp95G4OTPo2 =E/p+ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1zfoow-0004hp...@franck.debian.org
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On 07/19/2013 06:43 PM, John Paul Adrian Glaubitz wrote: On 07/19/2013 05:43 PM, Thomas Goirand wrote: We try to have technical reasoning, which is (one of) the reason this list exists. This has nothing to do with voting. If we actually did, the choice would have already been made for systemd long time ago. Don't make yourself any illusions. It has been explained to you by many people before that OpenRC isn't fit for the purpose at all and I really don't think upstart will meet the criteria either. I thought we were making software which is to be useful for our users in the end,... That is the case, but not using popcon as a metric to our technical decisions. Well, technical reasons are obviously not counted in. ...but it turns out that according to your line of arguments, Debian is primarily made to fuel the egos of its developers. Now you are crossing the line. No, I am not. How often do I have to read people claiming that systemd is a bad project because they don't like their upstream authors? Honestly, I do not care about upstream at all, but I'm still concerned about systemd (as well as about upstart). I had sufficient issues with upstart before - stopping to boot and not telling about its current state is from my point of view a show-stopper. And from my point of view it is irrelevant if there are underlying bugs. Important is that it helps the admin to figure out what went wrong and how this can be solved or worked-around. So upstart leaves a mostly blank screen without a console. What is systemd going to do if something fails? How does it help me if it crashes? How am I'm going to bring up a basic system then. Thanks, Bernd -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51e97c73.8070...@aakef.fastmail.fm
Re: using upstart in Debian [was, Re: Debian systemd survey]
On 05/22/2013 06:19 PM, Steve Langasek wrote: On Wed, May 22, 2013 at 03:39:00PM +0200, Bernd Schubert wrote: On 05/22/2013 04:50 AM, Uoti Urpala wrote: Lucas Nussbaum wrote: I went through the various init systems threads again during the last few days. My understanding of the consensus so far is the following: - Both systemd and upstart bring many useful features, and are a clear improvement over sysvinit. Yes, both are an improvement over sysvinit. Hrmm, I have not tested systemd yet, but personally I'm not conviced about the advantages of upstart: - Stops booting *somtimes*, does not provide any information why. I didn't report a bug yet as an almost black screen won't help in any way how to figure out why it stopped. Already that stops without any further information why and where is a sufficiently big design issue, imho. (Btw, in the mean time I belive this issue is related to /etc/mtab, but I'm not sure yet.). Sorry you ran into trouble with upstart. Probably related to /etc/fstab, rather than /etc/mtab... Due to incomplete upstart integration of plymouth in Debian at present, if there are problems in /etc/fstab, mountall won't Well, actually this happens on 2 ubuntu systems. always be able to display any prompt to the user asking what to do (cf. http://web.dodds.net/~vorlon/wiki/blog/Plymouth_is_not_a_bootsplash/). I really meant mtab. After the issue appeared last time again and didn't go away on reboots, I booted into recovery shell and noticed that 'mount -a' didn't do anything. Remouting / rw, deleting /etc/mtab solved it, also on reboots. I now linked /proc/self/mtab to /etc/mtab and that solved it. Might not be an upstart bug at all, but I'm mainly complaining here that upstart does not provide any way to figure out what it is currently waiting for. Just opening a shell after some time and writing something like waiting on XXX to proceed with ... probably would be sufficient. Without any logs, screen output and no way to investigate it just gives the feeling that one now needs to re-install the system, similar to another famous OS . Whereas sysvinit would eventually give up on trying to mount filesystems in /etc/fstab if they were missing at boot and continue booting without them, upstart takes the design decision that this is an error that the admin needs to deal with directly. This ensures that the system always boots reliably in the face of slow disks, which become more of a problem now that your init system is so fast that it can boot before your hardware has been probed. Feel free to file a bug report against the upstart package (with a copy of your /etc/fstab attached) so we can look at this further. - Updating/install programs in a chroot fails with weird messages that those programs (afaik for example X) cannot connect to upstart. Well, it is a chroot, what does it expect? This is bug #685779, which will be fixed in the next upload of sysvinit to unstable. - Personally I'm using unionfs-fuse as very first init script to mount /etc and /var and others on my development systems. So no need to modify an initrams, but a very simple approach and controllable using a boot script. But specifying a script to be run *before* anything else is not possible (yet?). I'm skeptical of the value of such a design in place of just using an initramfs, but the 'friendly-recovery' package in Ubuntu gives an example of to do this. You create an upstart job that's 'start on real-startup-event', runs your necessary pre-setup, and at the end calls 'initctl emit startup' to call into the rest of the boot sequence; then you pass '--startup-event=real-startup-event' to init on the kernel commandline. Thanks, going to look into this. I also need to work on unionfs-fuse to properly work from an initramfs. The issue is just missing time for either of both... I also just wanted to point out that upstart is some way a regression. Thanks, Bernd -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/519f2d5e.2010...@fastmail.fm
Re: Debian systemd survey
On 05/22/2013 04:50 AM, Uoti Urpala wrote: Lucas Nussbaum wrote: I went through the various init systems threads again during the last few days. My understanding of the consensus so far is the following: - Both systemd and upstart bring many useful features, and are a clear improvement over sysvinit. Yes, both are an improvement over sysvinit. Hrmm, I have not tested systemd yet, but personally I'm not conviced about the advantages of upstart: - Stops booting *somtimes*, does not provide any information why. I didn't report a bug yet as an almost black screen won't help in any way how to figure out why it stopped. Already that stops without any further information why and where is a sufficiently big design issue, imho. (Btw, in the mean time I belive this issue is related to /etc/mtab, but I'm not sure yet.). - Updating/install programs in a chroot fails with weird messages that those programs (afaik for example X) cannot connect to upstart. Well, it is a chroot, what does it expect? - Personally I'm using unionfs-fuse as very first init script to mount /etc and /var and others on my development systems. So no need to modify an initrams, but a very simple approach and controllable using a boot script. But specifying a script to be run *before* anything else is not possible (yet?). Bernd -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/519cca74.9030...@aakef.fastmail.fm
Accepted unionfs-fuse 0.24-2 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 29 Jun 2010 21:28:22 +0200 Source: unionfs-fuse Binary: unionfs-fuse Architecture: source amd64 Version: 0.24-2 Distribution: unstable Urgency: low Maintainer: Bernd Schubert bernd.schub...@fastmail.fm Changed-By: Bernd Schubert bernd.schub...@fastmail.fm Description: unionfs-fuse - Fuse implementation of unionfs Closes: 509516 533403 541614 Changes: unionfs-fuse (0.24-2) unstable; urgency=low . * remove quilt dependency and quilt entries from debian/rules (Thanks to Martin Pitt for spotting this) * Fix debian/changelog, all recent bug numbers had missing '#' (Again thanks to Martin) . unionfs-fuse (0.24-1) unstable; urgency=low . * New upstream release * Add utimens.patch * Also close 509516, although the solution is not perfect yet (closes: #509516) * Switch to dpkg-source 3.0 (quilt) format . unionfs-fuse (0.23.hg.20100315-1) unstable; urgency=low . * Another update from my branch to merge with Radek and to update the test script . unionfs-fuse (0.23.hg.20090831-1) unstable; urgency=low . * another pull from my branch * fix relative pathes (closes: #541614) * inlcude patch from Goswin (closes: #533403) Checksums-Sha1: f3bb6142005b65e4cd80982070868a5cb7659996 1035 unionfs-fuse_0.24-2.dsc 26f281e4e5f1e82194b430956b94cd7745d5bd97 30381 unionfs-fuse_0.24.orig.tar.bz2 d4cd28a1e42cc8c6c57d22cee0d2d55a2105123a 5617 unionfs-fuse_0.24-2.debian.tar.gz a2fba41ac67efc60ee913ab5778c5f59a559b76a 28154 unionfs-fuse_0.24-2_amd64.deb Checksums-Sha256: 425634b2cb55867d5ba400eb142828a26de5d66e1be74cb89ba1f455c7db4b4b 1035 unionfs-fuse_0.24-2.dsc d8abc855eb618ac356b1e716599c82f8f0f74dbaee36d4062edc707567121937 30381 unionfs-fuse_0.24.orig.tar.bz2 4b894746e849573ca3dcd327a8903e8fff81296f2bb4a5ff959203a2c0960517 5617 unionfs-fuse_0.24-2.debian.tar.gz 7e428406f28c1f52da1a72047ab88788747b3b669d2582218ae17df23e24252a 28154 unionfs-fuse_0.24-2_amd64.deb Files: 590036eb3c727710fe559442fcafeabd 1035 misc optional unionfs-fuse_0.24-2.dsc ab00f252c55a9a7252fca13a53260bf5 30381 misc optional unionfs-fuse_0.24.orig.tar.bz2 005e5465095b5f2d8d141d3928559c04 5617 misc optional unionfs-fuse_0.24-2.debian.tar.gz 8f2a0d54fb455a2f69c8bd9206f4a227 28154 misc optional unionfs-fuse_0.24-2_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkwsWDYACgkQDecnbV4Fd/Kx1QCg7P0TMUYwRJ7lUtAC5/ghaw2+ 1IwAn0XcuZPqcG8KPutYHf+17u/AS/es =Ttoa -END PGP SIGNATURE- Accepted: unionfs-fuse_0.24-2.debian.tar.gz to main/u/unionfs-fuse/unionfs-fuse_0.24-2.debian.tar.gz unionfs-fuse_0.24-2.dsc to main/u/unionfs-fuse/unionfs-fuse_0.24-2.dsc unionfs-fuse_0.24-2_amd64.deb to main/u/unionfs-fuse/unionfs-fuse_0.24-2_amd64.deb unionfs-fuse_0.24.orig.tar.bz2 to main/u/unionfs-fuse/unionfs-fuse_0.24.orig.tar.bz2 -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1oug9m-0006sy...@ries.debian.org
Re: Allowing QA uploads for DMs (was: A lot of pending packages)
On Wednesday 16 June 2010, Tim Retout wrote: On 15 June 2010 21:59, Neil Williams codeh...@debian.org wrote: Encouraging maintainers to invest their time in QA makes more sense than adding more NEW packages to become the QA workload of the future. Directing everyone at NEW is counter-productive and encourages more horrible first-time packages. I agree entirely with this goal - I'm not yet certain that allowing unrestricted QA uploads by DMs will solve that problem, although I wouldn't be against testing it out. For starters, it could only really be allowed for DMs, not any old packager, I think. So would this produce results among normal mentees? My understanding was that some DMs are interested only in the packages they already maintain, otherwise they would be in the NM queue - so this subset would be less likely to bother with orphaned packages, surely? As for the others... if the act of allowing unrestricted QA uploads would spur them to make lots of fixes, why do we not see DDs doing this all the time? There also some package maintainers such as I am, who simply do not have the time to go through the NM queue. And no, I won't even think about to adapt orphan packages, I already don't get packages I'm interested in through mentors. Fortunately, Martin Pitt now wants to help me to upload unionfs-fuse. I was already close to send a mail to this list requesting to remove this package from Debian. IMHO, it is wrong to list me as Maintainer, if it impossible to maintain it... Cheers, Bernd -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201006170342.20269.bernd.schub...@fastmail.fm
Re: Bug#535233: ITP: collectl -- Initial package request
Hello Christopher, On Wednesday 01 July 2009, Simmons, Christopher wrote: Package: collectl Version: 3.3.4 Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org *** Please type your report below this line *** I wish to work on creating a debian package for collectl-3.3.4 I already have a package, just didn't have the time yet to upload it. http://www.pci.uni-heidelberg.de/tc/usr/bernd/downloads/collectl/ This also includes some patches from Goswin. Cheers, Bernd -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted unionfs-fuse 0.23.hg.20090611-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 11 Jun 2009 20:42:41 +0200 Source: unionfs-fuse Binary: unionfs-fuse Architecture: source i386 Version: 0.23.hg.20090611-1 Distribution: unstable Urgency: low Maintainer: Bernd Schubert bernd.schub...@fastmail.fm Changed-By: Bernd Schubert bernd.schub...@fastmail.fm Description: unionfs-fuse - Fuse implementation of unionfs Closes: 496794 511047 511157 511446 530214 Changes: unionfs-fuse (0.23.hg.20090611-1) unstable; urgency=low . * another pull from my branch * change my maintainer mail address . unionfs-fuse (0.23.hg.20090601-2) unstable; urgency=low . * set DH_COMPAT to 7 * fix several lintian packaging errors . unionfs-fuse (0.23.hg.20090601-1) unstable; urgency=low . * new upstream release * pull from my branch to include everything that is supposed to be in 0.24 (http://podgorny.cz/~bernd/hg/hgwebdir.cgi/radek-trunk-bernd-merge) * (closes: #496794) * (closes: #530214) * (closes: #511157) * new option -o statfs_omit_ro (closes: #511446) * man page updated if -o cow (is not specified closes: #511047) * partly fixes bug #509516, I leave that bug open, since only fixed for one rw branch Checksums-Sha1: 5a1b68c32b6c8721088af97d163de0ee2df59c74 1109 unionfs-fuse_0.23.hg.20090611-1.dsc a5601696491ea67037a28fbbbf0826db54c6def1 400988 unionfs-fuse_0.23.hg.20090611.orig.tar.gz afd40bfb0103d25b78b0b8085718b6e24dd978de 4311 unionfs-fuse_0.23.hg.20090611-1.diff.gz 0f522c88147aac121f00db1f647a4caa9898d712 25036 unionfs-fuse_0.23.hg.20090611-1_i386.deb Checksums-Sha256: cc7434892c17dbe57df4f6db4a0d74e16f155bbca49e605397cad00ea72abc05 1109 unionfs-fuse_0.23.hg.20090611-1.dsc dc9bf416e8c7607ce79c98cefe20bb3849471eb8c5bdc55d29305f19ae9b5ba8 400988 unionfs-fuse_0.23.hg.20090611.orig.tar.gz 07a2876915565743d130d8bc89c1f643ca467b2055a2165069c1659f236e3ebb 4311 unionfs-fuse_0.23.hg.20090611-1.diff.gz 0ee620fae0358e3914ff1f19c9e4832241a2f7cb3617fa1945b1582590dccecc 25036 unionfs-fuse_0.23.hg.20090611-1_i386.deb Files: d6d9471aab099921526d2493078a1f4c 1109 misc optional unionfs-fuse_0.23.hg.20090611-1.dsc ef22576e66c7c837a1dcbc7dafc71af4 400988 misc optional unionfs-fuse_0.23.hg.20090611.orig.tar.gz 89fbea0b7e242ed6005c2b79d5637696 4311 misc optional unionfs-fuse_0.23.hg.20090611-1.diff.gz 851e2074f250d4586f0a79425ce1af98 25036 misc optional unionfs-fuse_0.23.hg.20090611-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkpKcskACgkQDecnbV4Fd/K6cQCeOc2x/QKLdhaW4XRbUPNaqVdS UW8An39morKTiXsfg9I3BqT5uGGHpBLl =de7G -END PGP SIGNATURE- Accepted: unionfs-fuse_0.23.hg.20090611-1.diff.gz to pool/main/u/unionfs-fuse/unionfs-fuse_0.23.hg.20090611-1.diff.gz unionfs-fuse_0.23.hg.20090611-1.dsc to pool/main/u/unionfs-fuse/unionfs-fuse_0.23.hg.20090611-1.dsc unionfs-fuse_0.23.hg.20090611-1_i386.deb to pool/main/u/unionfs-fuse/unionfs-fuse_0.23.hg.20090611-1_i386.deb unionfs-fuse_0.23.hg.20090611.orig.tar.gz to pool/main/u/unionfs-fuse/unionfs-fuse_0.23.hg.20090611.orig.tar.gz -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: xcdroast does no longer work with wodim: Who to blame?
On Monday 02 March 2009, Michelle Konzack wrote: Am 2009-03-02 06:23:26, schrieb Goswin von Brederlow: Since everything seems to be dumping core on your system have you thought about the possibility that it might be your system that is at fault? Such a widespread range of coredumps usualy means one of the core libraries is corrupted on your filesystem or you have faulty ram. Or maybe a root-kit that breaks things? Since the release of Lenny, I have installed arround 60 Workstaions, but making tararchives of the original installation and reinstalled Lenny from scratch, using the first binary DVD and the rest over Net. Nearly 80% of all Workstations do not work properly. Maybe you should start to test Debian-Testing from time to time and report bugs if something doesn't work for you? Just complaining *after* a release isn't really helpful. The half of them is without sound (all Creative LABS) 00:13.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 0a) 00:13.1 Input device controller: Creative Labs SB Live! Game Port (rev 0a) What exactly is the problem? Kernel related? If so try a more recent kernel version or an older version and then report a bug. which is needed for telephony. Then I have a couple of Dual-Screen Workstations with the above card... 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400/G450 (rev 82) xserver-xor-video-mga does not work... Now I use the framebuffer which is working nicely but I do not know the performance differnce between mga and 2fbdev. The mga driver never worked properly without its binary blob if you wanted more then a single vga connection. Don't know what the situation is now, maybe matrox doesn't provide a recent binary for Lenny's xorg version. If you want, go ahead and check yourself on the matrox site. While Fvwm was working fine under Sarge and Etch, no it stoped working correctly. The first time afte 7 years. Again, test yourself before a release and write bugs. You are definitely not an ordinary helpless user, but you make extensive usage of free software. So the least you can do is to write bug reports. Maybe there is a new config option, but curently I have flying windows arround, I mean, news windows are placed in non-expected places. I want my message boxes ans such back in the center if I do not use explicit geometry. But it is going more strange, because my own GTK2+ application are placed correctly like the OpenOffice ones... I have set EWMH to reserve space for my FvwmButton (Panel) and the FvwmTaskbar but they are now ignored... While reading the huge manpages, nothing has changed... Sorry, no idea, I never liked fvwm. I Given that you only have the core-dumps since Lenny I would suspect something got scrambled during the upgrade. Some bit flipped somewhere. I was thinking this too, and have tared the broken installation like the Etch and Sarge ones and reinstalled the WHOLE thing from scratch. The error persists. Go ahead and check your installation with 'debsums'. Cheers, Bernd -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: xcdroast does no longer work with wodim: Who to blame?
On Monday 02 March 2009, Russell Coker wrote: On Mon, 2 Mar 2009, Bernd Schubert bernd.schub...@fastmail.fm wrote: Since the release of Lenny, I have installed arround 60 Workstaions, but making tararchives of the original installation and reinstalled Lenny from scratch, using the first binary DVD and the rest over Net. Nearly 80% of all Workstations do not work properly. Maybe you should start to test Debian-Testing from time to time and report bugs if something doesn't work for you? Just complaining *after* a release isn't really helpful. Bernd, I (with my DD or upstream developer hat on) understand your sentiment. But I also (with my consultant or end-user hat on) find it impossible to implement. You don't have any chroots, virtual machines and you don't run Sid at home? If I was running a large scale IT environment (say 1000+ users) then I would assign an increasing portion of the help-desk people to run testing as the release became closer and I would allow some of the user-base to run testing when the release was really close. Then after the release I would slowly increase the number of people running the new release so that bugs could be identified and fixed. If a bug hit the 1% of the user-base who were most adventurous and demanding of new versions then it wouldn't be so bad. Well, Michelle upgraded over 50 machines. At university I was admin of of group of also that number. We had chroots (for old-stable, testing and sid). Some users sometimes had to use one or another chroot to get some programs running. Since that also requires the basic libs are working, it is at least a basic test. On upgrades we always tried to migrate as few as possible workstations first (of course easy, when you have a diskless environment as we had/have). So when on the first system not everything runs smoothly we never would have upgraded the 2nd system. But however I'm not running a large IT environment and I don't have the resources for such things. Sometimes I do the upgrade after the release and just have to deal with some bugs. I don't know, maintaining a testing chroot is really simple, since you don't need to adjust a single configuration file within the chroot. Testing some software components from time there is also easy then. Cheers, Bernd -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#516096: ITP: libibumad -- OpenFabrics Alliance InfiniBand umad (user MAD) library
Guus Sliepen wrote: On Thu, Feb 19, 2009 at 10:31:43AM +, Guy Coates wrote: * Package name: libibumad Version : 1.2.3 Upstream Author : Voltaire, Inc. * URL : http://www.openfabrics.org I do not see a libibumad tarball there, I did find OFED-1.4.tgz which contained a SRPM for it... if this is the only way upstream distributes these libraries, please suggest to them that it is better if they publish normal tarballs. Hmm, that is the difficult part. There are individual packages and there is OFED. OFED is a collection of many packages, mostly not the recent version, but a more tested stable version. E.g. IB management packages can be found here: http://www.openfabrics.org/downloads/management/ I already wondered all the time, which would be better for Debian, the packages from OFED or the individual packages. IHMO, extracting all the srpms is a pain... Description : OpenFabrics Alliance InfiniBand umad (user MAD) library libibumad provides the user MAD library functions which sit on top of the user MAD modules in the kernel. These are used by the IB diagnostic and management tools, including OpenSM. I have absolutely no clue what this does, except that it has something to do with InfiniBand. What is MAD? What is OpenSM? What functionality does this library provide? Also drop OpenFabrics Alliance from the short description. If you want to mention it, do it in the long description. The problem is, there is nowhere a real description of what all these IB libraries are actually doing. MAD = management datagram. As far as I understand it, you need this library to send IB management packages from user space. OpenSM = open subnet manager. Each IB network needs at least one running subnet manager, which controls the routing between ports. From the man page of opensm: opensm provides an implementation of an InfiniBand Subnet Manager and Administration. Such a software entity is required to run for in order to initialize the InfiniBand hardware (at least one per each InfiniBand subnet). Guy, it is a bit a pity, since you did all the work again, we already had done at q-leap :( IMHO all these IB packages are too many for one maintainer, what do you think to make an alioth for these? Cheers, Bernd -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted unionfs-fuse 0.21-3 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sat, 24 Jan 2009 00:10:44 +0100 Source: unionfs-fuse Binary: unionfs-fuse Architecture: source amd64 Version: 0.21-3 Distribution: unstable Urgency: high Maintainer: Bernd Schubert bernd-schub...@gmx.de Changed-By: Bernd Schubert bernd-schub...@gmx.de Description: unionfs-fuse - Fuse implementation of unionfs Closes: 511158 511995 Changes: unionfs-fuse (0.21-3) unstable; urgency=high . * fixes critical buffer overflow on using relativ pathes * slightly improve the man page to tell people without -ocow not everything might work as expected * change binary path from /usr/sbin to /usr/bin * (closes: #511995) * (closes: #511158) Checksums-Sha1: 59e76d074c57771ab8685038b2b5294dae3b3ce4 1017 unionfs-fuse_0.21-3.dsc db94f993a4fd5c7433a226ca06b9ea4bb79794b0 5955 unionfs-fuse_0.21-3.diff.gz 09ee6735f2fd64b8f4154c0c134fea4860403f63 25104 unionfs-fuse_0.21-3_amd64.deb Checksums-Sha256: a5213ea738fcaf9a2afdfb61955374b174e22569ace57772c95c97edca922890 1017 unionfs-fuse_0.21-3.dsc a29f132b956a59fc66b160390e363661b8a90aa721268b30c75a5c44a82a4052 5955 unionfs-fuse_0.21-3.diff.gz 6ee43218b63a4bc8c8ab55f84052400330942d714057a224f0842f8dd8bc7d29 25104 unionfs-fuse_0.21-3_amd64.deb Files: efafe1707da1a12982d54ce894788dc1 1017 misc optional unionfs-fuse_0.21-3.dsc 66b4b644abcbcddf467341a9226f4ff9 5955 misc optional unionfs-fuse_0.21-3.diff.gz 2fef47f1aad19b4808b7860cedb78c05 25104 misc optional unionfs-fuse_0.21-3_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmHVTYACgkQx/UhwSKygsp7owCfVpqdsGfqawVoVbxsiRZWHJqg ycYAoIltarFhgDal+0t9jOB6v6nWj+Ta =zXu4 -END PGP SIGNATURE- Accepted: unionfs-fuse_0.21-3.diff.gz to pool/main/u/unionfs-fuse/unionfs-fuse_0.21-3.diff.gz unionfs-fuse_0.21-3.dsc to pool/main/u/unionfs-fuse/unionfs-fuse_0.21-3.dsc unionfs-fuse_0.21-3_amd64.deb to pool/main/u/unionfs-fuse/unionfs-fuse_0.21-3_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted keytouch 2.3.2-2.1 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 20 Aug 2008 22:24:27 +0200 Source: keytouch Binary: keytouch keytouch-data Architecture: source all amd64 Version: 2.3.2-2.1 Distribution: unstable Urgency: low Maintainer: Luis Rodrigo Gallardo Cruz [EMAIL PROTECTED] Changed-By: Bernd Schubert [EMAIL PROTECTED] Description: keytouch - A program to configure extra function keys in multimedia keyboard keytouch-data - keyboard definition files and documentation for keytouch Closes: 487629 Changes: keytouch (2.3.2-2.1) unstable; urgency=low . * Non-maintainer upload. * fix xsession shutdown problem * (closes: #487629) Checksums-Sha1: 927291d7b9283d1a02f01c9967655f22def345c2 1320 keytouch_2.3.2-2.1.dsc 12d6646e2e955b8a18faa14cabb2d6f3b887bce5 11338 keytouch_2.3.2-2.1.diff.gz de4ad18df51e7bcaa48a4a35a197e24b4ab2 290806 keytouch-data_2.3.2-2.1_all.deb ff3c36122648ecc2de19b97f6510ce4093af612d 174166 keytouch_2.3.2-2.1_amd64.deb Checksums-Sha256: 65a95742e73aeae556f5069fce54f3a7168aba6082331fd4229f7f52949172fd 1320 keytouch_2.3.2-2.1.dsc e6a116c3fc3114ae5e4caf9d2ce2908e75afdff49c86eab8da4a3be086441c71 11338 keytouch_2.3.2-2.1.diff.gz 41dd8fc299dd4d749b24cd1b40ab61791d24ba7558b1cfafc2b8e62162837c9d 290806 keytouch-data_2.3.2-2.1_all.deb 79eef72ee89a3e5c659676b6dee8be248f3e3a69466ea05933211c4beb662a07 174166 keytouch_2.3.2-2.1_amd64.deb Files: 278eff7ae8e29afd5b6a0574e37b1bda 1320 admin optional keytouch_2.3.2-2.1.dsc b6486d4289703e07801ad56a957a6550 11338 admin optional keytouch_2.3.2-2.1.diff.gz aa99bf11b7ccf500f435336b30b345cd 290806 admin optional keytouch-data_2.3.2-2.1_all.deb 90ac7cbb748e9ccc12f5d9f78d210718 174166 admin optional keytouch_2.3.2-2.1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAki2xR8ACgkQiAEJSii8s+PGvgCgo5YuuDpcW2eVYe5LL6q+NTD1 VvEAoLMHi3nMuDoxs1lfJMnVpLV9ZZno =r8Kd -END PGP SIGNATURE- Accepted: keytouch-data_2.3.2-2.1_all.deb to pool/main/k/keytouch/keytouch-data_2.3.2-2.1_all.deb keytouch_2.3.2-2.1.diff.gz to pool/main/k/keytouch/keytouch_2.3.2-2.1.diff.gz keytouch_2.3.2-2.1.dsc to pool/main/k/keytouch/keytouch_2.3.2-2.1.dsc keytouch_2.3.2-2.1_amd64.deb to pool/main/k/keytouch/keytouch_2.3.2-2.1_amd64.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted unionfs-fuse 0.21-2 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Mon, 11 Aug 2008 09:22:42 + Source: unionfs-fuse Binary: unionfs-fuse Architecture: source amd64 Version: 0.21-2 Distribution: unstable Urgency: high Maintainer: Bernd Schubert [EMAIL PROTECTED] Changed-By: Bernd Schubert [EMAIL PROTECTED] Description: unionfs-fuse - Fuse implementation of unionfs Closes: 495380 Changes: unionfs-fuse (0.21-2) unstable; urgency=high . * fix a critical bug: creating new files in directories existing only in read-only branches failed, since the directory path wasn't copied to the rw-branch * (closes: #495380) Checksums-Sha1: e4858bb44546ba825cbf9497c421c85d995ce631 1017 unionfs-fuse_0.21-2.dsc 3e877b4829733458fbac054de3ab90e1cacdbd12 4968 unionfs-fuse_0.21-2.diff.gz 7b92f0322e460a340dc5d884749e88a75a47f41c 24760 unionfs-fuse_0.21-2_amd64.deb Checksums-Sha256: 074de0e6d6575ee9fb6422ef5a40531b78d743f47c93b37ded1e737bfcd6ca61 1017 unionfs-fuse_0.21-2.dsc 148c4b21f9a874aa96d31cfa7925c0de6b760841f007c0eeaa2cbcf49bd1ffc9 4968 unionfs-fuse_0.21-2.diff.gz 8988e96c8f865eb0a1a80b79c6d83091c6a9effacb4b38549e5e6aa31b8dd613 24760 unionfs-fuse_0.21-2_amd64.deb Files: 92149e1c2e4b0ce82e3d5f17ea6fe9f9 1017 misc optional unionfs-fuse_0.21-2.dsc 2416d3d550b68da91032c7a56e2fe3ac 4968 misc optional unionfs-fuse_0.21-2.diff.gz a011d85dd230a855840be42cfb807cca 24760 misc optional unionfs-fuse_0.21-2_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEUEARECAAYFAki0MiwACgkQKFvXofIqeU6lyQCgoKdAwcUNdzPyMTj10HNRSc2e iDQAmKg4sFcECkio0qFA22JqXWTZITU= =Xk5X -END PGP SIGNATURE- Accepted: unionfs-fuse_0.21-2.diff.gz to pool/main/u/unionfs-fuse/unionfs-fuse_0.21-2.diff.gz unionfs-fuse_0.21-2.dsc to pool/main/u/unionfs-fuse/unionfs-fuse_0.21-2.dsc unionfs-fuse_0.21-2_amd64.deb to pool/main/u/unionfs-fuse/unionfs-fuse_0.21-2_amd64.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted unionfs-fuse 0.21-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sat, 26 Jul 2008 18:28:39 +0200 Source: unionfs-fuse Binary: unionfs-fuse Architecture: source amd64 Version: 0.21-1 Distribution: unstable Urgency: low Maintainer: Bernd Schubert [EMAIL PROTECTED] Changed-By: Bernd Schubert [EMAIL PROTECTED] Description: unionfs-fuse - Fuse implementation of unionfs Changes: unionfs-fuse (0.21-1) unstable; urgency=low . * new upstream release Checksums-Sha1: 11b7439c6060a9aef5a249fef7dc2a7cebc38cf6 1017 unionfs-fuse_0.21-1.dsc b3101d8f3b9b0ed1aca92d80564a0eac749deced 31114 unionfs-fuse_0.21.orig.tar.gz 29d05ddff7be5228b55daedc34fb8d124bf02123 3739 unionfs-fuse_0.21-1.diff.gz 5166b1602a57da41c67ae3341650ed4ccf1f7ff6 24692 unionfs-fuse_0.21-1_amd64.deb Checksums-Sha256: 3bbacb33d898dd82ab87bf4a1d8395465080e23714f3a11b51dbc2c3919d9bf1 1017 unionfs-fuse_0.21-1.dsc 7c755017d9a7aab633d9863652f8fa068bfb91eacdbd8b1fefddbdbafbe957ed 31114 unionfs-fuse_0.21.orig.tar.gz df06fa96acf8dcd9076bb81bb5aba6b0ec4e0722e66f0a003c0bcf244545b660 3739 unionfs-fuse_0.21-1.diff.gz b254547699c8ad37b1784d7d08fd3d1dd6ce7c0c1245e520fbece415249f0a75 24692 unionfs-fuse_0.21-1_amd64.deb Files: a892c4b69fdb4af95725423e6891ceed 1017 misc optional unionfs-fuse_0.21-1.dsc 41b1484db393407daec69cab5e7e4bcf 31114 misc optional unionfs-fuse_0.21.orig.tar.gz acc99b696f029289601bedc6e6e347e7 3739 misc optional unionfs-fuse_0.21-1.diff.gz a33e42790b858f709f2bd5bf1297f557 24692 misc optional unionfs-fuse_0.21-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkiMnZ0ACgkQKFvXofIqeU4XpgCeK+J7gMIbw1TjYma+5YajE42m Rm0Ani6oxROp92cpjQvrP6m0M3Z0zchh =dWfS -END PGP SIGNATURE- Accepted: unionfs-fuse_0.21-1.diff.gz to pool/main/u/unionfs-fuse/unionfs-fuse_0.21-1.diff.gz unionfs-fuse_0.21-1.dsc to pool/main/u/unionfs-fuse/unionfs-fuse_0.21-1.dsc unionfs-fuse_0.21-1_amd64.deb to pool/main/u/unionfs-fuse/unionfs-fuse_0.21-1_amd64.deb unionfs-fuse_0.21.orig.tar.gz to pool/main/u/unionfs-fuse/unionfs-fuse_0.21.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted unionfs-fuse 0.20-4 (source powerpc)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 26 Jun 2008 21:02:11 +0200 Source: unionfs-fuse Binary: unionfs-fuse Architecture: source powerpc Version: 0.20-4 Distribution: unstable Urgency: low Maintainer: Bernd Schubert [EMAIL PROTECTED] Changed-By: Bernd Schubert [EMAIL PROTECTED] Description: unionfs-fuse - Fuse implementation of unionfs Closes: 481490 Changes: unionfs-fuse (0.20-4) unstable; urgency=low . * as by suggestion of Kapil: - remove debian/copyright.in - install the CREDITS file with dh_installdocs . unionfs-fuse (0.20-3) unstable; urgency=low . * another hg pull from http://hg.podgorny.cz/unionfs-fuse (fixes the elfhash CPL incompatibility problem) * Changes to the debian/copyright files as suggested by Kapil Hari Paranjape and Richard Laager . unionfs-fuse (0.20-2) unstable; urgency=low . * add debian/watch file * fix the copyright file generation . unionfs-fuse (0.20-1) unstable; urgency=low . * Ouch, already so many internal releases and I never noticed the version string was wrong. . unionfs-fuse (0.9.20-2) unstable; urgency=low . * correct the section to misc . unionfs-fuse (0.9.20-1) unstable; urgency=low . * new upstream release * additional hg pull from http://podgorny.cz/~bernd/hg/hgwebdir.cgi/radek-trunk-bernd-merge * preparing official debian upload * switch to cmake based build system * (closes: #481490) . unionfs-fuse (0.9.19-hg20080403-ql2) unstable; urgency=low . * convert to debian quilt series * add fd.patch . unionfs-fuse (0.9.19-hg20080403-ql1) unstable; urgency=low . * rename() bugfixes * slight rmdir() and readdir() bugfixes * Update the version to 0.9.19-hg . unionfs-fuse (0.9.18hg.ql2) unstable; urgency=low . * fix dependency of unionfs-fuse and build-dependency . unionfs-fuse (0.9.18hg-1) unstable; urgency=low . * update to hg version + fixes . unionfs-fuse (0.9.18-1) unstable; urgency=low . * Initial Release. Checksums-Sha1: 57140c2be06b52dd150d7200b1793fd5127337f6 1012 unionfs-fuse_0.20-4.dsc f0f5f0d6b198b627427b59615999618b803e7f86 25907 unionfs-fuse_0.20.orig.tar.gz ccc87215d42121535164824a6fe70fad9f8254d9 15442 unionfs-fuse_0.20-4.diff.gz c03334e5d10760ba131c8f8ea296eb38b2e9fa6a 25208 unionfs-fuse_0.20-4_powerpc.deb Checksums-Sha256: b6f0568ed2839de21dcf7aebb3c54d44dded816fcc4904e5b86a413c7fd9d52c 1012 unionfs-fuse_0.20-4.dsc 8ac52e6f80492343c13bc49f1aa23746460104e068550215a7aededf404660c3 25907 unionfs-fuse_0.20.orig.tar.gz ab8bfa2478d738316062241e1faf6144c96d40c4271e566f9525724fe964aae8 15442 unionfs-fuse_0.20-4.diff.gz 1618d07129828acd0464f20626e66432fe4272198c6679edb1553664532f1e5b 25208 unionfs-fuse_0.20-4_powerpc.deb Files: 8b82654df0315f17f6f675fbefe1ce93 1012 misc optional unionfs-fuse_0.20-4.dsc e8e4dff2e32e5becd10c5e8ea39674ae 25907 misc optional unionfs-fuse_0.20.orig.tar.gz b6b0b2b4e8170980e4eb62a9bdf5c8cd 15442 misc optional unionfs-fuse_0.20-4.diff.gz 4c894bb08400e83f7cb867b1b8dfdf59 25208 misc optional unionfs-fuse_0.20-4_powerpc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIZDmKSR+P2lQW5bgRAuocAJ9IApWsuAzG6C+YQQPHidztWlG7IACfd58L bcpZWAXXx85zLnqNn1p4Jy4= =oZEF -END PGP SIGNATURE- Accepted: unionfs-fuse_0.20-4.diff.gz to pool/main/u/unionfs-fuse/unionfs-fuse_0.20-4.diff.gz unionfs-fuse_0.20-4.dsc to pool/main/u/unionfs-fuse/unionfs-fuse_0.20-4.dsc unionfs-fuse_0.20-4_powerpc.deb to pool/main/u/unionfs-fuse/unionfs-fuse_0.20-4_powerpc.deb unionfs-fuse_0.20.orig.tar.gz to pool/main/u/unionfs-fuse/unionfs-fuse_0.20.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
William Pitcock wrote: Hi, I am wondering if it is a good idea to remove lilo entirely. At the moment, lilo has been pulled from testing, and the code is in a shape where a grave bug (bug #479607) is unlikely fixable without severe refactoring of the codebase. Well, grub is also not free of bugs, all my partitions are usually reiserfs and on a hard reset grub stupidly comes up with GRUB Error 16: Inconsistent filesystem structure. You might see it differently, by in my opinion this is a grave bug as well. So why not also to remove grub ;) Sorry, I don't know if there is a debian bug report, the ubuntu bug description is here: https://bugs.launchpad.net/grub/+bug/64928 With grub being stable and grub2 approaching stability itself, do we really need lilo anymore? It's not even installed by default anymore, and the only systems I have that are still on lilo are installations of Debian I have had since Woody. I still use lilo on all of my systems. It seems like moving to grub for everything may be a good choice on the archs where lilo is used. If we do not need lilo, then I will file a RM bug in the next couple of weeks. Next problem with grub, grub can't read links, but always needs to update the menu.lst. In my previous work group we have a laptop chroot for updates. We then rsync from this chroot to the laptops and as last step only call 'lilo' to update to the recent kernel. For some laptops there are exceptions, however, and not the generic kernel is installed. With simple links and calling lilo these exceptions can be easily handled, with grubs menu.lst this would required full parsing of that file - the script probably would be 10x larger only for this stupid menu.lst parsing. So I quite disagree to remove lilo. Cheers, Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: VMware packaging
posted mailed Marc Haber wrote: On Tue, 15 Aug 2006 11:03:31 +0200, Bernd Schubert [EMAIL PROTECTED] wrote: Ubuntu already has vmware kernel module packages Yes, but adapting them to Debian seems to be nontrivial. I have not yet been able to get them build on Debian. Actually I didn't have much problems using the Ubuntu directory, though I have to admit that it was overly complex. You may find a cleaned up version here: http://www.pci.uni-heidelberg.de/tc/usr/bernd/downloads/vmware-modules/ Just tell me, if there's a problem with it. Cheers, Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: VMware packaging
Marc Haber wrote: On Sun, 13 Aug 2006 01:06:59 +0100, Peter Collingbourne [EMAIL PROTECTED] wrote: I found there were no VMware-related packages in the official repository, nor any way of creating them. Thus I propose to create a tool that will build (for example for VMware Server) vmware-server and vmware-modules-source packages based on an installation tarball (a la java-package). I have been (rather half-heartedly) trying to do this in the last few weeks, but have not been very successful due to lack of time, and lack of knowledge about module-assistant and the Debian kernel packages. Add in vmware's rather twisted way of building the modules (made less evil by vmware-any-any), and I have to go a long way until I fully understand the implications of what I'm doing. Would you be willing to cooperate, or is my knowledge too low to be useful for you? Ubuntu already has vmware kernel module packages, I have a slightly bugfixed version of the debian/ directory. The package name is a bit strange, but my 2 minute attempt to modify it failed, need to look into it again. If someone is interested, just mail me. Cheers, Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Remove cdrtools
Wouter Verhelst wrote: On Mon, Aug 14, 2006 at 10:58:13AM -0500, Steve Greenland wrote: On 12-Aug-06, 09:09 (CDT), Jon Dowland [EMAIL PROTECTED] wrote: At 1155391794 past the epoch, Bernd Schubert wrote: Btw, why always the autotools while there's this nice cmake? I've never used cmake myself, so I can't speak for how nice it is, but autotools (for all its problems) is very widespread. So is syphilis. That doesn't make it desirable. Syphilis is a disease. Software usually isn't. In the case of autotools, the fact is that usually it's configure.ac or Makefile.am being horribly broken, rather than the autotools. If used properly, autotools usually do their job; and pretty well, too. Just have a look here http://lwn.net/Articles/188693 Cheers, Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Remove cdrtools
The fork-team can look at http://www.arklinux.org/projects/dvdrtools, a 100% free fork of cdrtools. The SVN is inactive from 6 month, but the autotool-ization is already done and it can write on DVDs, and probably is better than starting another fork. Btw, why always the autotools while there's this nice cmake? The cmake build system might even get accepted by Joerg, as it can create makefiles for MS compilers (I know, its not important to this list and also not to me, but it seems to be important for Joerg). Cheers, Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
kernel modules postinst script
Hi, while I just build some kernel module packages for our clients and installing them, I think I found a bug applying to almost all kernel module packages. Most packages have a file like postinst.modules.in with something like #!/bin/sh set -e if [ `uname -r` = _KVERS_ ] ; then depmod -a fi Now imagine you are installing the package on a fileserver in a chroot and the file servers kernel version is different from _KVERS_. Furthermore, all clients mount their root directory read-only from the server. So /lib/modules/modules.dep will never be updated. Why is not something like this used? #!/bin/sh set -e SYSTEMMAP=/boot/System.map-_KVERS_ if [ -f $SYSTEMMAP ] ; then depmod -ae -F $SYSTEMMAP _KVERS_ elif [ `uname -r` = _KVERS_ ] ; then depmod -a fi Thanks, Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: use of invoke-rc.d $PACKAGE stop || exit $? in prerm scripts
Michael Prokop wrote: But /etc/init.d/$PACKAGE is executed only, if [ -x `which invoke-rc.d 2/dev/null` ] fails. And I still don't see what's the Ah, I entirely misunderstood your intention. I thought you want to get rid of this if condition and execute the commands one after the other. Sorry for the noise. Cheers, Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: use of invoke-rc.d $PACKAGE stop || exit $? in prerm scripts
Michael Prokop wrote:
* Bernd Schubert [EMAIL PROTECTED] wrote:
inside their prerm maintainer scripts. If stopping $PACKAGE through
invoke-rc.d/init-script fails, removing the package fails as well.
Using:
invoke-rc.d $PACKAGE stop || true
/etc/init.d/$PACKAGE stop || true
We are using chroot environments (e.g. with sid) where no daemon is
running and invoke-rc.d will only do an exit 0 in those chroots.
How do you achieve that? For example symlinking invoke-rc.d to
/bin/true is a workaround, but I'm searching for a general solution
to avoid that daemons are started when upgrading even though they
did not run before the upgrade (or don't start any service at all,
e.g. in chroots - as you mentioned).
Via /usr/sbin/policy-rc.d, e.g.:
#!/bin/sh
# are we on hamilton?
WHERE=$(hostname -s|cut -b 1-8) # cut to remove {1,2} from hamilton{1,2}
if [ $WHERE = hamilton ]; then
# notify invoke-rc.d that nothing should be done -- we are in a chroot
exit 101
else
# allow it
exit 0
fi
(This chroot is used on the clients as their root environment)
Using the method above, wouldn't there be any chance that a bad
init script could kill daemons started outside the chroot?
The init script would be broken then.
Anyway, I don't see the difference between stop || exit $? and
stop || true in this case.
What I mean is that the call of
invoke-rc.d $PACKAGE stop || true
is fine, but the second call
/etc/init.d/$PACKAGE stop || true
will not using policy-rc.d and therefore might be a possible problem. Given
the fact that we have a sid chroot on a high availibilty system and a sid
package always might cause some trouble, I don't like the idea that a
malformed script is able to stop programs outside its chroot.
Cheers,
Bernd
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: use of invoke-rc.d $PACKAGE stop || exit $? in prerm scripts
inside their prerm maintainer scripts. If stopping $PACKAGE through invoke-rc.d/init-script fails, removing the package fails as well. Using: invoke-rc.d $PACKAGE stop || true /etc/init.d/$PACKAGE stop || true We are using chroot environments (e.g. with sid) where no daemon is running and invoke-rc.d will only do an exit 0 in those chroots. Using the method above, wouldn't there be any chance that a bad init script could kill daemons started outside the chroot? Thanks, Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Everyone go test aptitude 0.3.4!
I reported a bug several weeks ago and didn't get the slightest response. You filed a single severity: important bug against apt. Regardless of whether you got an answer, this doesn't qualify as critical. I decided to fill it in as 'important' only, since I was surprised nobody else reported it and so I'm not sure this bug is as severe as I believe it to be. As I only tested it in our chroot environment and since I'm currently not willing to blow up my home system, I also can't confirm that other systems/configurations are affected as well. However, I really didn't expect that my report seems to be ignored. Regards, Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Everyone go test aptitude 0.3.4!
I suppose so -- it'll probably take a while before the translations are ready anyway. When do you think apt 0.6.41 and its related packages will go in? Not until gcc-4.0 and perl are both updated in testing, which block much of the archive from being updated right now. gcc-4.0 is blocked mainly by kaffe at this point; perl is blocked by the yet-unresolved testsuite failures on arm and m68k. May I kindly ask first to solve the critical bugs in apt-0.6.x and then upload it to Etch? I mean, I reported a bug several weeks ago and didn't get the slightest response. Thanks, Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PRINT EPSON STYLUS C82; bug #235522?
Alexander Schmehl wrote: * SAVERIO FERRARO [EMAIL PROTECTED] [041005 18:49]: I HAVE SOME PROBLEMS WITH THE CONFIGURATION OF THIS PRINT. HOW HAVE I TO DO? Tell us your problem, and we might be able to help. Oh, and in case you didn't noticed: Your caps-lock key seems to be broken. Yours sincerely, Alexander May its its bug #235522? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=235522 I filled this bug report pretty much time ago and the maintainer doesn't seem to care. I tried to fix it myself, but even the cups newsgroup couldn't help me with it. Unfortunality the error messages don't make any sense to me or to someone else. However, I would really be glad if not only me would care more about this bug. IMHO its release critical, since it not only effects the C82, but maybe all recent stylus printers. When I wrote this bug report, I didn't know yet that many others Epson stylus printers do have the very same problem. Thanks, Bernd
