Re: Bug#1020792: tech-ctte: Halt merged-/usr transition until dpkg filesystem damage bugs are fixed
Hi,
I would really appreciate if you quote your reply properly:
It was not Andreas Metzler who sent the below:
> On Tue, 2022-09-27 at 18:25 +0200, Andreas Metzler wrote:
> > On 2022-09-27 Zack Weinberg wrote:
> > [...]
On Wed, 2022-09-28 at 11:55 +0100, Luca Boccassi wrote:
> >
> > > This number is of usrmerged systems is so large that we cannot mark
> > > them as unsupported ("Please reinstall"). Whether this percentage
> > > is 25% or 90% does not matter.
> >
> > You can easily revert any system having usrmerge installed with dpkg-
> > fsys-usrunmess. This should be known by all Debian users, by some
> > suitable channel.
> >
> > And for example the latest init-system-helpers release should add
> > this to the package description (if not reverted). This applies to
> > other present and future packages having usrmerge as a dependency
> > too.
>
> Please note that this will result in an unsupported system, as per CTTE
> decision. It is important to note this, for the record. So no, that
> will not be added anywhere, package description or otherwise, and in
> fact the last time it was "made known by all Debian users" it caused
> quite a lot of damage, and was forcefully reverted.
Please learn how to properly quote/reply to peoples postings :(
Thanks!
Bug#1020792: tech-ctte: Halt merged-/usr transition until dpkg filesystem damage bugs are fixed
On Tue, 2022-09-27 at 18:25 +0200, Andreas Metzler wrote:
> On 2022-09-27 Zack Weinberg wrote:
> [...]
> > What I am asking for is a schedule change: specifically, that the
> > merged /usr transition not be allowed to proceed past the status
> > quo as of two weeks ago (i.e. *before* init-system-helpers added a
> > dependency on usrmerge|usr-is-merged) until after the dpkg bugs are
> > fixed to the satisfaction of the dpkg maintainers.
> [...]
>
> Hello Zack,
>
> Afaiui the only thing the change two weeks caused is an increased
> percentage of usrmerged Debian installations.
>
> Afaict the problem is unchanged: There is a very large number of
> usrmerged systems (every system installed with bullseye installer or
> newer unless some very specific steps were taken to avoid this) which
> are prone to bugs due to dpkg not having been changed *first*. This
> number is of usrmerged systems is so large that we cannot mark them
> as unsupported ("Please reinstall"). Whether this percentage is 25%
> or 90% does not matter.
You can easily revert any system having usrmerge installed with dpkg-
fsys-usrunmess. This should be known by all Debian users, by some
suitable channel.
And for example the latest init-system-helpers release should add this
to the package description (if not reverted). This applies to other
present and future packages having usrmerge as a dependency too.
Thanks!
Bug#947847: please install systemd-sysusers using update-alternatives
On Wed, 2020-01-29 at 12:23 -0800, Moritz Mühlenhoff wrote: > Simon McVittie wrote: > > I think we have a fairly good picture of the costs that would be > > incurred from using alternatives: > > Plus in the case of opentmpfiles; a pile of security issues: systemd- > tmpfiles addresses a number of complex races using low level > primitives like openat() et al. or O_PATH, while opentmpfiles is > implemented in shell. Do you mean that shell scripts cannot cannot handle such issues?? So C- code is safe by construction, do you really believe in that?
Bug#947847: please install systemd-sysusers using update-alternatives
On Wed, 2020-01-29 at 12:24 -0600, Gunnar Wolf wrote: > It's not like having two competing implementations causes much > harm here.we technically _can_ allow any /bin/systemd-* to be > provided by another implementation, that we should (actually, I think > we should clearly _not_). Of course the name should not be systemd-*. That would conflict with systemd upstream, and a lot of other stuff too! > /usr/bin/systemd-* is clearly implementation-specific. Now, if we are > to allow alternative implementations of /usr/bin/system-brewmycoffee, no way! > we should first push to an alternative /usr/bin/brewmycoffee, get the > systemd maintainers to "subscribe" to it using our great alternatives > system, and provide our /usr/bin/open-brewmycoffee. Why should they be subscribing? There are other people within Debian who can provide alternatives. > And I think that now, that not so many packages have yet adopted > systemd-derived facilities, is a great time to set this as a good > practice. Is this your interpretation of the GR?
Bug#947847: [Fwd: Re: Bug#947847: please install systemd-sysusers using update-alternatives]
--- Begin Message --- On Mon, 2020-01-27 at 11:01 -0500, Anthony DeRobertis wrote: > > Strikes me as there is a possible solution, though: have opensysusers > dpkg-divert it and put a shell script in its place that checks which > init system is running, and exec's the right sysusers based on that. It is as simple as: if ps -p1|grep -q "systemd"; then else fi > This wouldn't affect systemd-only machines (as opensysusers would not be > installed at all), and would do the right thing if someone has installed > two init systems to, e.g., consider switching. It'd need to be a script > that the systemd maintainers feel reasonably confident will always run > systemd's implementation when systemd is running, to avoid the mixed > implementations issue. --- End Message ---
Re: Bug#947847: please install systemd-sysusers using update-alternatives
On Mon, 2020-01-27 at 11:01 -0500, Anthony DeRobertis wrote: > > Strikes me as there is a possible solution, though: have opensysusers > dpkg-divert it and put a shell script in its place that checks which > init system is running, and exec's the right sysusers based on that. It is as simple as: if ps -p1|grep -q "systemd"; then else fi > This wouldn't affect systemd-only machines (as opensysusers would not be > installed at all), and would do the right thing if someone has installed > two init systems to, e.g., consider switching. It'd need to be a script > that the systemd maintainers feel reasonably confident will always run > systemd's implementation when systemd is running, to avoid the mixed > implementations issue.
Re: Bug#914897: debating the wrong thing
On Tue, 2018-12-04 at 21:58 +0100, Ansgar Burchardt wrote: > > If we keep merged-/usr as default then we can /recommend/ people to > install usrmerge to switch to merged-/usr; reducing the difference > between newly-installed and existing setups is a good idea IMHO. I > think I filed a report for this two years ago. > > Maybe we should also mention somewhere that it might be useful to not > switch build environments (yet). How about this case: - Make as default non merged-/usr for all buildds. - Make a choice of non merged-/usr or merged-/usr in the installer. - Users wanting merged-/usr install the usrmerge package and convert to merged- /usr. - We have two alternatives here: 1) For those not wanting merged-/usr: All is fine. 2) For those having merged-/usr installed: Re-run usrmerge to convert all newly installed packages to merged-/usr. Is this possible or is installing that package a install-once-only? Just a thought!
Bug#914897: debootstrap, buster: Please disabled merged /usr by default
On Sun, 2018-12-02 at 21:04 +0100, Marc Haber wrote: > > The next debhelper change might choose to give / instead of /usr as a > target directory by default, moving hundreds of megabytes from /usr to / > over time. This solution was proposed by GNU/Hurd several years ago, and was scrapped due to not being big enough player in the *NIX world: https://www.gnu.org/software/hurd/faq/slash_usr_symlink.html The distinction between / and /usr has historical reasons. Back when Unix systems were booted from two tapes, a small root tape and a big user tape. Today, we like to use different partitions for these two spaces. The Hurd throws this historical garbage away. We think that we have found a more flexible solution called union filesystems, which allow to create virtual filesystems which are the union of several other filesystems. However, support for union filesystems is still in early development. About unionfs: Unionfs allows you to simply union one directory or translator into another one, so you see the files of both of them side by side. More here: https://www.gnu.org/software/hurd/hurd/translator/unionfs.html
Bug#762194: Debian has abandoned many users also on upgrades by the CTTE decision on December 4 2014
Hello, Looking at the IRC log http://anonscm.debian.org/cgit/collab-maint/debian-ctte.git/tree/meetings/20141204/debian-ctte.2014-12-04-18.00.log.txt lines 197 to 280 reveals the plan. Conclusion: quoting vorlon Steve Langasek: we recommend/support systemd being the default init system for upgrades as well as new installs Action point: quoting dondelelcaro Don Armstrong: #action dondelelcaro to draft affirmative resolution on #762194 noting #757298 et al More details: (if using apt, see also #757298 about the grub2 entry) - upgrading from Wheezy/with sysvinit to Jessie can boot with init=/lib/sysvinit/init unless/until the sysvinit package is removed by e.g. autoclean. CAUTION: don't autoclean until you have installed sysvinit-core if you don't want systemd-sysv! - dist-upgrading Wheezy/with sysvinit to Jessie will get systemd-sysv, and sysvinit will be history!! (unless you install sysvinit-core on next reboot (if your system boots)) - grub will obtain a menu entry to boot with init=/lib/sysvinit/init if something goes wrong with the switch to systemd-sysv (unless you dist-upgrade). If you are using some other bootloader, e.g. LILO you are on your own. - people not careful enough are on their own: quote from Tollef Fog Heen at some point, it's the user shooting their foot off I wonder what the people not having physical access, e.g. ssh, to their boxes should do, not even able the see the boot screen? Very nice conclusions and actions ;) -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1417804266.3453.97.ca...@g3620.my.own.domain
Bug#762194: Summary:Re: Bug#762194: Proposal for upgrades to jessie
On Fri, 2014-11-28 at 12:56 +0100, Svante Signell wrote: Hello, In summary: a) Upgrades should _not_ change init: whatever is installed should be kept. b) New installs should get systemd-sysv as default init with a debconf message about alternative init systems. More detailed: 1) Fix debootstrap bugs 2) Add a (non-aborting) debconf message referring to release-notes on how to install sysvinit-core when installing from scratch. 3) Add information in release-notes on how to: - Upgrade from stable/testing/sid to jessie to avoid getting systemd-sysv installed (this should not strictly be needed if the ctte chooses to decide that upgrades will _not_ switch init) - Install sysvinit-core after installation and reboot after getting systemd-sysv as default. 3.1) I'll file a bug against release-notes as written above. Hopefully the ctte will make a decision on init system for upgrades to Jessie today! FYI: Bugs for release-notes on upgrades, #771825, and installation-guide (and perhaps debian wiki) on new installs (pending), are in the pipe! -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1417692256.3453.60.ca...@g3620.my.own.domain
Bug#762194: Summary:Re: Bug#762194: Proposal for upgrades to jessie (lendows 1)
One claim is changed, see below. On Fri, 2014-11-28 at 12:56 +0100, Svante Signell wrote: Hello, In summary: a) Upgrades should _not_ change init: whatever is installed should be kept. b) New installs should get systemd-sysv as default init with a debconf message about alternative init systems. Since there is no interest in adding a debconf message on new installs, I wish for a menu entry in the advanced part of the installer to be able to install a new system with sysvinit-core or upstart! -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1417284908.6826.3.ca...@gmail.com
Bug#762194: Summary:Re: Bug#762194: Proposal for upgrades to jessie (lendows 1)
On Sat, 2014-11-29 at 20:19 +, Adam D. Barratt wrote: On Sat, 2014-11-29 at 20:40 +0100, Svante Signell wrote: This is another nail in the Universal OS coffin: Let's move to devuan, please! You are of course free to do that. This discussion is about what Debian should do, however. If you wish to discuss Devuan, please do so in a more appropriate forum. Yes, I'll do that. But it does not seem like you are realizing what is happening unfortunately. Debian will not be as it was historically due to this issue. Maybe the new DDs are to young to learn from history? -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1417292862.6826.11.ca...@gmail.com
Bug#762194: Summary:Re: Bug#762194: Proposal for upgrades to jessie
Hello, In the (last) hope that the CTTE will bring this issue on the agenda next meeting on December 4. Additional information below and a short summary. On Wed, 2014-11-26 at 09:56 +0100, Thorsten Glaser wrote: On Tue, 25 Nov 2014, Svante Signell wrote: (another partial? solution is to change order of the (pre-)depends of the init package, as proposed in No, that breaks due to the bug in debootstrap’s dependency “resolver” (see #557322, #668001, #768062) and the unwillingness of KiBi to fix that. That is, it breaks fresh installs. Note, this (long-time) refusal to make changes to that package has to be weighted in when the CTTE is discussing this issue: There are very small patches available before the freeze Wed, 5 Nov 2014 (Sun, 22 Nov 2009 and Fri, 17 Oct 2014) that has not been addressed by the maintainer: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=557322#24 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668001#20 and reported working https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668001#50 And according to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762194 with preliminary results in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762194#142 the order of pre-depends for int init package should change from Pre-Depends: systemd-sysv | sysvinit-core | upstart to Pre-Depends: sysvinit-core | systemd-sysv | upstart (I hope I made the correct links and conclusions) 1) Heavily advertise (release-notes?) that doing an upgrade from wheezy/etc to jessie will give you systemd as init system and inform about the apt pinning solution. That should be a given, a minimum, independent of the others. I'll file a bug against release notes about the release-notes! In summary: a) Upgrades should _not_ change init: whatever is installed should be kept. b) New installs should get systemd-sysv as default init with a debconf message about alternative init systems. More detailed: 1) Fix debootstrap bugs 2) Add a (non-aborting) debconf message referring to release-notes on how to install sysvinit-core when installing from scratch. 3) Add information in release-notes on how to: - Upgrade from stable/testing/sid to jessie to avoid getting systemd-sysv installed (this should not strictly be needed if the ctte chooses to decide that upgrades will _not_ switch init) - Install sysvinit-core after installation and reboot after getting systemd-sysv as default. 3.1) I'll file a bug against release-notes as written above. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1417175791.11764.416.ca...@g3620.my.own.domain
Bug#762194: Proposal for upgrades to jessie
On Wed, 2014-11-26 at 09:56 +0100, Thorsten Glaser wrote: On Tue, 25 Nov 2014, Svante Signell wrote: 2) In case you missed doing the above, you get a debconf prompt when No, no, no, no, no, no, no! Again: aborting the dist-upgrade in the debconf of one package may leave the system an ugly mess, especially if you don’t preconfigure packages. I did _not_ propose aborting the dist-upgrade here. Sorry for not being clear enough. The proposed debconf prompt is just for information: hit return to continue -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1416993577.11764.317.ca...@g3620.my.own.domain
Bug#762194: Proposal for upgrades to jessie
On Wed, 2014-11-26 at 09:56 +0100, Thorsten Glaser wrote: On Tue, 25 Nov 2014, Svante Signell wrote: Does that work, anyway (i.e. does installing systemd and immediately reverting to sysvinit leave the system net unchanged, modulo the dependencies it pulls in (see planet post))? I've installed testing (basic install) on a new box and immediately after first reboot installed sysvinit-core. That worked for me, but as written before, it can create problems for people having different preferences set. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1416994053.11764.322.ca...@g3620.my.own.domain
Bug#762194: Proposal for upgrades to jessie
On Wed, 2014-11-26 at 14:46 +, Neil McGovern wrote: Hi, On Tue, Nov 25, 2014 at 09:29:28PM +0100, Svante Signell wrote: 1) Heavily advertise (release-notes?) that doing an upgrade from wheezy/etc to jessie will give you systemd as init system and inform about the apt pinning solution. 3) Heavily advertise (again in release notes?) that you need to install sysvinit-core and add the pinning file _before_ dist-upgrading. See https://anonscm.debian.org/viewvc/ddp/manuals/trunk/release-notes/en/issues.dbk?view=markup lines 170 to 223. Are you after something different? How about raising a bug against the release-notes package before asking tech-ctte to do something? Is it possible to get access to edit those pages? By filing a bug against release-notes? Note that the only technical in the above is the creation of a debconf prompt in pre/post-inst of the init package. All the rest is just a matter of writing. To clarify: debconf prompt - debconf message, meaning that the install is not to be aborted, only an informal message is written and hit CR to continue. Is it possible to propose a text here? Alternatively: The only hard bit of the above is the creation of the release notes. All the rest is just a matter of coding. YMMV -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1417015399.11764.347.ca...@g3620.my.own.domain
Bug#762194: Alternative proposal for init switch on upgrades.
On Sun, 2014-11-23 at 13:55 -0700, Bdale Garbee wrote: Svante Signell svante.sign...@gmail.com writes: Do people use the usb stick/cd/dvd etc for upgrades to jessie, i.e. the debian installer. Or do they only use apt/aptitude/etc? I don't know that we can speak in absolutes, but I've never personally seen or heard of anyone using debian-installer to do an upgrade. Has the proposed (pre-)depends ordering on init been tested and the results known? The technical solution asked for in #765803 might be the above for upgrades. The installer is not used for upgrades and is no issue here. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1416945651.11764.294.ca...@g3620.my.own.domain
Bug#762194: Proposal for upgrades to jessie
Hello, Below is a proposal for a (partial) solution for the upgrade problem of keeping the installed init system: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765803 This has been discussed privately among selected users/DM/DDs and since the deadline for the ctte is December 4, it has to be known to them (and -devel for comments). (another partial? solution is to change order of the (pre-)depends of the init package, as proposed in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762194 with preliminary results in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762194#142) 1) Heavily advertise (release-notes?) that doing an upgrade from wheezy/etc to jessie will give you systemd as init system and inform about the apt pinning solution. 2) In case you missed doing the above, you get a debconf prompt when installing the init package that if you want to keep sysv/openrc/etc continue with the installation, get systemd-sysv installed and after that install sysvinit-core and do the pinning. (This is suboptimal, many peoples systems could be broken at first reboot, we will find out in due time). Another issue is upgrading from testing/sid?/etc (different status) to jessie: 3) Heavily advertise (again in release notes?) that you need to install sysvinit-core and add the pinning file _before_ dist-upgrading. Note that the only technical in the above is the creation of a debconf prompt in pre/post-inst of the init package. All the rest is just a matter of writing. Sincerely! -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1416947368.11764.312.ca...@g3620.my.own.domain
Bug#762194: Alternative proposal for init switch on upgrades.
On Sun, 2014-11-23 at 03:10 +0100, Adam Borowski wrote: On Sat, Nov 22, 2014 at 05:29:42PM -0800, Cameron Norman wrote: I would like to propose a different one. [...] So, the change would be that: the sysvinit package would cease being a transition / shim package, however it would not signal that a user explicitly installed sysvinit; sysvinit-core would be a simple package that just depended on sysvinit, and the presence of this package *would* signal that the user explicitly installed sysvinit; init would (pre-)depend on systemd-sysv | sysvinit | sysvinit-core | upstart. I'm afraid this doesn't allow partial upgrades from wheezy to use systemd-sysv, as sysvinit is an essential package there, and apt considers packages to be essential if they're present in any source. Do people use the usb stick/cd/dvd etc for upgrades to jessie, i.e. the debian installer. Or do they only use apt/aptitude/etc? -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1416742353.11764.280.ca...@g3620.my.own.domain
Re: Bug#762194: On automatic init system switching on upgrade
On Wed, 2014-11-19 at 13:51 +0100, Ansgar Burchardt wrote: Hi, I would like to see an end to open questions on systemd in Jessie. So, given that the GR is over and no technical proposals for not switching init systems on upgrade to Jessie have been made, is it possible to draw a conclusion to this issue now? I'm not sure there is much to gain from waiting longer... Hi Ansgar and especially the ctte members, Now when the GR outome is know it is time for the ctte to resolve the bug report first issued by me in #747535, then issued by Ian in #762194 to the ctte, and then by me to the ctte in #765803. According to the ctte announcement https://lists.debian.org/debian-devel-announce/2014/11/msg0.html the important parts of that text is: 3. We do not want to prejudge, interfere with, or contradict, the General Resolution process on init systems which is currently ongoing. Some of the GR options imply that automatic switching (both during upgrades, and during leaf package installations) will be necessary in at least some circumstances. The GR is now resolved: No GR required. 4. For the moment, we invite concrete proposals for technical changes which would arrange that 1. new jessie installations using Linux would get systemd but 2. existing installations retain their existing init system so far as possible. Solutions exists or are in the works for solving this. 5. After the result of the General Resolution is known, we intend to formally resolve the question of automatic switching of init systems. Our decision on that question will of course be consistent with the successful General Resolution option, whatever that may be. This issue is not resolved, and since the GR did not give any answer on the above problem, this question now bounces back to the ctte! Now with three less members, down to five :( Or can the resigning members still be part of deciding on this issue? Note also that the bug about automatic switching of init systems was issued in March this year by me, and brought to the ctte in September by Ian and me in October. Ian is/was was in the ctte, but I'm not, so the question about if a ctte member can issue an issue to the ctte, and vote at the same time does not apply in this case. (in case somebody questions the involvement by Ian (as has been done)). Bug #746578 is now resolved by the ctte in https://lists.debian.org/debian-devel-announce/2014/11/msg00010.html about the order of systemd-shim and systemd-sysv, but the above bugs still have to be resolved by the ctte. So Ansgar, this has to be dragged on for still some while. Thank you for your attention. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1416436750.11764.125.ca...@g3620.my.own.domain
Bug#765803: tech-ctte: Ask before changing init system when upgrading to jessie and Inform about init systems when installing jessie
Package: tech-ctte Severity: Important When upgrading an old system installing certain packages, like network-manager and gdm3 systemd-sysv is installed changing the init system. These packages depend on libpam-systemd, which depends on systemd-sysv | systemd-shim. If systemd-shim is not installed systemd-sysv will be, and the init system changes the default to systemd-sysv, and changing PID 1. Changing init system, i.e. PID1, should be warned about loudly by debconf. Not all users want to change init system when doing and upgrade, of course this should not happen (sometimes unnoticed by upgrading a lot of packages). For new installations the situation is different, systemd is the default init system. Nevertheless, perhaps even for new installations the user should be given a choice. At least on how to reinstall sysvinit-core after installing the default init system: systemd-sysv in the Debian Installer (DI) (if not solvable by other means in the DI). The bug on (and the discussion there) on systemd-sysv: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=747535 has ping-ponged in severity and the systemd maintainers always downgrade the severity to wishlist and tagged it wontfix. The only way to resolve this issue is that the CTTE makes a decision on this matter. Other bugs related to this issue are: 760601 764186 746578 In summary, the CTTE is asked to make a decision on debconf warnings on: 1) Changing init system on upgrades (including sid) 2) Inform about alternate init systems for new installations Thank you for your attention! -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1413631957.27347.45.ca...@g3620.my.own.domain
Bug#636783: TC casting vote
On Fri, 2014-05-23 at 08:32 +0200, Lucas Nussbaum wrote: On 22/05/14 at 10:14 -0700, Steve Langasek wrote: On Thu, May 22, 2014 at 03:56:26PM +0100, Ian Jackson wrote: We have had some discussion about this. No-one seems to have objected to the suggestion that the DPL, rather than the TC chairman, should have a casting vote in TC decisions. I'm therefore intending to roll this up into my TC GR(s). I don't recall seeing this discussion. I don't agree that this is a good structural change, for similar reasons to Tollef. Same here. Additionally: 1/ it would feel quite strange if the DPL suddenly had to dig deeply into a controversial issue at the end of the voting period, without taking part in the earlier technical discussion. 2/ the DPL is not chosen using the same criteria as the TC members, and we may very well have a DPL that is not trusted by the project for his/her technical skills. So it would mean turning a technical decision into a political one. 3/ a recent GR (the code of conduct one) showed that Developers were not big fans of the idea of deferring out-of-the-usual-scope decisions to the DPL. The solution is simple: Have an odd number of members in the TC. Then no casting vote is needed at all. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1400830927.17164.2.ca...@g3620.my.own.domain
Re: Bug#727708: init system coupling etc.
* Russ Allbery (r...@debian.org) [140212 19:00]: Packages should normally support the default Linux init system. There I would drop the word Linux here - Packages should support our default init systems. If you do that then you have killed all non-linux architectures, is that intentional? Debian is digging their own grave with respect to Free Software (not not FOSS or FOS), why don't you align with M$soft, Apple or especially RedHat :( Debian will just be a memory in a few years, RedHat will be the solution for everybody (TM). -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1392492790.3779.94.camel@PackardBell-PC
Bug#727708: init system coupling etc.
On 2014-02-14 15:46:18 +, Ian Jackson wrote: Ansgar Burchardt writes (Bug#727708: init system coupling etc.): Don't you mean drop GNOME, KDE and others? It's not only GNOME that plans to depend on logind... logind is a red herring because AIUI we already have a technical solution to that. The problem is other things that might be in the pipeline. It does not, see e.g. bug: 736880, or bug 602724, wrt gdm3 a really old one. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1392493734.3779.100.camel@PackardBell-PC
Bug#727708: init system coupling etc
Debian is digging their own grave with respect to Free Software (not FOSS or FOS), why don't you align with M$soft, Apple or especially RedHat :( Debian will just be a memory in a few years, RedHat will be the solution for everybody (TM). Please take this sort of thing to some other mailing list. It's not going to change the mind of anyone here; it's just annoying and basically content-free Never mind now, just please read this message in (about) three years from now, and judge for yourself (am I a fortune teller, or not? :)) -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1392495175.3779.110.camel@PackardBell-PC
Bug#727708: Why open voting?
Hi, Following this bug report for several months now this is really becoming a farce. Who is in charge calling for votes, and why don't you have a closed voting procedure? Of course the people voting later has a advantage against the others. Have you ever heard of game theory? This is like scheduling four quarter finals in e.g. football championship -after_ each other, not concurrent. Things like this happens, but is very seldom in high quality sports/events :-( -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1391975253.18980.26.ca...@g3620.my.own.domain
Bug#727708: init system resolution - revised proposal
To CTTE, In the wait for your decision next week, many of us assume that you take into consideration the many misleading and false statements that have been written about about sysvinit + openrc/insserv. Additionally, consider this, please: Adopting systemd (and gnome, dbus-kdbus, wayland, etc depending on it) is very dangerous for the future of Free Software :-( (I wonder which view FSF would have if they had been involved) Thanks, have a nice weekend! -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1391175670.20080.53.ca...@g3620.my.own.domain
Bug#727708: Cut-and paste typo
I think you made a c-p typo, see below: That will leave us voting on (most likely): Dsystemd default in jessie, say nothing about multiple inits DM systemd default in jessie, support multiple inits Usystemd default in jessie, say nothing about multiple inits ^upstart UM systemd default in jessie, support multiple inits ^upstart Oopenrc default in jessie Vsysvinit default in jessie GR project should decide via GR FD further discussion Otherwise the voting would (almost) not be needed! -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1391095387.7040.23.ca...@s1499.it.kth.se
Bug#727708: Regarding sysvinit+openrc/insserv
Who wrote the parts of sysvinit+openrc and sysvinit+insserv? Maybe that person should modify some of the faulty information for these cases. Some points: sysvinit+insserv/openrc: D-Bus interfaces: Why are they needed, nothing of this is defined by POSIX? And dbus is already heavily depending on systemd on GNU/Linux: Build-depends:... libsystemd-daemon-dev (= 32) [linux-any], libsystemd-journal-dev (= 32) [linux-any], libsystemd-login-dev (= 32) [linux-any] sysvinit+openrc: Remove: OpenRC’s support for parallel boot is not production-ready: wrong, see the upcoming 0.12.4+20131230-8 Add: OpenRC is developing quickly, many of the missing features will soon be there. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1391107274.7040.40.ca...@s1499.it.kth.se
Bug#727708: openrc: Updated patches making openrc work properly on Debian GNU/Hurd
Whatever you have decided about Linux only, this is relevant
information. Debian is about versatility in the Unix/Posix way, not any
proprietary locked-in thing. If you continue this track Debian will no
longer be a Universal operating system. And users will choose to go
for a FREE SOFTWARE solution (not a locked-in one)!
Package: openrc
Version: 0.12.4+20131230-7
Severity: important
Tags: patch
Usertags: hurd
Hi, the recent patches 0100-GNU-Hurd_PATH_MAX_and_defined.patch and
0110-GNU-Hurd_add-missing-files.patch enables a successful build of
openrc for GNU/Hurd. However, to make it work properly 0110-* has to be
modified, and #721917 to be applied! Attached is an updated patch of
0110-GNU-Hurd_add-missing-files.patch.
Of course some minor things, like mount parameters still has to be
modified, but the basic functionality is there :)
Thanks!
Description: Adds missing files for GNU Hurd
Author: Thomas Goirand z...@debian.org, Svante Signell svante.sign...@gmail.com
Forwarded: no
Last-Update: 2014-01-06
Index: openrc-0.12.4+20131230/etc/rc.conf.GNU
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ openrc-0.12.4+20131230/etc/rc.conf.GNU 2014-01-24 12:03:48.669658957 +0100
@@ -0,0 +1,15 @@
+##
+# GNU/Hurd SPECIFIC OPTIONS
+
+# This is the subsystem type. Valid options on GNU/Hurd:
+# - nothing special
+# subhurd - Hurd subhurds (to be checked)
+# If this is commented out, automatic detection will be used.
+#
+# This should be set to the value representing the environment this file is
+# PRESENTLY in, not the virtualization the environment is capable of.
+#rc_sys=
+# This is the number of tty's used in most of the rc-scripts (like
+# consolefont, numlock, etc ...)
+#rc_tty_number=6?
+
Index: openrc-0.12.4+20131230/sh/init.sh.GNU.in
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ openrc-0.12.4+20131230/sh/init.sh.GNU.in 2014-01-25 18:48:04.227762627 +0100
@@ -0,0 +1,43 @@
+#!@SHELL@
+# Copyright (c) 2007-2009 Roy Marples r...@marples.name
+# Copyright (c) 2014 Svante Signell svante.sign...@gmail.com
+# Released under the 2-clause BSD license.
+# This basically mounts $svcdir as a ramdisk, but preserving its content
+# which allows us to run depscan.sh
+# FIXME: Modify for GNU/Hurd
+
+mount_svcdir()
+{
+# RC_LIBEXECDIR=/lib/rc
+# RC_SVCDIR=/lib/rc/init.d
+einfo Executing /lib/rc/sh/init.sh
+if ! fstabinfo --mount $RC_SVCDIR; then
+ if ! mountinfo -q $RC_SVCDIR; then
+echo $RC_SVCDIR not mounted
+ro=0
+rc=`fsysopts / | grep -q readonly`
+if [ $? = 0 ]; then
+ ro=1
+ echo $RC_SVCDIR not writable
+ fsysopts / --writable
+ echo Creating $RC_SVCDIR
+ mkdir -p $RC_SVCDIR
+ echo Mounting $RC_SVCDIR on tmpfs
+
+ rc=`mount -t tmpfs -o mode=0755,no-suid,size=10% tmpfs $RC_SVCDIR`
+ if [ $? != 0 ]; then
+echo Unable to mount tmpfs on $RC_SVCDIR.
+echo Can't continue.
+exit 1
+ fi
+ if [ ro = 1 ]; then
+fsysopts / --readonly
+ fi
+fi
+ fi
+fi
+}
+
+. $RC_LIBEXECDIR/sh/functions.sh
+[ -r /etc/rc.conf ] . /etc/rc.conf
+. $RC_LIBEXECDIR/sh/init-common-post.sh
Index: openrc-0.12.4+20131230/conf.d/network.GNU.in
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ openrc-0.12.4+20131230/conf.d/network.GNU.in 2014-01-24 08:32:52.0 +0100
@@ -0,0 +1,4 @@
+
+# You can assign a default route
+#defaultroute=gw 192.168.0.1
+#defaultroute6=gw 2001:a:b:c
Index: openrc-0.12.4+20131230/mk/os-GNU.mk
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ openrc-0.12.4+20131230/mk/os-GNU.mk 2014-01-24 08:32:52.0 +0100
@@ -0,0 +1,8 @@
+# Copyright (c) 2008 Roy Marples r...@marples.name
+# Released under the 2-clause BSD license.
+
+SFX= .GNU.in
+PKG_PREFIX?= /usr
+
+CPPFLAGS+= -D_BSD_SOURCE -D_XOPEN_SOURCE=700
+LIBDL= -Wl,-Bdynamic -ldl
Index: openrc-0.12.4+20131230/conf.d/staticroute.GNU.in
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ openrc-0.12.4+20131230/conf.d/staticroute.GNU.in 2014-01-24 08:32:52.0 +0100
@@ -0,0 +1,7 @@
+# Separate multiple routes using ; or new lines.
+# /etc/route.conf(5) takes precedence over this configuration.
+
+# Example static routes. See route(8) for syntax.
+# FIXME: net ... not supported
+#staticroute=net 192.168.0.0 -netmask 255.255.255.0 --address 10.73.1.1
+#net 192.168.1.0 -netmask 255.255.255.0 --address 10.73.1.1
Index: openrc-0.12.4+20131230/init.d/sysctl.GNU.in
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ openrc-0.12.4+20131230/init.d/sysctl.GNU.in
Bug#727708: gdm3 is still gravely buggy even in Linux!
... On Sun, Jan 19, 2014 at 07:23:17PM +0100, Josselin Mouette wrote: ... I also have to insist that GNOME 3.10+ *needs* a working logind even for basic functionality, ... Can you elaborate on where exactly upstream GNOME 3.10 has a hard dependency on logind, and no alternative ConsoleKit codepath that could be used instead? Regarding gnome there is still a grave bug on gdm3 wrt systemd-logind in GNU/Linux I have tried to report, making it unusable on up till now three boxes upgraded (and subsequently replaced by lightdm and xfce4). Maybe we should have a discussion about default desktop system too. I tried to reopen bug #727708 but failed, and have to find the time to submit a new bug report. Problem is that in order to submit a bug report with report-bug you need a working desktop, but when gdm3 is buggy, how to report when it is no longer installed. Just my few cents as a _very_ frustrated (no longer) gnome user. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1390160256.9619.89.ca...@g3620.my.own.domain
Bug#727708: gdm3 is still gravely buggy even in Linux!
On Sun, 2014-01-19 at 19:44 +, Steven Chamberlain wrote: On 19/01/14 19:37, Svante Signell wrote: I tried to reopen bug #727708 but failed Was that a typo? That's the bug number of the Debian tech-ctte bug. Yes, bug number is 724731, sorry. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1390161150.9619.99.ca...@g3620.my.own.domain
