Entering drakboot in konsole as user or as root results in the launch of drakautologin
Entering drakautologin in konsole returns "no such file"
However in drakconf:
Set up autologin
Set up the boot system
both work as expected.
The ncurses version of drakboot launches in a tty
hm, I thought it was only in cauldron that drakboot had been renamed to drakautologin, and that in Mageia 5, to launch what is drakboot in cauldron, the command "drakboot --boot" was still needed.
But according to our documentation, that was changed between Mga4 and 5
I don't have time now to check the changelog
So I suppose that the bug is actually in the official docs rather than in drakxtools, although the logic of the situation escapes me :)
I checked the cauldron drakxtools changelog now:
r918390 | tv | 2016-01-02 15:20:35 +0100 (za, 02 jan 2016) | 12 lines
o skip swap in the list of partitions (mga#15767)
o split drakautologin from drakboot (mga#7160)
There is nothing like that in the Mageia 5 drakxtools changelog, and in bug #7160, comment #11 we read
> Docteam will need to adjust the MCC manual for Mga6
> 'drakboot' became 'drakautologin'
> 'drakboot --boot' became 'drakboot'
So, we forgot all about this change when we decided to sync the Mga 5 manual with the cauldron one :-(
Assigning to docteam, and CC'ing atelier team.
As a reminder, here are the modifications done in February 2016
1- For the 18 languages in git:
- drakboot.xml in renamed drakautologin.xml and the contents are changed in 6 places (in Calenco)
- drakboot --boot.xml is renamed drakboot.xml and the contents are changed in 4 places (in Calenco)
2- The SC drakboot.png (only one) is renamed drakautologin.png in the 9 languages that had it, that means de, en, et, fr, nl, pt_BR, ro, sv and tr. (in Calenco)
3- The mcc-boot.xml content is changed in 4 places for the 13 languages that have it, that means ca, de, el, en, et, fr, id, it, nl, ro, ru, sv and tr. (in Calenco)
IIUC, we should do a reverse job for mageia 5 help ?
(In reply to André DESMOTTES from comment #4)
> As a reminder, here are the modifications done in February 2016
> 1- For the 18 languages in git:
> - drakboot.xml in renamed drakautologin.xml and the contents are changed in
> 6 places (in Calenco)
> - drakboot --boot.xml is renamed drakboot.xml and the contents are changed
> in 4 places (in Calenco)
> 2- The SC drakboot.png (only one) is renamed drakautologin.png in the 9
> languages that had it, that means de, en, et, fr, nl, pt_BR, ro, sv and tr.
> (in Calenco)
> 3- The mcc-boot.xml content is changed in 4 places for the 13 languages that
> have it, that means ca, de, el, en, et, fr, id, it, nl, ro, ru, sv and tr.
> (in Calenco)
> IIUC, we should do a reverse job for mageia 5 help ?
Just in case anyone considers that: I do certainly not think we should revert anything in Calenco.
If this was the _only_ Mga5->Mga6 change that we forgot about, then, for the html publications (so for both mageia-doc-mcc-* and for http://doc.mageia.org/mcc/5/*/content/drakboot.html and http://doc.mageia.org/mcc/5/*/content/drakautologin.html, I prefer to keep the "wrong" page and screenshot names, but to only change the wrong command.
In http://doc.mageia.org/mcc/5/*/content/drakautologin.html only
and in http://doc.mageia.org/mcc/5/en/content/drakboot.html
Each of those strings might be on two lines in a translation, but the command name will itself will always be on the same line, so it is probably better to let sed or whichever tool is used match and replace both '"subtitle">drakautologin' and 'drakautologin</h2>', etc.
I don't know of a way to fix strings in a pdf file, and even if, at first sight, it seems possible to do it in the epub files, I do not think this mistake is so bad that it would be good to spend a lot of time on fixing it.
About reverting to the previous Mga5 version: for languages in which many new strings were translated, reverting to the previous version that was packaged and published on our website, would be worse than keeping the current one.
It's a pity the new "Release" feature in Calenco doesn't work for us :-(
.... or did you or Yves manage to add and see other Releases than HEAD, and is there an unchanged release from just before the above changes were added?
(In reply to Marja van Waes from comment #5)
> It's a pity the new "Release" feature in Calenco doesn't work for us :-(
> .... or did you or Yves manage to add and see other Releases than HEAD, and
> is there an unchanged release from just before the above changes were added?
It might work now, at least this is the first time I see something happening... trying to create a "test" release, the pop-up became grey and there's a turning cogwheel in it.
However, even if anyone created a Mga5.0 release and can access it, there's this warning in http://mageia.calenco.com:8284/docs/2.9.2/user/en/content/help-workspace-versions.html :
> [Warning] Images Management
> Whenever you update an image in the current release, this image is also
> automatically updated in other releases. This makes it impossible to access
> image content as it was in previous releases.
There _may_ be a better solution.
Camille advised to create a new workspace when we have a new Mageia release, by exporting the old one and importing it into a new one for that release.
I do have:
-rw-rw-r-- 1 marja marja 181M okt 25 2015 calenco_bup2015-10-25zo.12:57.zip
-rw-rw-r-- 1 marja marja 181M nov 3 2015 calenco_bup2015-11-03di.11:10.zip
-rw-rw-r-- 1 marja marja 183M jan 23 2016 calenco_bup2016-01-23za.17:16.zip
-rw-rw-r-- 1 marja marja 184M apr 23 2016 calenco_bup2016-04-23za.19:33.zip
-rw-rw-r-- 1 marja marja 190M aug 28 2016 calenco_bup2016-08-28zo.11:37.zip
-rw-rw-r-- 1 marja marja 190M sep 14 2016 calenco_bup2016-09-14wo.09:35.zip
-rw-rw-r-- 1 marja marja 191M jan 21 09:21 calenco_bup2017-01-21za.09:16.zip
So, in theory, we could use the last one that doesn't contain the unwanted changes and import it into a Mageia5 workspace (if the used additional disk space isn't a problem for Calenco)
but they only contain shrunk screenshots, we'd need to upload all the original screenshots in their original size to that workspace.
I do have backups of the correctly sized screenshots, too, but didn't store them in a smart way.... I'm afraid it'll take an awful lot of time to filter out the needed ones for each language :-(
Sorry for the delay for taking part to the discussions.
When deciding to publish a revision of Mageia documentation, I though to the new translations. I forgotten that we already started to write for Mageia 6. Sorry for that.
Duplication of files are not enough to have a previous state. We have also to duplicate publications configuration. Will the export of the workspace deal with that? This seems to me also to be a huge volume for very small changes. But why not.
Indeed the release feature is not enough for what we want. We can only get the state at the release time, publish the documentation again, but not edit it as in a branch.
I think that we can apply the "sed" method marja proposed above for publications on the site and the documentation as packaged, leaving the PDF and Epub in their current state.