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: 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
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: 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: 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
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 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: 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: 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]
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: 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]
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: 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: VMware packaging
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: 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
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
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: 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: 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 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: 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 com
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
&g
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
