Re: Re: How to avoid stealth installation of systemd?
I think that this would be an annoying waste of time for most users, since only a few people care so much about not being tainted by systemd I do not care being tainted by systemd when it works. Actually on two very different machines it means no audio for me. On a NAS it means no boot(probably because of RAID10 fs in /etc/fstab), so I reverted it on all machines Bug for pulse is open for a while but so far no change. and BTW, rtkit does not work with systemd208, udsiks2 depends on libpam-systemd, and systemd-shim is incompatible with systemd-shim meaning usb key hotplus is now unavailable and rtkit also. I think that as long as the transition is not smooth, whithout any religious conveiction, people will complain. For me, the forced transition was introduced too early -- eric -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53b2f20e.1070...@free.fr
Re: How to avoid stealth installation of systemd?
On 01/07/2014 19:59, Matthias Klumpp wrote: These are valid points, and thank you for reporting bugs! However, as unstable user, some breakage can be expected, and the point for transitioning early in unstable is to make the transition as smooth as possible when someone uprades Debian stable, which is not affected by init-system changes at all. Sure. I also had bug with libc, X and so on in the past breaking the machine. Just my personal feeling is that it does currently break valid setup a bit easily to my taste (setup running for years on unstable + experimental while regularly updated). Running stable is fine *when you can*. Each user buying a recent AMD/ATI graphic cards or and AMD APU for an htpc needs experimental stuff to get video acceleration (glamor support is not even in unstable and radeonsi and later needs it). Support for recent Intel graphic feature is also problematic and vaapi is undergoing massive changes in th same area. You can indeed argue it is a way of rapidly collecting bugs but you better have to fix them rapidly enough or people will revert and/or hold their packages for not being annoyed until it stabilizes more and it will/may void the target. And again, I have no religious/sound opinion on which init system is better. As an old folk I'm a bit concerned about the size for maintainability reasons and the fact that it is almost already mandatory because more and more packages starts depending on it or making changes that implies systemd (like udisks2) but that's all. -- eric -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53b30357.2070...@free.fr
Re: Re: How to avoid stealth installation of systemd?
Which bug report is that? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748651 I will try to add the requested debug log ASAP. Dunno where I got the initial bogus trace command from. Probably not invented it. --eric -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53b306c1.7050...@free.fr
Re: init system policy
On 18/11/2014 17:39, Matthias Urlichs wrote: Text emails, please. I alway forget that in my company my mailer is configured for html as outlook discussion cut is absurd... You _can_ do ExecStart=sudo -u $USER_MINIDLNA -g GROUP_MINIDLNA /usr/sbin/minidlnad -S but that's not the optimal solution here. Yes not really. And given the number of damons that chnage the uid/gid, it would rather be good to define a best practice!!! It's better IMHO to use a fixed user in your packaging -- why should that user be configurable in the first place? If the sysadmin _really_ needs to use a different user+group, they can add an overriding unit file to /etc/systemd/system/ (files get merged, so no need to copy the whole thing). That's typical: instead of answering the question, you try to say the actual packaging is absurd. Its current debian packaging for systemv! The system V init script has the ability to change the user and this is really useful because the multimedia file are likely owned by you and in your home directory by daemon and not minidlna and why should you belong to minidlna group?... And running anything that use upnp as root I suggest to not do for security reasons... ExecStartPre=/bin/mkdir -p /var/run/minidlna You might want to use this opportunity to replace /var/run with /run. Sure. Also, one ExecStartPre stanza is sufficient: ExecStartPre=/usr/bin/install -o %u -g %g -m 0750 -d /run/minidlna But again this does not really slpit the script to configurable option that will not be overwritten when upgrading... -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/546b8049.3030...@free.fr
Re: init system policy
On 18/11/2014 17:46, Ansgar Burchardt wrote: Hi, On 11/18/2014 05:39 PM, Matthias Urlichs wrote: trying to convert minidlna sysv init file to systemd, managed to have a working unit file but failed to split the configuration mimicing the ../default/minidlna content with the hability to make USER and GROUP configurable. You _can_ do ExecStart=sudo -u $USER_MINIDLNA -g GROUP_MINIDLNA /usr/sbin/minidlnad -S but that's not the optimal solution here. It's better IMHO to use a fixed user in your packaging -- why should that user be configurable in the first place? If the sysadmin _really_ needs to use a different user+group, they can add an overriding unit file to /etc/systemd/system/ (files get merged, so no need to copy the whole thing). Ack. In the file they just need to set User and Group then? Both of these can be replaced with RuntimeDirectory=minidlda which will create /run/minidlna, chown it to the user given in User= and even remove it again once the service is stopped. There's RuntimeDirectoryMode= if you need different permissions. All of this is documented in systemd.exec(5) if you want more information. Thanks. I read them for trying to fix the User= dynamic problem but did not found this. -- eric -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/546b8114.7050...@free.fr
Re: init system policy
On 18/11/2014 18:36, Ansgar Burchardt wrote: Hi, On 11/18/2014 06:25 PM, Eric Valette wrote: In the file they just need to set User and Group then? With systemd you can ship a default configuration in /lib/systemd/system and administrators can override specific options, for example: +--- | [Unit] | Description=Some Helpful Description | Documentation=man:minidlda(1) | | [Service] | User=minidlda | ExecStart=/usr/sbin/minidldad -S +---[ /lib/systemd/system/minidlda.service ] Then an admin can override the entire file by writing his own /etc/systemd/system/minidlda.service or only override specific settings: +--- | [Service] | User=some-other-user +---[ /etc/systemd/system/miniblda.service.d/user.conf ] That's crystal clear and solves my problem (cannot reuse the system v default config file but that's a minor and expected problem) Thanks for your time --eric -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/546b8997.2030...@free.fr
Re: init system policy
On 18/11/2014 19:47, Matthias Urlichs wrote:
ExecStart=sudo -u $USER_MINIDLNA -g GROUP_MINIDLNA /usr/sbin/minidlnad -S
is an adequate and perfectly serviceable answer to your question.
On the other hand, the documented way to do this in systemd man pages is
to use User and Group. If the User and Group variables have been added
to unit files I naively think it was for a reason but I may be wrong.
I just mentioned that naively combining User=$TOTO or ${TOTO} TOTO being
defined in an default/package file parsed by EnvironmentFile= does not
seem to work as documented in man pages (seen the very same question
being asked on various distro mailing list without definitive answer).
Maybe because Debian is a multiuser system AIUI, so running the daemon as a
specific "normal" user didn't even occur to me. Sorry!
Sure but what percentage is used by a single user? And for multiple
users, to index multimedia files, you should either define a single
location and a import script or play with groups and permission..
systemd for servers systems may still have some way to go for converting
complex init scripts for firewall,openssh,VM's IMHO.
If you already do have an /etc/default/PACKAGE file, the sudo method's
advantage is that you can just use an EnvironmentFile= stanza, and thus
don't need to keep that and /etc/systemd/system/PACKAGE.service in sync
somehow.
The syntax may not always been compatible as it may use shell tricks to
define variables. I do not mind duplicating the file as only one init
system will be used at a time and transition should be the job of
package setup when default init system changes (I know some backward
compatibility is planned).
Thanks for your time.
-- eric
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/546b9c43.4050...@free.fr
Re: Re: init system policy
Parsing User=$TOTO as "the User is the value of the environment variable TOTO as given by Environment or EnvironmentFile" might be a reasonable feature request, but it is not currently an implemented feature. I think anything that simplify transitioning from an init system to another new one is valuable as long as it does not breaks the original new design intention. There has been a good and valuable effort trying to split original upstream packages provided init system scripts by debian developers into /etc/default/X and /etc/init.d/X file and storing most commonly changed sysv init options in the default file part (including start or not). Wasting this work due to systemd transition would be a bad idea IMHO. Being able to reuse the sysv default config file or automate its back and forth conversion (like passwd and shadow or group and gshadow with grpck and pwck) would be helping both init system transition for debian devs and administrators that have been developing their own sysv scripts. Looking at ways to replace start-stop-daemon various parameters by corresponding unit file sequences/file layout would probably help (-g and -c are just examples for their User and Group systemd counterpart) --eric -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/546bb622.5000...@free.fr
Re: Re: init system policy
> well, debconf seems like a win here. > There's no reasonable default so it's desirable to make it easy for the > admin to specify and so you'd probably want to use normal best practice > for debconf updates. I agree with this but unfortunately original minidlna package as no debconf setup :-) -- eric -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/546c6051.2040...@free.fr
Re: Re: init system policy
> I did not know that. It is very interesting. > > But, is there a way to be notified at upgrade time that the > system service file has been modified when there is local > (partial or full) changes ? > As a small workaround, I think I will put symlinks such as > /lib/systemd/[perhaps sub-directory, to check] -> /etc/systemd/lib/[...] > This way, systemd config files and their changes will be, at least, > recorded by etckeeper. Non sure you want to automate that. For minidlna, there are several conf files that can be edited. more minidlna.conffiles /etc/minidlna.conf /etc/init.d/minidlna /etc/default/minidlna Some are mostly relevant to the init system itself (default one), some to minidlna daemon itself. When you start modifying the daemon config you may modify all the files and some have a syntax that cannot be changed. If your restart the daemon after modifying the unit config file and later modify its own managed config file, unless the daemon monitors the config file chnages itself, you wil have to restart. -- eric -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/546df440.9010...@free.fr
Accepted digikam 4:2.9.0-2 (source amd64 all)
Unless I missed someting, the binary contained in digikam_2.9.0-2_amd64.deb is still linked with the libmarblewidget12 library, the control file is still wrong, and I think the conflick with phonon-backend-vlc is unnecessary. I edited the control file using dpkg-deb -x/-e and then rebuild and found the error. -- eric -- 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/504dd7ad.9010...@free.fr
Re: debian-multimedia.org considered harmful, Was: Unofficial repositories on 'debian' domains
While debian-multimedia.org has gained a reputation of providing packages, which were desperately lacking in Debian, IMO this repository has turned into a major source of trouble and pissed users provoking flamewars in the recent past. There is still a number of remaining multimedia-related packages that we still lack in Debian, and pkg-multimedia is working on getting at least the most popular ones packaged and uploaded - help, as always, is of course very appreciated. [2] The problem is that debian per se 1) is unusable for any serious multimedia usage. what are the version of VLC, ffmpeg, xbmc provided by debian? 2) has long pretended they have the knowledge to make multimedia packages better than other Instead of arguing you should be pleased someone makes debian useable for multimedia activities otherwise people will move to ubuntu where also multimedia packages are maintained via non official PPA Have you heard of raspberrypi, cubox, spark, that are making the buzz. What is demoed on it: multimedia capabilities. Will debian be attractiive without multimedia packages: no. In summary, I can only advise everyone against enabling that repository on any machine. Crap: I've been using that for ages (running debian since 96) with experimental+unstable and it is rock solid. Maintainer also fixes issues and respond to bug report more correctly than some other official package maintainer. --eric -- 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/4f5b19ba.8010...@free.fr
Re: debian-multimedia.org considered harmful, Was: Unofficial repositories on 'debian' domains
On 10/03/2012 11:14, Thomas Goirand wrote: In where? Stable? SID? Backports? FYI, you can check all of this easily by yourself using packages.debian.org. Or are you trying to make the point that Debian has outdated packages? I ask you a question: what are the version of the packeges in debian unstable and in debian-multimedia.org trying to be factual. I know the answer, I just would like someone from debian to write it down ;-) I know the version already yes. And yes debian is completely outdated. Or even better: consider helping yourself. I don't think that the debian multimedia maintainers ever refused help. I do help the people providing the packages I need and currently its debian-multimedia. Have you heard of raspberrypi, cubox, spark, that are making the buzz. What is demoed on it: multimedia capabilities. Will debian be attractiive without multimedia packages: no. It's up to *anyone* (eg: including yourself) to make this change. And by the way, I have read many people writing that Debian would be a very good choice for raspberry pi. I do think that Debian Squeeze has a very nice set of packages that will make a good fit for this platform. What do you think will be lacking exactly? XBMC, up to date ffmpeg at least with some non-free extensions for sure. It's very easy to point fingers at others, without giving proof of what you are writing, and without proposing any help. I find this a very bad attitude. I was not the first pointing fingers. And yes it's because I also think it is bad attitude that I reacted. -- eric -- 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/4f5b30a2.7040...@free.fr
Re: debian-multimedia.org considered harmful, Was: Unofficial repositories on 'debian' domains
On 10/03/2012 11:44, Eric Valette wrote: I know the version already yes. And yes debian is completely outdated. To be fair, but catching up at least for vlc, mplayer... Still no xbmc, handbrake, libdvbcsa tough and quite old ffmpeg -- eric -- 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/4f5b3515.10...@free.fr
Re: debian-multimedia.org considered harmful, Was: Unofficial repositories on 'debian' domains
On 10/03/2012 12:03, Eric Valette wrote: On 10/03/2012 11:44, Eric Valette wrote: I know the version already yes. And yes debian is completely outdated. To be fair, but catching up at least for vlc, mplayer... Still no xbmc, handbrake, libdvbcsa tough and quite old ffmpeg mythtv, tvheadend, ... -- eric -- 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/4f5b3659.5010...@free.fr
Re: Re: debian-multimedia.org considered harmful, Was: Unofficial repositories on 'debian' domains
Yes acknowledged that vlc and mplayer are now up-to-date. Libav vs ffmpeg could be per se part of the debate. We could also speak about compilation options and induced feature/codec support what about xbmc, mythv, tvheadend, avidemux? -- eric -- 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/4f5b3b53.5050...@free.fr
Re: debian-multimedia.org considered harmful, Was: Unofficial repositories on 'debian' domains
On 10/03/2012 12:40, Philip Hands wrote: Really? Again, vlc or mplayer do not make a multi-media capable distribution. take a look at yavdr, openelec, geexbox, ubuntu studio and the packages they provide Read http://thelinuxcauldron.wordpress.com/2009/04/14/the-list-the-top-5-media-center-programs-for-linux/ and see the one you have. -- eric -- 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/4f5b4a59.7050...@free.fr
Re: Re: debian-multimedia.org considered harmful, Was: Unofficial repositories on 'debian' domains
> take a look at yavdr, openelec, geexbox, ubuntu studio and the > packages they provide > > Readhttp://thelinuxcauldron.wordpress.com/2009/04/14/the-list-the-top-5-media-center-programs-for-linux/ > and see the one you have. Ahh, so your definition of "serious multimedia" is "media centers". Thanks for clarifying. I agree, that's an area Debian has too few poeple devoted to currently. Please do consider to help out yourself! Thanks for not copying me. Afraid I was going to answer? Ubuntu studio is not media center BTW. And you also need sources to browse and its mainly IPTV or DVB-T/C/S, DVD or blue-ray. With actual policy (that I respect and understand), you are not going to provide stuff to circumvent protection means meaning I cannot watch even a dvd. I help debugging XBMC and ffmpeg using debian packaging tool. Feel free to incorporate other people work. --eric -- 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/4f5b75cf.1080...@free.fr
Re: Re: debian-multimedia.org considered harmful
When the totem law of Kbanga declares that displaying any words with two consonant clusters is illegal on Fridays, the rest of the world doesn't suffer. Being able to pop in a DVD and play it is something an average person takes for granted. If oppressive laws in a single country stop a good part of multimedia functionality, why should that functionality be taken away from everyone else? The problem is: decss is illegal in very much more than just the US. This is a very different situation. Again, I can understand the reasons, but an average user expects to be able to read dvd or blue-ray or to get a decent multimedia player. Other distribution do have ways to provide it to their users. Actually official debian does not offers this and is furthermore criticizing good willing people that try to make Debian useable a multimedia/HTPC system. Some of the messages asking to help instead of complaining are in my view a bit reverted has debian-multimedia has been providing good package for ages and some debian people did prefer to reinvent the wheel. You can tomorrow take the packaging done and integrate the non law encumbered packages into normal debian repository or enhance them if it does not strictly adhere to Debian standard. --eric -- 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/4f5c6a17.4060...@free.fr
Re: Re: debian-multimedia.org considered harmful, Was: Unofficial repositories on 'debian' domains
When exactly was vlc not up-to-date on Debian? As long as it is unable to play dvd or various codec that are non supported given the option for compiling libav for example -- eric -- 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/4f5c86f7.6010...@free.fr
Re: Re: debian-multimedia.org considered harmful
Actually official debian does not offers this and is furthermore criticizing good willing people that try to make Debian useable in a multimedia/HTPC system. official Debian is not criticising anyone here. This is just debian- devel@l.d.o: some people ranting, some discussing and some totally off anything and everything. Oh, and occisionally some good stuff too :) Original part of the post that I found not acceptable is at http://lists.debian.org/debian-devel/2012/03/msg00151.html Author does not seem to care about people not being able to play dvd or various multimedia format or have good multimedia player because of the strict gpl compliance or stupid law. Ubuntu at least provide an official package that get libdvdcss from medibuntu... You must consider your user. You must consider your legal obligation too. Today debian-multimedia is a path that enable to run debian and to still have the necessary tools to make it acceptable for average people for their multimedia tasks. Author seems also to not remember debian-multimedia was there long before official blessed debian multimedia team even started and decided to go their own way. Will try to shut up now. -- eric -- 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/4f5c8c45.5060...@free.fr
Re: debian-multimedia.org considered harmful
On 18/03/2012 02:24, Christoph Anton Mitterer wrote: Which distro provides Blu-Ray playback? Even though there is libaacs and friends now... the MKBs are only publicly known till version ... what? ... 10? As long as it remains free of charge and available, you can package makemkv in non-free. --eric -- 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/4f659bdc.8000...@free.fr
Re: Re: On init in Debian
> And how do you expect non-experts be able to solve problems when they > pop up. Buying consultant services from the experts? Non-experts are not able to solve any problem, so this is not an issue. You are even unable to understand how brilliant I am you poor stupid fellows. Come on, there are people on this list that have been using debian for probably longer than you and know Linux quite well. System init is very fragile, as bootloader. Fixing them is complicated and should be done in a couple of hours so that broken machines do not spread to much beyond people unable to fix them. So its vital to have a lot of people able to fix broken init in a couple of hours. It did happen in the past, and will happen with any init system. (grub upgrade broke one of my machine yesterday). A new system init will require a learning curve and the sentence above, make people fear that they will be unable to fix anything by themselves while you sleep after pushing an insufficiently tested change... --eric -- 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/4f69a19e.7080...@free.fr
Re: Re: Processor microcode update packages (was: Towards d-i wheezybeta 3)
Reading the thread about microcode, I wonder why there is no more any /etc/init.d/microcode.ctl equivalent for people like building their own kernel without initrd. -- eric -- 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/5065a9c4.2070...@free.fr
Re: Processor microcode update packages
On 29/09/2012 03:46, Henrique de Moraes Holschuh wrote: 1. No html, please. non-initrd is supported. Read the package documentation for the details. I did. I do not want to compile microcode tool as a module because module loading juts slows down the boot process and contrarilly to many other package requiring firmware, this one does not enable to load firmware when not compiled as a module. So it does not work for people compiling their own kernel and not using modules (when you tailor your kernel for a given machine, modules are just slowing the boot process and do not bring anything). -- eric -- 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/5066b198.9030...@free.fr
Re: [OT] kernel modules
Unless under very specific circumstances, the use of a modular kernel brings one the ability to replace the particular hardware the system runs on at will. If I do taylor my kernel for my machine, I do not care at all Say, it's possible to replace a just burned motherboard with an Intel CPU with a different one having an AMD CPU instead. Or one may take the HDD holding the system and put it into a wholly different box, while often retaining the ability to boot. Not true in general unless you compile the whole modules set which takes ages. You probably never rebuild the stock debian kernel on a old machine ;-) For these reasons, in the majority of cases, compiling a non-modular kernel doesn't worth the effort, and may also be harmful to the system's operation. Well I do this happily since 96. Almost never used the debian kernel more than a few days after install. Crashed a lot of disks, replaced mother boards, changed computers... Nothing that booting knoppix iso cannot fix and a lot of time gained each boot and when compiling a new kernel version... -- eric -- 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/5066c93c.2070...@free.fr
Re: Processor microcode update packages
On 29/09/2012 12:32, Henrique de Moraes Holschuh wrote: If you want to use non-modular, built-in microcode, the documentation of iucode-tool does explain how to trigger the microcode reload after boot. You will have to add it to your system yourself. Fair enough. Already done. However, during the stable->wheezy migration, all users building their own kernel may be affected as microcode.ctl package did had an initscript... --eric -- 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/5066d79c.7090...@free.fr
Re: Re: assumptions about the build environment.
While working on debian one thing I have not managed to find is documentation on what packages can and can't assume about the build environment. Does such documentation exist and if not should it be created. Some specific cases i'm wondering about: I just discovered that on my beagleboard XM (under armhf sid) nacl (which previously build on a debian experimental armhf buildd but not a debian unstable armhf buildd) will build if /sys is mounted but will not build if it is not mounted. Can packages assume that /sys will be mounted in the build environment or not? I consider /sys almost as essential as /proc. However I wonder what a build process would need it for. I will hijack this thread a bit and I know there is another one running on the subject, but assumption like this makes it impossible to cross compile most packages. I'm currently trying to compile armhf package for the rasberry pi on a amd64 machine and naively though it would be easy to do with multiarch. I screwed my machines(replaced the dynamic linkers, ftp and other tools by arm binaries although I followed the scarce available documentation). Natively compiling package as big as XBMC on the PI is a nightmare and current tools fails really short because you: 1) need a root filesystem for the machines. You can use debootstrap but will need many additionnal packages that are yet not build, 2) cannot install produced .deb in the root filesystem exept by running them on qemu which is.. Any hint? -- 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/50715160.5050...@free.fr
Re: init system policy
On 11/21/2014 03:26 PM, Jonathan de Boyne Pollard wrote: > Eric Valette: >> There has been a good and valuable effort trying to split original >> upstream packages provided init system scripts by debian developers >> into /etc/default/X and /etc/init.d/X file and storing most commonly >> changed sysv init options in the default file part (including start >> or not). Wasting this work due to systemd transition would be a bad >> idea IMHO. > > It's actually thinking that /etc/default is the right place for service > enable/disable information that has traditionally been seen as the bad > idea. See Debian bug #522163 for starters. Never said that. I know the master of the universe said /etc/default must dispappear but his arguments are more than weak IMHO... I said separating complex config file into elements that should be modifiable by almost anyone without noticeable impacts and change that may lead to more complex situations is good for the novice. I do not assume everyone has been using Unix since its birdth... -- eric -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/546f4e98.2020...@free.fr
Re: 64-bit time_t transition in progress in unstable
My current list of unupgradable packages on amd64 is: gir1.2-gstreamer-1.0/unstable 1.24.0-1 amd64 [upgradable from: 1.22.10-1] libegl-mesa0/unstable 24.0.2-1 amd64 [upgradable from: 24.0.1-1] libgbm1/unstable 24.0.2-1 amd64 [upgradable from: 24.0.1-1] libgl1-mesa-dri/unstable 24.0.2-1 amd64 [upgradable from: 24.0.1-1] libglapi-mesa/unstable 24.0.2-1 amd64 [upgradable from: 24.0.1-1] libglx-mesa0/unstable 24.0.2-1 amd64 [upgradable from: 24.0.1-1] libgstreamer1.0-0/unstable 1.24.0-1 amd64 [upgradable from: 1.22.10-1] libldb2/unstable 2:2.8.0+samba4.19.5+dfsg-4 amd64 [upgradable from: 2:2.8.0+samba4.19.5+dfsg-1] libspa-0.2-modules/unstable 1.0.3-1.1 amd64 [upgradable from: 1.0.3-1] libzvbi-common/unstable 0.2.42-1.2 all [upgradable from: 0.2.42-1.1] mesa-va-drivers/unstable 24.0.2-1 amd64 [upgradable from: 24.0.1-1] samba-libs/unstable 2:4.19.5+dfsg-4 amd64 [upgradable from: 2:4.19.5+dfsg-1] Doing a bit of exploration, the root problems seem to be: libdebuginfod1 : Depends: libelf1 (= 0.190-1+b1) libdw1 : Depends: libelf1 (= 0.190-1+b1) libxine2-misc-plugins : Depends: libsmbclient (>= 2:4.0.3+dfsg1) libgl1-mesa-dri : Depends: libglapi-mesa (= 24.0.1-1) I'm not sure what's blocking the chain ending in libelf1 since t64 versions of those libraries seem to be available, but attempting to force it would remove gdb and jupyter if that helps. You can force the migration by explicitly adding the package that it propose to remove (e.g gdb for libelf, ...) I managed to upgrade all packages you mention in your mail that way. Only libkf5akonadisearch-bin libkf5akonadisearch-plugins libkf5akonadisearchcore5t64 libkf5akonadisearchpim5t64 libkf5akonadisearchxapian5t64 are missing because there are bugs in the Provides: for api /or the packe depending on the T64 ABI are not yet rebuild. I opened a bug for that -- eric
Re: 64-bit time_t transition in progress in unstable
On 07/03/2024 07:25, Kevin Bowling wrote: As of this evening these are the packages that currently have broken deps on amd64 for me: gstreamer1.0-plugins-good gstreamer1.0-pulseaudio libkf5akonadisearch-bin libkf5akonadisearch-plugins occt-misc Someone already opened a bug for libkf5akonadisearch-bin libkf5akonadisearch-plugins that has been closed as "being part of the normal things due to transition" but I reopened it as: The maintainer transitionned the "abi name" to "abi name"t64 but many package still depend on old "abi name" and are not going to be rebuild unless someone force it. -- eric
Re: 64-bit time_t transition in progress in unstable
On 07/03/2024 18:57, Rene Engelhard wrote: That one is tracked and will get appropriate bin-NMUs from the release team, I am sure. It is right that this uninstallability is "being part of the normal things due to transition". I'm sure it will be done at some point. However, I just point out that on amd64 this is the last set of packages that are uninstallable currently on all my systems (except the one when i manually edited the control file) and this has been so since 29 february. -- eric
Re: 64-bit time_t transition in progress in unstable
On 07/03/2024 19:58, Rene Engelhard wrote: I'm sure it will be done at some point. However, I just point out that on amd64 Maybe, though in my sid VM with all tasks installed plasma-workspace fails to upgrade, claiming about gdb-minmal | gdb not to be installed whereas both of that install, but that doesn't help it futher. Didn't debug, no KDE person. If you look at my first post in this thread I explain how to install libelfxxx without removing gdb. Apt has problem finding a correct path for some T64 packages but if you explicitly put each packages apt naively and wrongly wants to remove in the install line it find the correct path. Other have confirmed this methods works (see in thread) and not only for libelf but many others problematic packages. A bug or limitation of apt. Dunno. My point also was that your reopening of the bug is wrong since the maintainer can't do anything about it. And you probably need to get out of your amd64 bubble, see below My "bubble" probably represent in volume 99% of debian users/installations so that is a big bubble! I admit that unstable installation volume is far less than stable but the proportion of people using unstable on arm/xxx is probably identical as stable. I completely can understand that the RT doesn't do those bin-NMUs per arch (when?) but just when it's actually ready. Well well, you annoy 99% of unstable debian users. A choice that you are perfectly entitled to make, as I am for complaining of consequences because of having hard time to help apt to find a migration path (and time consuming solution). I imagine it is even worse on other arch. -- eric
Re: 64-bit time_t transition in progress in unstable
On 07/03/2024 20:55, Rene Engelhard wrote: unstable is unstable. Don't use it if you can't handle stuff like this. And yes, be it even for more days or however it takes. The usual mantra. However, if no one use unstable and debug it to make it work correctly, maintainers will discover existing bug very late in the process and they will impact more people. You should be happy people debug code in advance and thanks them instead of using this mantra (and I dunno how many debian bugs (100+) I have reported and sometime fixed myself). -- eric
Re: 64-bit time_t transition in progress in unstable
On 07/03/2024 21:16, Rene Engelhard wrote: ct more people. But not so much for dependency issues like this. Which is my sole point. In 99,9% of cases this won't even migrate to testing. And unstable won't be released - testing will. What is your point? Without known bugs or new versions packages migrate from unstable to testing automatically. You should be happy people debug code *debug code*, yes. debug *actual* (dependency) issues, yes. I did my part for example with this one, that maintainer denied first but fixed later in his next upload as suggested... https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065349 -- eric
Re: 64-bit time_t transition in progress in unstable
On 08/03/2024 07:38, Rene Engelhard wrote: Hi, I did my part for example with this one, that maintainer denied first but fixed later in his next upload as suggested... https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065349 Well, you haven't seen the various discussion how to fix smbclient on IRC... I started my analysis in the comment of the above mentioned bug report when my suggestion to add "Provides" was politely denied by: "So Although I'm not a debian developer, I read this control file as:" Not really. This is an affect of * d/genshlibs: run dh_makeshlibs on libsmbclient0 (Closes: #1065349) See above. That is the correct fix (with a similar result of what you suggests), not what you suggested in the first mail, though. ... That is plain wrong. Breaks: is not waiting for anything be there. It's just a lesser version of Conflicts See above. It still means the two packages cannot be co-installed no? So result is the same as far as the bug was concerned. You are so determined to prove how dumb I am and how superior you, personally, are, that you do cannot even see these simple facts: 1) There was indeed a problem with this samba package set, that I spend time to report with a kind fix suggestion (from my point of view), 2) I said that a "Provides" was missing in control file, not how it should be added, 3) At the end "Provides:" has indeed been added, probably the "right" way as you suggest but still, Insulting users is generally not very efficient, even for a non profit organisation. And believe me although on pre-retirement, with more time, and a lot of linux and debian user experience, this does not encourage me to take any package responsibility any time soon if that means dealing with people like you. That said, I have a lot of respect and sympathy for debian developers in general. I selected this linux distrib because of that more than 20 years ago. -- eric
Re: Re: support for merged /usr in Debian
What is the "upgrade path" for an older system that has /usr split off? Will it just stop being bootable after upgrading? It just needs to use an initramfs. A standalone /usr without an initramfs IS ALREADY NOT SUPPORTED by systemd. This is not relevant for merged /usr. What is the "upgrade path" for an older system that has /usr split off? Will it just stop being bootable after upgrading? It just needs to use an initramfs. A standalone /usr without an initramfs IS ALREADY NOT SUPPORTED by systemd. This is not relevant for merged /usr. It is not supported *BUT* just works as expected on more than 20 machines I have access to, especially now that the debian systemd maintainers make sure systemd do not depend on libraries installed in /usr... Systemd shall make linux boot easier, faster, secure, not render things impossible because it does not know how to handle it because it wants to do too much. For years (actually 20), I've been installing Linux on various machine using various distro to end up using exclusively debian because, I was able to tune the system as I want and not because other have decided I MUST do it in whatever way. For machines I really manage, I have a separate /usr, no initrd and self build kernel: 1) Why should I build modules when I always load them and hardware almost never changes. Its slower to start, does not bring any benefit, 2) I can even add binary blob in the kernel nowadays, so I do not need an initrd at all and the packages needed to build them are not even installed 3) There is not always places to copy / in /usr 4) My grub setup does not enable initrd, nor UUID for rot file system because without initrd you just can't, 5) I have machine with a byte of bad memory, and specific grub setup. I do not think you will ever be able to guess the correct grub config 6) I have machine that do network boots, and do not mount /usr the usual way,... The debian installer should first loudly warn that having a separated / and /usr may break things in the future but not forbid it. With that in place, new debian installations that have no good reason for different filesystem for / and /usr will be installed the preferred new way. Old folks that have been doing this for years on hundred of machines will eventually learn new tricks. People that are using this setup for reasons will still be able to do so. So please, do not make that kind of proposition that you will never be able to transition gracefully... -- eric
Re: Re: support for merged /usr in Debian
The debian installer should first loudly warn that having a separated / and /usr may break things in the future but not forbid it. With that in place, This is not true: you just need to use an initramfs. Ok, so it should warn that this setup will soon require to use an initramfs. I just pointed out that this implies a slower boot and consumes times nearly at each package install (plus initrd tools seldom guess right everything that should be in the initrd to function). "I have always done this in a different way" is not a valid use case, sorry. Same for your proposal : nothing really sound except systemd wants it... And again, this is not related to supporting a merged /usr scheme. I think I gave you other reasons for not using an initrd that you have not answered (other did also in the discussion) and other gave you reasons to have /usr separated and not mounted at boot time that you have not answered either. -- eric
Re: Re: support for merged /usr in Debian
>This is not true: you just need to use an initramfs. Ok, so it should warn that this setup will soon require to use an initramfs. It is the Debian default, there is no need to do this. Being debian installer default does not mean any debian users 1) really has any benefit of using it as explained, 2) nor use it after initial installation, Others have expressed better than I did that initramfs by itself is evil and just does what / was supposed to do originally: 1) because of binary firmware blob mainly allthough as explained this can be solved by putting the blob in kernel itself or using modules if things can be started late enough 2) because systemd requires many things that are traditionally located in /usr I for sure hate to have things twice on a system and make sure they are kept coherent by black magic (and using busybox rather than original utilities makes it even more evil...) Same for your proposal : nothing really sound except systemd wants it... Again, this is not related to systemd. I am not interested in continuing this discussion with people who are not understanding the basic facts. Sure. And I'm not interested to discuss with someone that feels so superior to normal human either and does not answer various points that have been detailed in this thread. I'm still 100% against your proposal. -- eric
Re: Re: support for merged /usr in Debian
Note that mounting /usr early, something we *already do*, is separate from actually merging /usr with /bin and /lib. Once you mount /usr early, it's rather less important whether you actually merge the file systems. While it does let you do some interesting things, I see it as more of a cleanup. Thanks for summarizing things so clearly : the root of the problem is indeed to mount /usr early enough at init time. Then : 1) initramfs can be seen as a well known solution that I personally dislike as explained elsewhere in this thread. But I do agree upon the ROI of using such a mechanism provided it is not imposed, 2) no separate partition for / and /usr being another one. I will probably end up changing the way I install new debian system to this one now that even SSD disks are so huge compared to system requirements, 3) merged /usr proposal being a kind of UFO... But could you elaborate a bit on "mounting /usr early, something we *already do*" if you do not implicitly refer to initramfs solution. I understand that for complex fs setup (lvm/raid/mounted networked fs...) this may require to much work to be done realistically at first install (like the solutions above by the way), but for most common cases (two ext4fs on a same disk, or separate disk but same drivers sets), I do not get what really prevents to mount /usr really early and propose that as a viable alternative to the mess (3) we have been proposed. --eric
Re: support for merged /usr in Debian
On 03/01/2016 22:10, Russ Allbery wrote: Eric Valette writes: The problem of getting /usr mounted before things start using it is mostly separate from the question of whether we want to merge it with /bin and /lib. This thread is more about the latter than the former. (Obviously, mounting /usr early is a *prerequisite* for merging /bin and /lib with /usr, which is why it comes up.) Well, I do not see the need for that (merging /bin and /lib with /usr) once /usr is mounted early enough as PATH and LD_LIBRARY_PATH should allow to find binaries and libraries wherever they are at the end when both fs are mounted... If it is just to close once for all the right location philosophical debate, I would say it will be over priced: changing executable PATH will just breaks million scripts people have written themselves on top of original debian install to maintain their system or do whatever their system is really needed for. System admins do like using absolute path for security reasons... -- eric
Re: Re: support for merged /usr in Debian
I'm confused why you think anything will break. There would obviously be symlinks, so anything that's currently in /bin will continue to work if invoked with an absolute /bin path. I consider linking across file system a very bad practice because if /usr gets errors all the symlinks may be broken until it is repaired. Currently / is 600 MB on my system /usr being over 12 GB nad merging will just make it bigger. So there are more chances to break /usr and it takes more time to repair it. Aditionaly remount ro on error is hardly set in fstab and fs_passno is usually 2 not 1... With what you propose, any /usr fs bug will end up inserting a CD or USB key for repair... For sure it is not the case at the moment! Just as another reality check: I believe Red Hat has already done this. Lots of people use Red Hat and derivatives, and there doesn't seem to have been that much breakage. Red hat is mainly for servers nowadays with paying support. So I wonder if you are really doing meaningful comparison. Likewise Systemd was used by various distrib before debian, and it did break a lot at the beginning when upgrading existing debian installs, most init script are still unconverted and they cannot really accommodate the /etc/defaut/pkg configurable options... -- eric
Re: Re: support for merged /usr in Debian
Remember that / and /usr don't have to reside on the same partition with the usrmerge proposal: they only have to be both available post-initramfs. The initramfs already takes care to mount /usr (for the systemd case as initscripts needs updates for sysvinit as was said elsewhere). So no repartitioning should be required on upgrades. As explained elsewhere in this thread, using initramfs is still not mandatory in debian and I personally have more managed debian system installed without it than with it. And the fact that /usr break may require user interaction is not really handled by initramfs and may cause dangling sysmlink in / -- eric
Re: Re: support for merged /usr in Debian
Remember that / and /usr don't have to reside on the same partition with the usrmerge proposal: they only have to be both available post-initramfs. The initramfs already takes care to mount /usr (for the systemd case as initscripts needs updates for sysvinit as was said elsewhere). So no repartitioning should be required on upgrades. As explained elsewhere in this thread, using initramfs is still not mandatory in debian and I personally have more managed debian system installed without it than with it. And the fact that /usr break may require user interaction is not really handled by initramfsand may cause dangling sysmlink in / -- eric
Re: support for merged /usr in Debian
On 04/01/2016 20:43, Michael Biebl wrote: an initramfs is not mandatory as long as you don't have /usr on a separate partition. No initramfs + split /usr is not supported and has been broken for a while. Did you actually test it? It works for me TM on fairly simple setup... -- eric
Re: support for merged /usr in Debian
On 01/06/2016 10:40 AM, Simon McVittie wrote:
On 05/01/16 15:55, Ian Jackson wrote:
Abolishing the distinction between /usr and /
"Merged /usr" is not about removing the distinction between /usr and /,
it's about removing the distinction between subdirectories of /usr and
the corresponding subdirectories of the root, namely /{bin,sbin,lib*}.
"lib*" means lib and lib64 in our case, and maybe lib32 (I forget
whether we have any architectures where that exists). On distributions
that have it, libexec is also in-scope for "merged /usr", but Debian
doesn't have libexec anyway.
I beg do disagree : so far / is almost selfcontained and can be
realisticly used without /usr being mounted. (you even stated this in
your mail after) Booting on / with a non clean/not automagically
repairable /usr works, you do not need to insert a bootable support to
fix things. Putting symbolic link pointing for libraries or binaries to
/usr just breaks that (initrd or not) and it is also said to be broken
in general for people not using initrd...
And yes it does make / growth a lot especially because of systemd
needing a lot libraries or /usr being mounted really early enough. And
you pointed why mounting /usr indeed may require a lot of stuff for
networked mount...
besides the / and /usr merged, I think that a proper/preferred
partitioning scheme has not yet been enough discussed and that the
proposal, while trying to help fixing broken""" partitioning scheme
is only one solution to the real problem : what should be available
(partition, file system hierarchy) and in what form (ro:rw, ...) when
init starts.
For sure there is not something as one for all situation solution, but
if we find realistic solutions for people using custom/self generated
kernel or no initrd, or systemd, sysvinit (put your preferred init
system here) or networked file systems and at least document them or
(dreaming a bit) implement the partitioning scheme in installer that
would be good.
I personally think those factors undermine the "/ as recovery" use-case
Probably a install kernel + dedicated recovery initramfs is indeed a
better solution and could be installed by regular installer and updated
via package upgrade (a bit like metest86+ package does). I think most
people complain because :
1) the amount of things that should be present to have a system
reparable/bootable is just going beyond normal especially for
embedded/non PC case,
2) they are told that their system is likely to stop functioning at
some point in time and nobody will fix it because the installation is
going to be flaged as "non standard" no more supported.
And yes the tool proposed does help fixing some cases but not all.
Maybe a an automatic repartitioning tool (iso/usb image) that could use
some extra disk storage to store / + /usr before providing a repartioned
system disk could also be useful for users even if I agree it is
impossible to resolve all partition migration cases especially with old
bios partitioning sheme and their primary/secondary partitions but for
gpt partitionned devices, this should be simpler...
If only fixing the BL remains ...
-- eric
Re: Re: support for merged /usr in Debian
Russ Allbery writes: For one specific example, it's become quite clear over the past year that systemd has achieved the same status as abortion debates in US politics. Not only is it clear that we will *never* stop arguing about systemd, opposition to or support of systemd has turned into a tribal identity marker for at least some people. Your example comparing systemd debate vs abortion debate is definitively insane : abortion is a philosophical debate that mainly roots whether you believe or not in god, which is not something that can be argued on its technical merits, or the fundamental compatibility problem it causes. The only point were your comparison makes sense is that communication by both opponent and proponent could have been better and less hostile (at least here in France). Part of what ian said (copied below for ref), that has not been done with systemd is definitively the root cause of all the systemd debate I think that people who want to change Debian should take care to: - Communicate respectfully; - Ensure technical interoperability between different approaches and different tools; - Carefully plan necessary transitions; - Approach change in a consensual manner; - Particularly, avoid hostile acts like publicly declaring other people's code or configurations dead or unsupported. I have been criticizing systemd introduction in this newgroup/mailing lists because, at the beginning, it did break nearly all my systems, whereas it should not had: 1) when you find /proc/config.gz and you know that some feature are required for systemd, you could check before installing it and avoid removing sysv init system even if mots pelple do use distribution kernel (without /proc/config.gz you can write program that will check features via system calls). 2) as it started to depend on libraries located in /usr, it did break on my system with no initrd, and different / and /usr and it did break my system at least 5 or six times before stabilizing. I suggested to add a script to make sure sysdemd binary does not link with /usr located libraries to detect this before crashing people installations, So this are clear example were simple technique could have been used to avoid breaking installed systems. It does cost a bit more effort but would have generated far less heated debate and meybe even les work at the end. Now I do see benefits of systemd (boot faster) but the lack of easiness to define user modifiable parts (/etc/defaut/pkg) and things that are better left as the maintainer wants is still complicated and if you need to directly change default /lib/systemd/system/pkg.service its overridden during upgrade... I have nas machines running debian without screen, video output, that have been installed via network and do not have easy way to repartition, not access to bootlodaer to install a different initrd, nor to repair other than soldering a serial line, so saying you should merge / and /usr or it may break and you will be on your own makes me less than happy. I thinks you can understand that. I'll say it again: enthusiasm is fragile. If we slap down excited people every time they make intemperate comments out of enthusiasm, we lose SO MUCH energy. And I don't think we can afford to lose that much energy from the project. Agreed. But making transition smooth, may not cost that much and could preserve motivated people against hostile reactions if their changes breaks people habits/systems. So having a policy like Ian did propose for making fundamental changes may at the end avoid loosing energy.. --eric
Re: Re: Re: support for merged /usr in Debian
On Sun, Jan 10, 2016 at 10:56:21AM +0100, Eric Valette wrote: Russ Allbery writes: >For one specific example, it's become quite clear over the past year that >systemd has achieved the same status as abortion debates in US politics. >Not only is it clear that we will *never* stop arguing about systemd, >opposition to or support of systemd has turned into a tribal identity >marker for at least some people. Your example comparing systemd debate vs abortion debate is definitively insane : abortion is a philosophical debate that mainly roots whether you Unbelievable!! What part don't you understand? He says it's "achieved the same status", even I, understood at least that much. "Achieved the same status" BUT for totally different fundamental reasons so the reasoning is totally void. The analogy by itself, I let him the responsibility of comparing technical decisions to a matter of life or death -- eric
