Hmmm, I distantly recall this dorsync script issue before. Last line is fix. Tony $ ./dorsync You need to install udisks to run this program # urpmi udisks No package named udisks # urpmi udisks2 Package udisks2-2.10.1-1.2.mga9.x86_64 is already installed Fix: in line 46 of dorsync change udisks to udisks2
Assuming someone from QA team will fix this, thus assigning to QA. Please assign back if I'm wrong.
CC: (none) => marja11Assignee: bugsquad => qa-bugs
Summary: won't run until single char fix => dorsync won't run until single char fix
Before the edit, dorsync refuses to run, as described in comment 0. After the edit, it does run, though with one fault yet. Dorsync checks for the sha1 checksum, which we no longer use, and reports it as "missing." That should be fixed as well, but it doesn't affect the rest of the script. Checks for md5 and sha512 are still performed, so I believe that covers this bug. Validating, but I don't know where it is to go from here.
Keywords: (none) => validated_updateCC: (none) => andrewsfarm, sysadmin-bugs
Well, the "Function to list USB sticks" at end of the file seems to need a correction too. Shouldn't "udisksctl info" be used, instead of "udisks --show-info"? And maybe more changes are needed, if the udisksctl output differs from the old udisks one?
Yes to Comment 3. I'd not tested that. See below: $ ./dorsync Do you want to Rsync (R), skip Rsync and just dump to usb (D) or quit (Q): d egrep: warning: egrep is obsolescent; using grep -E egrep: warning: egrep is obsolescent; using grep -E egrep: warning: egrep is obsolescent; using grep -E egrep: warning: egrep is obsolescent; using grep -E egrep: warning: egrep is obsolescent; using grep -E egrep: warning: egrep is obsolescent; using grep -E ./dorsync: line 289: udisks: command not found ./dorsync: line 293: [: =: unary operator expected No USB drives found. Please insert one now. Press Q to quit or any other key to continue:
... but I really like dorsync - worth fixing!
This bug is for Cauldron only and no RPMs are listed. That doesn't seem right.
CC: (none) => dan
There isn't an rpm in the repos. The dorsync script is available for download at https://gitweb.mageia.org/qa/dorsync/plain/dorsync I don't have the know-how or know the procedure, or who would do it, but the script that is there needs to be repaired/updated and replaced. Should this be a "Website" bug? That doesn't really sound quite right, either.
Source RPM: https://gitweb.mageia.org/qa/dorsync/plain/dorsync => (none)
I have no idea what this script is for. Is it for QA people to run on their workstations? Then IMHO it really ought to be put into an RPM so those people can easily install the correct version to run it, the same way as mgaadv (for example). Is it just used in some kind of automation on the servers? Then the Infrastructure group would make more sense, although there's a good case for making an RPM out of it in that case as well, such as mgapeople or youri (for example). Asking QA people to install a script from a gitweb site and keep it up to date manually seems a lot to ask.
This script is used to download ISOs for testing, and later update them. Yes having it as an rpm would be nice.
CC: (none) => fri
It is a command line script to do essentially the same thing as Mageiasync. More properly, since dorsync was written first by several years, Mageiasync is a GUI version of the dorsync script. Usage is described in https://wiki.mageia.org/en/ISO_testing_rsync_tools#Dorsync I don't see any reason why it shouldn't be made into an rpm. Maybe tweaked a little here and there to make it easier for a novice, but then making it easier for a novice is why Mageiasync was created. Why do we need/want both? Because some users prefer a GUI, while others prefer the command line.
Keywords: validated_update => (none)
I think I can fix the script. Let me see how far I can go.
Status: NEW => ASSIGNEDAssignee: qa-bugs => LpSolit
Created attachment 15210 [details] shellcheck log Since someone is updating the script anyway, shellcheck has a lot of suggestions for improving it, most of which look good to me. I'm happy to implement the changes but I don't know how to test them. I'll upload the shellcheck log for posterity.
Created attachment 15211 [details] patch, v1 This fixes issues reported above.
Updating the summary as the code was broken. The output of udisks and udisksctl are different, and they do not display the same fields. That's why I also use udevadm to get the missing data.
Summary: dorsync won't run until single char fix => dorsync doesn't run anymore because udisks is now obsolete
commit 197650b84d9ff5c696fb1dafa9237c3354542137 Author: Frédéric "LpSolit" Buclin <lpsolit@...> Date: Sat Dec 13 03:30:58 2025 +0100 Fix dorsync with udisks2 (mga#34826) The output of udisks and udisksctl are different, and they do not display the same fields. Now use udevadm to get the missing data. --- Commit Link: https://gitweb.mageia.org/qa/dorsync/commit/?id=197650b84d9ff5c696fb1dafa9237c3354542137
I've pushed your change in comment 13 as well as fixes for most of the shellcheck issues. Does someone want to make an RPM out of this? I could tag a release of this first if so.
Created attachment 15213 [details] replace sha1sum by sha3-512sum Here is another patch which replaces sha1sum by sha3-512sum. This patch also fixes arguments passed to rsync. I cannot commit the patch myself to the dorsync repo: lpsolit DENIED by fallthru :(
I've submitted that patch as well. I'll try to figure out next week why you don't have git access. What git URL are you using?
I can work on a RPM.
CC: (none) => bruno
(In reply to Bruno Cornec from comment #19) > I can work on a RPM. Wait before creating one. There is still some work to do first. Parameters such as the login and password must be moved out of the script, else they will be erased after each new update. I will work on it later next week.
Package submitted to cauldron. Please test. I use version 2.91. We should to tag the next version with that name and adapt the spec file to refer to it instead of master as of now.
(In reply to Frédéric "LpSolit" Buclin from comment #20) > (In reply to Bruno Cornec from comment #19) > > I can work on a RPM. > > Wait before creating one. There is still some work to do first. Parameters > such as the login and password must be moved out of the script, else they > will be erased after each new update. I will work on it later next week. It's easy to source a conf file which would contain these info and not be part of the package. if [ -e /etc/dorsync.conf ]; then source /etc/dorsync.conf fi declare in it the variables you need Bruno. Anyway the package is also in test so I can update easily once you've pushed your modifications.
This bug was filed against Cauldron but once this is ready I think it should be made available in Mageia 9, too. Consider, what better way to thoroughly test than with the many rounds of Mageia 10 isos to come? I suppose policy would dictate that it be a backport for Mageia 9, but exceptions to that policy have been made in the past if there was sufficient reason. What do you guys think?
I agree with you. I can make it easily a backported RPM or just an update. This only make sense for QA anyway I think, so won't disturb others. Let me know what's you preferred solution.
(In reply to Dan Fandrich from comment #18) > What git URL are you using? ssh://git@git.mageia.org/qa/dorsync
(In reply to Bruno Cornec from comment #22) > It's easy to source a conf file which would contain these info and not be > part of the package. > > if [ -e /etc/dorsync.conf ]; then > source /etc/dorsync.conf > fi Shouldn't dorsync.conf be located at ~/.config/Mageia/dorsync.conf ? I don't see the point to have it in /etc/.
(In reply to Frédéric "LpSolit" Buclin from comment #26) > Shouldn't dorsync.conf be located at ~/.config/Mageia/dorsync.conf ? I don't > see the point to have it in /etc/. Moreover, this would be consistent with mageiaSync.conf which is also in ~/.config/Mageia/.
Created attachment 15216 [details] patch, v3 In this patch, I bump version to 3.0 with the following improvements: - Store parameters in ~/.config/Mageia/dorsync.conf. When dorsync is executed for the first time, it creates this config file if not found. - If dorsync.skip is missing, dorsync asks the user if he really wants to download all ISOs or if he wants to select which ones to download, and stores the user choice in dorsync.skip for future reuse. - Update README.md
New Package v3.00 submitted to cauldron (pending git update)
I've submitted the patch in comment 28. Should I tag it as v3.0? FWIW, it's better to use $XDG_CONFIG_HOME instead of $HOME/.config/ if the former is available, since that allows the user to specify an alternate location. This patch (minimally tested) should be enough: diff --git a/dorsync b/dorsync index c98fb37..624b636 100644 --- a/dorsync +++ b/dorsync @@ -15,7 +15,8 @@ # progress indicator when dumping to USB. # ############################################ -conf_file="$HOME/.config/Mageia/dorsync.conf" +XDG_CONFIG_HOME="${XDG_CONFIG_HOME:-$HOME/.config}" +conf_file="$XDG_CONFIG_HOME/Mageia/dorsync.conf" generate_config_file () { cat << EOF > "$conf_file" I can commit that if you would like.
w.r.t. comment 25, I figured out the permission issue: commits to /qa/… repos are restricted to members of mga-qa and sysadmins. Are you on the QA team? Does it make sense for you to be added?
He's on the list of ISO testers. A late entry, added to the bottom. Was supposed to have received the email with password, etc.
(In reply to Thomas Andrews from comment #32) > He's on the list of ISO testers. A late entry, added to the bottom. Was > supposed to have received the email with password, etc. That doesn't automatically make him a member of the mga-qa ldap group ;-) https://people.mageia.org/g/mga-qa.html
(In reply to Marja Van Waes from comment #33) > https://people.mageia.org/g/mga-qa.html Shouldn't the top two entries be removed? Stormi and wilcal?
You're right, being inactive they probably should be. I'd leave the rest.
(In reply to Bruno Cornec from comment #29) > New Package v3.00 submitted to cauldron (pending git update) Thank you Bruno for the new RPM. :) (In reply to Bruno Cornec from comment #24) > I agree with you. I can make it easily a backported RPM or just an update. > This only make sense for QA anyway I think, so won't disturb others. Let me > know what's you preferred solution. I guess making it available as an update for Mageia 9 would make it easier to discover. No need to enable backports. (In reply to Dan Fandrich from comment #31) > w.r.t. comment 25, I figured out the permission issue: commits to /qa/… > repos are restricted to members of mga-qa and sysadmins. Are you on the QA > team? Does it make sense for you to be added? I'm not a member of the QA team. So I guess you will have to commit my patches in the future, if you agree to do it. :) (In reply to Thomas Andrews from comment #32) > He's on the list of ISO testers. A late entry, added to the bottom. Was > supposed to have received the email with password, etc. I got your email, yes. Thank you. Do we want to close this bug as FIXED, or do you first want to see this new RPM in Mageia 9 ?
I think we should wait for the Mageia 9 version. I believe that's where most of us would be using it until Cauldron stabilizes a bit more.
w.r.t. comment 35, I've removed stormi and wilcal from mga-qa and mga-qa-committers, but they're still members of several other groups. I've tagged the release as 3.0 and updated the .spec file to pull the sources based on the tag.
I was going to try it in one of my two shiny new Cauldron installs, but it won't install because of a bad signature. Then again, there are something like 525 updates available, and I'm told several of them have bad/no signatures, as well. I'm suspecting a mirror syncing issue. I'll try again tomorrow when things might settle down a bit.
(In reply to Dan Fandrich from comment #38) > w.r.t. comment 35, I've removed stormi and wilcal from mga-qa and > mga-qa-committers, but they're still members of several other groups. > > I've tagged the release as 3.0 and updated the .spec file to pull the > sources based on the tag. Have you submitted a new RPM or do you want me to do it ? Same question for mga9 ?
Dan updated the RPM for Cauldron, but not for Mageia 9: https://svnweb.mageia.org/packages?view=revision&revision=2302848
I have submitted a mga9 RPM for updates_testing. If you find it correct, you can move it to updates then.
Assignee: LpSolit => qa-bugs
Whiteboard: (none) => MGA9TOOSummary: dorsync doesn't run anymore because udisks is now obsolete => dorsync fixing, improving, and packing to rpm.
Great to have this packaged. I am testing it and is working on revising https://wiki.mageia.org/en/ISO_testing_rsync_tools#Dorsync to this packaged version. One minor bug so far: After downloading it asked if i want to dump to USB: it seems not to recognise big USB drives? Not: Corsair Voyager GTX 128GB nor JetFlash Transcend 256GB OK: Samsung Flash Drive FIT 32GB
If using qarepo in Mageia 9, the rpm to search for is mga-dorsync-3.0-3.1.mga9.noarch.rpm
(In reply to Morgan Leijström from comment #43) > After downloading it asked if i want to dump to USB: it seems not to > recognise big USB drives? > Not: Corsair Voyager GTX 128GB nor JetFlash Transcend 256GB > OK: Samsung Flash Drive FIT 32GB What is the output of this command ? lsblk -ndpro NAME,RM,TRAN,TYPE | grep "usb disk$" In my case, I get this: /dev/sda 0 usb disk (for my external hard drive) /dev/sdb 1 usb disk (for my USB key) Only my USB key is listed as removable (0 = not removable, 1 = removable), and only removable USB drives are available to copy an ISO on it. I guess this is to avoid to erase your external hard drive. When I updated dorsync to work with udisks2, I didn't remove this test. This test was already there to only select USB drives seen as removable.
CC: (none) => LpSolit
No problem here dumping to a Teamgroup 128GB drive. That drive had been formatted to NTSC before detecting. No idea if that makes a difference. But I have another issue. I set the conf to download to a different location than the one I had used with Mageiasync. The first time I ran it, I told it to sync/download just the Live Plasma and x86_64 CI isos. That worked OK. Then I went back later to try getting one of the isos I had skipped before. But I wasn't given the chance. Entering "R" sent me straight to re-syncing the isos already downloaded and not looking at the others.
(In reply to Thomas Andrews from comment #46) > Then I went back later to try getting one of the isos I had skipped before. > But I wasn't given the chance. Entering "R" sent me straight to re-syncing > the isos already downloaded and not looking at the others. That's because dorsync.skip has been created and now dorsync uses it to know what to update. You can manually edit dorsync.skip.
(In reply to Frédéric "LpSolit" Buclin from comment #47) > That's because dorsync.skip has been created and now dorsync uses it to know > what to update. You can manually edit dorsync.skip. I could easily update dorsync to ask if you want to edit the list, if you think that would be useful.
Oh, yes - I almost forgot. A minor niggle, probably something to address in the future: When I went to dump the iso, I had neglected to insert the usb drive. USB "drives" were detected, but they were from my generic card reader. 4 of them, sda through sdd, for different card types, all of them empty. There was no way to insert a stick at that point and use it, except to quit, and run the script again. When I did that, the sticks I had inserted (sde and sdf) were detected, as were the card readers. I think the script should ignore usb devices with a size of 0, and if none that are usable are found it should ask the user to insert one and try again, or quit. For what it's worth, Isodumper ignores my card readers if they are empty.
(In reply to Frédéric "LpSolit" Buclin from comment #45) > What is the output of this command ? [morgan@svarten ~]$ lsblk -ndpro NAME,RM,TRAN,TYPE | grep "usb disk$" /dev/sdc 0 usb disk (JetFlash Transcend 256GB) /dev/sdd 1 usb disk (Flash Drive FIT 32GB) [morgan@svarten ~]$ dorsync Do you want to Rsync (R), skip Rsync and just dump to usb (D) or quit (Q): d USB drives found: Device Size When Found Model 1) /dev/sdd 59.7Gb ons 17 dec 2025 16:05:26 CET Samsung Flash_Drive_FIT (In reply to Thomas Andrews from comment #46) > No problem here dumping to a Teamgroup 128GB drive. That drive had been > formatted to NTSC before detecting. No idea if that makes a difference. My 256MB is exfat (directly from package never used before) The 32 and 128 MB both had Mageia 9 Live systems on them. (In reply to Frédéric "LpSolit" Buclin from comment #48) > I could easily update dorsync to ask if you want to edit the list, if you > think that would be useful. Yes! Maybe add a new option to the first question: S=Select ISOs (rewrite dosrync.skip) (In reply to Thomas Andrews from comment #49) > When I went to dump the iso, I had neglected to insert the usb drive. USB > "drives" were detected, but they were from my generic card reader. 4 of > them, sda through sdd, for different card types, all of them empty. ... > For what it's worth, Isodumper ignores my card readers if they are empty. Likewise, Isodumper lists both my big USB flash that dorsync do not list, so maybe look at how Isodumper do, or ask its developer.
(In reply to Frédéric "LpSolit" Buclin from comment #48) > (In reply to Frédéric "LpSolit" Buclin from comment #47) > > That's because dorsync.skip has been created and now dorsync uses it to know > > what to update. You can manually edit dorsync.skip. > > I could easily update dorsync to ask if you want to edit the list, if you > think that would be useful. I dunno... I could go either way on that one. I haven't used dorsync before this bug came up, so I had to look up the wiki to learn where dorsync.skip is. But once I looked at it, I saw how easy it would be to edit, so it probably wouldn't be an issue except for new users. What do others think? Either way, I can see we'll have to remember to remind that dorsync.skip should be edited for each new release the same way we remind to make changes in the file/folder names.
I ran it again, this time inserting a card reader stick with a 128GB SD card, a 128GBusb stick, a 16GB usb stick, and just for giggles a 2TB external drive. I get this: $ dorsync Do you want to Rsync (R), skip Rsync and just dump to usb (D) or quit (Q): d USB drives found: Device Size When Found Model 1) /dev/sda 0Gb Wed Dec 17 10:52:24 AM EST 2025 Generic- SD_MMC 2) /dev/sdb 0Gb Wed Dec 17 10:52:24 AM EST 2025 Generic- Compact_Flash 3) /dev/sdc 0Gb Wed Dec 17 10:52:24 AM EST 2025 Generic- SM_xD-Picture 4) /dev/sdd 0Gb Wed Dec 17 10:52:24 AM EST 2025 Generic- MS_MS-Pro 5) /dev/sde 14.6Gb Wed Dec 17 10:52:24 AM EST 2025 General UDisk 6) /dev/sdf 116.0Gb Wed Dec 17 10:52:24 AM EST 2025 SMI USB_DISK 7) /dev/sdg 115.0Gb Wed Dec 17 10:52:24 AM EST 2025 Mass Storage_Device Please choose which USB to use or Q to quit and press <enter>: The 2TB drive was not detected by dorsync, though it was by the Plasma device notifier. Isodumper detects the 2TB drive, too.
OK, so I will update dorsync to: - ignore the "removable" bit and list *all* USB drives. - ignore drives for which the size is zero. - let the user change his selection even if dorsync.skip already exists - store in dorsync.skip the release for which the list has been created, and if it doesn't match the "release" variable in dorsync.conf, dorsync will ask the user to select which ISOs to download/sync again and invalidate the previous selection. @Dan: do you want to give me permissions to update the dorsync git repo, or do you prefer to commit my patches again as you did these last few days ?
Sounds good to me, except: > - store in dorsync.skip the release for which the list has been created, and if it doesn't match the "release" variable in dorsync.conf, dorsync will ask the user to select which ISOs to download/sync again and invalidate the previous selection. Users are supposed to edit dorsync.skip, dorsync.conf, and names of all the files, at a new release. (documented already) Unless we want to change that? IF we are going to change it maybe automate it all the way like mageiasync?
Minor bug to fix: When the path set by location= in dorsync.conf does not exist, and user selects to Dump without downloading, the script hangs. (exit by ctrl-C) It should exit with a message that that path is invalid. (It works OK if user selects to download, then that folder is created)
Usability: May I suggest a change in this interaction: "No dorsync.skip file found. Do you really want to download/update all ISOs? Press C to choose which ISOs to select, or any other key to continue with all ISOs " On the question "Do you really want to download/update all ISOs?" Ii is easy to answer N for no but that means yes... I suggest to change key to Y and text to: "No dorsync.skip file was found. Do you want to download/update all ISOs? Press Y to download all, or any other key to start selection."
> do you want to give me permissions to update the dorsync git repo, or do you prefer to commit my patches again as you did these last few days ? It makes sense that you get direct write access, but the way that's currently done is to add you to mga-qa. If that's not possible, I don't mind being an intermediary if it's not going to be a high volume of changes, but I ask that you upload or e-mail patches using 'git format-patch' to make the job easier.
(In reply to Morgan Leijström from comment #54) > > IF we are going to change it maybe automate it all the way like mageiasync? Mageiasync isn't automated "all the way" either. When releases are changed, like from alpha1 to alpha2, or alpha to beta, we still have to rename the files/folders we downloaded for the previous release unless we want to download the whole thing over again.
(In reply to Dan Fandrich from comment #57) > > do you want to give me permissions to update the dorsync git repo, or do you prefer to commit my patches again as you did these last few days ? > > It makes sense that you get direct write access, but the way that's > currently done is to add you to mga-qa. OK, let's do that.
Thomas, as QA team leader, do you approve of adding lpsolit to the mga-qa group?
OK with me.
lpsolit has now been added. You should now be able to commit directly to the dorsync repo.
MGA9-64 server Plasma Wayland on Compaq H000SB. No installation issues. Copied settings from mageia-sync on my desktop, with one exception: the edition is in mageia-sync mageia10-alpha1qaiso, while the release line in dorsync.conf has to be mageia10-alpha1. $ dorsync Do you want to Rsync (R), skip Rsync and just dump to usb (D) or quit (Q): R No dorsync.skip file found. Do you really want to download/update all ISOs? Press C to choose which ISOs to select, or any other key to continue with all ISOs: C For each of the following ISOs, press Y to download/update it, or any other key to skip it: Mageia-10-alpha1-Live-GNOME-x86_64 : n Mageia-10-alpha1-Live-Plasma-x86_64 : n Mageia-10-alpha1-Live-Xfce-i686 : y Mageia-10-alpha1-Live-Xfce-x86_64 : Y Mageia-10-alpha1-i686 : n Mageia-10-alpha1-x86_64 : n Your selection has been saved in dorsync.skip. Starting rsync.. receiving incremental file list ./ Mageia-10-alpha1-Live-Xfce-i686/ Mageia-10-alpha1-Live-Xfce-i686/DATE.txt 32 100% 31.25kB/s 0:00:00 (xfr#1, to-chk=19/23) Mageia-10-alpha1-Live-Xfce-i686/Mageia-10-alpha1-Live-Xfce-i686.iso 3,722,596,352 100% 4.61MB/s 0:12:50 (xfr#2, to-chk=18/23) Mageia-10-alpha1-Live-Xfce-i686/Mageia-10-alpha1-Live-Xfce-i686.iso.md5 70 100% 0.10kB/s 0:00:00 (xfr#3, to-chk=17/23) Mageia-10-alpha1-Live-Xfce-i686/Mageia-10-alpha1-Live-Xfce-i686.iso.sha3 166 100% 0.23kB/s 0:00:00 (xfr#4, to-chk=16/23) Mageia-10-alpha1-Live-Xfce-i686/Mageia-10-alpha1-Live-Xfce-i686.iso.sha512 166 100% 0.23kB/s 0:00:00 (xfr#5, to-chk=15/23) Mageia-10-alpha1-Live-Xfce-i686/Mageia-10-alpha1-Live-Xfce-i686.langs 27 100% 0.04kB/s 0:00:00 (xfr#6, to-chk=14/23) Mageia-10-alpha1-Live-Xfce-i686/Mageia-10-alpha1-Live-Xfce-i686.lst 76,770 100% 106.64kB/s 0:00:00 (xfr#7, to-chk=13/23) Mageia-10-alpha1-Live-Xfce-i686/Mageia-10-alpha1-Live-Xfce-i686.lst.full 54,956 100% 75.59kB/s 0:00:00 (xfr#8, to-chk=12/23) Mageia-10-alpha1-Live-Xfce-i686/Mageia-10-alpha1-Live-Xfce-i686.lst.leaves 3,728 100% 5.12kB/s 0:00:00 (xfr#9, to-chk=11/23) Mageia-10-alpha1-Live-Xfce-i686/Mageia-10-alpha1-Live-Xfce-i686.lst.names 36,964 100% 50.42kB/s 0:00:00 (xfr#10, to-chk=10/23) Mageia-10-alpha1-Live-Xfce-x86_64/ Mageia-10-alpha1-Live-Xfce-x86_64/DATE.txt 32 100% 0.04kB/s 0:00:00 (xfr#11, to-chk=9/23) Mageia-10-alpha1-Live-Xfce-x86_64/Mageia-10-alpha1-Live-Xfce-x86_64.iso 4,194,183,168 100% 4.85MB/s 0:13:44 (xfr#12, to-chk=8/23) Mageia-10-alpha1-Live-Xfce-x86_64/Mageia-10-alpha1-Live-Xfce-x86_64.iso.md5 72 100% 0.08kB/s 0:00:00 (xfr#13, to-chk=7/23) Mageia-10-alpha1-Live-Xfce-x86_64/Mageia-10-alpha1-Live-Xfce-x86_64.iso.sha3 168 100% 0.18kB/s 0:00:00 (xfr#14, to-chk=6/23) Mageia-10-alpha1-Live-Xfce-x86_64/Mageia-10-alpha1-Live-Xfce-x86_64.iso.sha512 168 100% 0.18kB/s 0:00:00 (xfr#15, to-chk=5/23) Mageia-10-alpha1-Live-Xfce-x86_64/Mageia-10-alpha1-Live-Xfce-x86_64.langs 27 100% 0.03kB/s 0:00:00 (xfr#16, to-chk=4/23) Mageia-10-alpha1-Live-Xfce-x86_64/Mageia-10-alpha1-Live-Xfce-x86_64.lst 78,995 100% 82.33kB/s 0:00:00 (xfr#17, to-chk=3/23) Mageia-10-alpha1-Live-Xfce-x86_64/Mageia-10-alpha1-Live-Xfce-x86_64.lst.full 57,064 100% 58.66kB/s 0:00:00 (xfr#18, to-chk=2/23) Mageia-10-alpha1-Live-Xfce-x86_64/Mageia-10-alpha1-Live-Xfce-x86_64.lst.leaves 3,706 100% 3.81kB/s 0:00:00 (xfr#19, to-chk=1/23) Mageia-10-alpha1-Live-Xfce-x86_64/Mageia-10-alpha1-Live-Xfce-x86_64.lst.names 39,035 100% 39.87kB/s 0:00:00 (xfr#20, to-chk=0/23) sent 638 bytes received 7,919,066,034 bytes 4,966,488.98 bytes/sec total size is 7,917,131,666 speedup is 1.00 Completed rsync 7.4G Total 3.5G Mageia-10-alpha1-Live-Xfce-i686 4.0G Mageia-10-alpha1-Live-Xfce-x86_64 Starting checks, please ensure the dates are correct PATH: Mageia-10-alpha1-Live-Xfce-i686 ISO: Mageia-10-alpha1-Live-Xfce-i686.iso DATE: Mon Dec 8 03:57:28 PM CET 2025 MD5: OK SHA3: OK SHA512: OK PATH: Mageia-10-alpha1-Live-Xfce-x86_64 ISO: Mageia-10-alpha1-Live-Xfce-x86_64.iso DATE: Mon Dec 8 05:06:54 PM CET 2025 MD5: OK SHA3: OK SHA512: OK ------------------------------------ All tests passed OK. Yippee! Please check the dates are correct. ------------------------------------ Do you want to dump one onto USB? [y/n]n Looks OK to me.
Whiteboard: MGA9TOO => MGA9TOO, MGA9-64-OKCC: (none) => herman.viaene
Sorry, this should already have been set to developer in comment 53 onwards, assigning now. Removing the OK as we should test the upcoming version. Please, when new version is built, assign back to QA!
Whiteboard: MGA9TOO, MGA9-64-OK => MGA9TOOAssignee: qa-bugs => LpSolit
(In reply to Dan Fandrich from comment #62) > lpsolit has now been added. You should now be able to commit directly to the > dorsync repo. This still doesn't work: remote: FATAL: W refs/heads/master qa/dorsync lpsolit DENIED by fallthru
(In reply to Frédéric "LpSolit" Buclin from comment #65) > This still doesn't work: > > remote: FATAL: W refs/heads/master qa/dorsync lpsolit DENIED by fallthru @Dan: do you have a moment to debug what's wrong here?
Adding the flag: affects_mga9 + to all bugs with MGA9TOO on the whiteboard, without removing MGA9TOO (for now).
Flags: (none) => affects_mga9+
(In reply to Frédéric "LpSolit" Buclin from comment #66) > @Dan: do you have a moment to debug what's wrong here? The gitolite configuration file containing the expanded list of group members hasn't been updated since June, so it doesn't see you as a member. I'll try to figure out why that is.
The git permissions issue was due a bad precondition that meant group member changes were only reflected whenever somebody happened to change an SSH key. I've updated it manually so you should have access to dorsync now and I will fix it properly tomorrow.
commit b7527f083a630525b8df210386a47f9896f72e4c Author: Dan Fandrich <danf@...> Date: Wed Jan 7 23:41:29 2026 -0800 Separate running the SSH keys script from the mgagit script (mga#34826) The mgagit script was previously run after the SSH keys script, but only if an SSH key was updated. That meant that any group changes were not reflected until after someone changed an SSH key. Decouple the running of the two scripts since they are not (completely) dependent on each other. --- Commit Link: https://gitweb.mageia.org/infrastructure/puppet/commit/?id=b7527f083a630525b8df210386a47f9896f72e4c
commit 6a019527c73b72a92a1309ffd7ad566806c62806 Author: Frédéric Buclin <LpSolit@...> Date: Fri Dec 26 20:11:15 2025 +0100 Improve the detection of USB drives, and let the user edit dorsync.skip (mga#34826) --- Commit Link: https://gitweb.mageia.org/qa/dorsync/commit/?id=6a019527c73b72a92a1309ffd7ad566806c62806
(In reply to Bruno Cornec from comment #42) > I have submitted a mga9 RPM for updates_testing. If you find it correct, you > can move it to updates then. Bruno, can you update the RPM with this last commit, please ?
Assignee: LpSolit => bruno
(In reply to Dan Fandrich from comment #69) > I've updated it manually so you should have access to dorsync now and I will > fix it properly tomorrow. It works now. Thank you!
> It works now. Thank you! Excellent! You'll need to bump the version and push a new dorsync tag before making a new RPM. Remember to update the version embedded in the script to match.
(In reply to Dan Fandrich from comment #74) > You'll need to bump the version and push a new dorsync tag before making a > new RPM. Remember to update the version embedded in the script to match. IMO, we should drop the hardcoded version in the script and only use git tags. What do you think?
It's nice to be able to tell what version you have on disk, but it's probably worse if it becomes out of sync with reality. And as long as it's a manual process, it's guaranteed to fail at some point. So, I wouldn't be upset if it were removed.
(In reply to Frédéric "LpSolit" Buclin from comment #72) > (In reply to Bruno Cornec from comment #42) > > I have submitted a mga9 RPM for updates_testing. If you find it correct, you > > can move it to updates then. > > Bruno, can you update the RPM with this last commit, please ? Yes, will do ASA the version and tags are correct.
(In reply to Dan Fandrich from comment #76) > It's nice to be able to tell what version you have on disk, but it's > probably worse if it becomes out of sync with reality. And as long as it's a > manual process, it's guaranteed to fail at some point. So, I wouldn't be > upset if it were removed. What about using a commit hook in all Mageia git infra repo, with inspiration from https://dev.to/elpalomo/automate-semantic-versioning-and-tagging-with-a-git-hook-577b That would ease a lot the work on our side once it works.
Done! I removed the hardcoded version and tagged the latest commit.
(In reply to Bruno Cornec from comment #78) > What about using a commit hook in all Mageia git infra repo, with > inspiration from > https://dev.to/elpalomo/automate-semantic-versioning-and-tagging-with-a-git-hook-577b That would work, but only for users who have set up the hook, a manual process leading to another point of failure. I'm not too worried about dorsync since it's likely to have very few contributors and I suspect will be pretty stable again once the current churn is over. If someone put the effort in for a general solution we could install it server-wide on all our git repos then all Mageians could learn to use it and expect it to be everywhere.
(In reply to Frédéric "LpSolit" Buclin from comment #79) > Done! I removed the hardcoded version and tagged the latest commit. Package v3.1 pushed to cauldron.
(In reply to Bruno Cornec from comment #81) > Package v3.1 pushed to cauldron. Thanks! Could you update the RPM in Mageia 9 too, please? :)
Just submitted to core/updates_testing
Assignee: bruno => qa-bugs
[S]RPM: mga-dorsync-3.1-1.mga9
Status comment: (none) => Package in comment 84Version: Cauldron => 9Whiteboard: MGA9TOO => (none)
Good Comment regarding file checking: Should it really check all ISO:s even when I choosed to only update one of them (all was downloaded previously). Also, maybe there could be an option to not check all three checksums per ISO. It is good that *someone* test that *all* checksums files are good though, but takes time for every user...
# dorsync /usr/bin/dorsync: line 21: /root/.config/Mageia/dorsync.conf: No such file or directory Missing file /root/.config/Mageia/dorsync.conf has been created. Please edit this file and then rerun dorsync. There is no such folder under /root/.config/
MGA9-64 server Plasma Wayland on Compaq H000SB. No installation issues. Used settings from previous test above. $ dorsync Do you want to Rsync (R), skip Rsync and just dump to usb (D) or quit (Q): R dorsync.skip file found: Mageia-10-alpha1-Live-GNOME-x86_64 SKIPPED Mageia-10-alpha1-Live-Plasma-x86_64 SKIPPED Mageia-10-alpha1-Live-Xfce-i686 SELECTED Mageia-10-alpha1-Live-Xfce-x86_64 SELECTED Mageia-10-alpha1-i686 SKIPPED Mageia-10-alpha1-x86_64 SKIPPED Do you want to continue with this selection? Press Y to continue, or any other key to modify this list: Y Starting rsync.. receiving incremental file list ./ Then load of download lines and at the end: sent 1,010,296 bytes received 2,901,228,100 bytes 4,000,328.60 bytes/sec total size is 8,025,900,298 speedup is 2.77 Completed rsync 7.5G Total 3.6G Mageia-10-alpha1-Live-Xfce-i686 4.0G Mageia-10-alpha1-Live-Xfce-x86_64 Starting checks, please ensure the dates are correct PATH: Mageia-10-alpha1-Live-Xfce-i686 ISO: Mageia-10-alpha1-Live-Xfce-i686.iso DATE: Sat Dec 20 02:18:13 PM CET 2025 MD5: OK SHA3: OK SHA512: OK PATH: Mageia-10-alpha1-Live-Xfce-x86_64 ISO: Mageia-10-alpha1-Live-Xfce-x86_64.iso DATE: Sat Dec 20 03:23:01 PM CET 2025 MD5: OK SHA3: OK SHA512: OK ------------------------------------ All tests passed OK. Yippee! Please check the dates are correct. ------------------------------------ Do you want to dump one onto USB? [y/n]n Looks good to me, but I didn't test the dumping to USB. I use a Ventoy stick.
commit 0eb150ba760b0ab9c286e2acd5105a762b90af1f Author: Frédéric Buclin <LpSolit@...> Date: Mon Jan 12 15:24:47 2026 +0100 Make sure the path exists before creating dorsync.conf (mga#34826) --- Commit Link: https://gitweb.mageia.org/qa/dorsync/commit/?id=0eb150ba760b0ab9c286e2acd5105a762b90af1f
(In reply to Herman Viaene from comment #86) > # dorsync > /usr/bin/dorsync: line 21: /root/.config/Mageia/dorsync.conf: No such file > or directory > Missing file /root/.config/Mageia/dorsync.conf has been created. > Please edit this file and then rerun dorsync. > There is no such folder under /root/.config/ Thanks for catching that. This is fixed in comment 88. (In reply to Morgan Leijström from comment #85) > Comment regarding file checking: > Should it really check all ISO:s even when I choosed to only update one of > them (all was downloaded previously). I will try to improve this.
I suddenly see new .torrent files which were not present before. Is that expected?
The .torrent files in root folder is OK. The are recently created. I also see the three new .gpg files in each subfolder for the isos, they were created a couple days ago, after it was agreed to release. All as it should be. We should probably manually remove the .torrent and .gpg files before syncing next ISOs round (same time as when we rename the rest).
Do we want dorsync to download .torrent files too? Or should it ignore them?
We do not need them for testing, but it is a convenient way to get them today for us who started seeding. Otherways we could get hem official from mirrors, but maybe hours later, but that probably do not make much difference... / For seeding, I copied the files to my archive files, then started torrenting from there so dorsync can update the files separately... /
(In reply to Frédéric "LpSolit" Buclin from comment #92) > Do we want dorsync to download .torrent files too? Or should it ignore them? I think they should be ignored. Remember what the purpose of dorsync is, a tool to help QA iso testers to sync/download test isos. Torrents have nothing to do with that. They are for the public, after the testing is done and the isos are released.
(In reply to Thomas Andrews from comment #94) > > Do we want dorsync to download .torrent files too? Or should it ignore them? > > I think they should be ignored. OK, perfect. I agree to exclude them too. I asked because the original code didn't exclude them, so I wondered if that was on purpose.
You'd have to ask MrsB. that one.
Source RPM: (none) => dorsync
Source RPM: dorsync => mga-dorsync
When last we left this for mga9, I believe there was a new revision in the works. I see that a new mga-dorsync was recently uploaded to Cauldron. Are there plans to do a mga9 version, as well? In short, it's been almost three months. Where is this going?
(In reply to Thomas Andrews from comment #97) > When last we left this for mga9, I believe there was a new revision in the > works. I see that a new mga-dorsync was recently uploaded to Cauldron. Are > there plans to do a mga9 version, as well? > > In short, it's been almost three months. Where is this going? Now that torrent files have been moved into their own directory, this fixes comment 94 and this is no longer an issue. This leaves us with comment 85, but it can be implemented in a future update. This is not a regression.
OK then, that sounds like we've gone as far as we are going to go with the Mageia 9 version and with the RC looming soon it should be validated ASAP. Many thanks, Frederic. Further development can take place in the Mageia 10 version, with plenty of time available before the next set of test isos, be they Cauldron (Mageia 11) or a potential Mageia 10.1. Giving this an OK, and validating once more. Once again I don't know where to go from here. While this isn't exactly an update, I wouldn't call it a backport, either.
Flags: (none) => test_passed_mga9_64+Whiteboard: (none) => MGA9-64-OKKeywords: (none) => validated_update
Advisory mga-dorsync is QA tool to sync Mageia ISO images and transfer them to a USB stick. Now after some updates in the code and bugs fixed we are providing a official package for this tool.
Keywords: (none) => advisory
The advisory says ver. 3.1 but ver. 3.2 is the current one in git. Which one do you want to push?
(In reply to Dan Fandrich from comment #101) > The advisory says ver. 3.1 but ver. 3.2 is the current one in git. Which one > do you want to push? As long as I can see for mageia 9, the version is 3.1
Version 3.2 is required on Mageia 9. It includes the commit listed in comment 88.
(In reply to Frédéric "LpSolit" Buclin from comment #103) > Version 3.2 is required on Mageia 9. It includes the commit listed in > comment 88. No body build it https://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/9/x86_64/media/core/updates_testing/mga-dorsync-3.1-1.mga9.noarch.rpm
mga-dorsync-3.2-1.mga9 now available on 9/Core/Updates_testing repo!
CC: (none) => geiger.david68210
Keywords: validated_update => (none)Whiteboard: MGA9-64-OK => (none)Flags: test_passed_mga9_64+ => test_passed_mga9_64-
Removing validation, for the moment. I had not tested version 3.2-1 because I didn't know it existed. But I just did, and I have a problem with it. I was just going to download a couple of the isos, so I had it go through the list for selection. The list showed each version twice, which I found odd, but I selected only the two I wanted, anyway, only the first of each. The sync was almost immediate, which was impossible, but I was told the checksums were OK. But when I looked at the results, I found that I had downloaded the torrents rather than the isos themselves. There had been nothing that I noticed when I was selecting the files to download that indicated that one or more of them were torrent files. It's most confusing this way, as far as I am concerned. If you want the torrent files, or anything else other than the files/folders under test (I don't, but am only one user), OK, but they need to be identified as such.
Oops. I deleted the skip file, and ran it again. This time I saw the files WERE identified as torrent files. I had merely missed it the first time. Continuing with my second test...
commit b068584799bc99485778b7cefc0b5e67167ea8a2 Author: Frédéric Buclin <LpSolit@...> Date: Fri Apr 17 16:19:38 2026 +0200 Skip torrent files (mga#34826) --- Commit Link: https://gitweb.mageia.org/qa/dorsync/commit/?id=b068584799bc99485778b7cefc0b5e67167ea8a2
I had this patch applied locally for a long time. Could you test it, please ?
Everything worked out OK. I synced a couple of isos, they checked out, and had the Live Plasma dumped to a new usb stick. Then I booted into Live mode, so the stick is OK. I was goig to restore the validation, but now I see my unwarranted grousing has born fruit in the form of a new commit. Putting the validation on hold again...
Mid-air collision! (In reply to Frédéric "LpSolit" Buclin from comment #109) > I had this patch applied locally for a long time. Could you test it, please ? Will do.
(In reply to Thomas Andrews from comment #111) > Mid-air collision! > > (In reply to Frédéric "LpSolit" Buclin from comment #109) > > I had this patch applied locally for a long time. Could you test it, please ? > > Will do. Waiting for it to get to my mirror...
(In reply to Mageia Robot from comment #108) > commit b068584799bc99485778b7cefc0b5e67167ea8a2 > Author: Frédéric Buclin <LpSolit@...> > Date: Fri Apr 17 16:19:38 2026 +0200 > > Skip torrent files (mga#34826) > --- > Commit Link: > > https://gitweb.mageia.org/qa/dorsync/commit/ > ?id=b068584799bc99485778b7cefc0b5e67167ea8a2 I think need tag as version to release new package?
mga-dorsync-3.3-1.mga9 now available on 9/Core/Updates_testing repo!
(In reply to David GEIGER from comment #114) > mga-dorsync-3.3-1.mga9 now available on 9/Core/Updates_testing repo! Will be updated in cauldron too?
already done!
mga9-64 test OK updating all beta1 to rc1 ISOs in one go; no skip.list. Per https://wiki.mageia.org/en/ISO_testing_rsync_tools#Dorsync
Tested on the beta1 isos, and it now ignores the torrent files. One minor issue, mentioned on the QA ML by Morgan (I think...), but not one severe enough to hold back the mga9 version: After syncing, the script ignores the skip list and performs the checksum check on all the Mageia isos it finds in the destination directory, not just the ones it just synced. I suppose it doesn't hurt, but it shouldn't be necessary and does take what seems like quite a bit of time if all test isos have been downloaded. Something to consider for a mga10 update. I'd say this is ready to validate.
Exercized dorsync with good result. $ dorsync -h Do you want to Rsync (R), skip Rsync and just dump to usb (D) or quit (Q): q [tester9@mach3 ~]$ dorsync Do you want to Rsync (R), skip Rsync and just dump to usb (D) or quit (Q): r No dorsync.skip file found. Do you really want to download/update all ISOs? Press Y to continue with all ISOs, or any other key to choose which ISOs to select: n For each of the following ISOs, press Y to download/update it, or any other key to skip it: Mageia-10-rc1-Live-GNOME-x86_64 : n Mageia-10-rc1-Live-Plasma-x86_64 : y Mageia-10-rc1-Live-Xfce-i686 : n Mageia-10-rc1-Live-Xfce-x86_64 : n Mageia-10-rc1-i686 : n Mageia-10-rc1-x86_64 : Y Your selection has been saved in dorsync.skip. Starting rsync.. receiving incremental file list etc... ending with Completed rsync 11G Total 5.1G Mageia-10-rc1-Live-Plasma-x86_64 5.6G Mageia-10-rc1-x86_64 Starting checks, please ensure the dates are correct PATH: Mageia-10-rc1-x86_64 ISO: Mageia-10-rc1-x86_64.iso DATE: Sun Apr 19 02:22:51 PM CEST 2026 MD5: OK SHA3: OK SHA512: OK PATH: Mageia-10-rc1-Live-Plasma-x86_64 ISO: Mageia-10-rc1-Live-Plasma-x86_64.iso DATE: Sun Apr 19 01:48:43 PM CEST 2026 MD5: OK SHA3: OK SHA512: OK ------------------------------------ All tests passed OK. Yippee! Please check the dates are correct. ------------------------------------ Do you want to dump one onto USB? [y/n]n Looks good to me.
Advisory updated
Thomas, per your comment 118, it seems to work fine now, right ?
Flags: test_passed_mga9_64- => test_passed_mga9_64?(andrewsfarm)
Yes. Validating again. Morgan, once this has been pushed, if I don't get to it first please edit the wiki page to let users know it's in the repos.
Keywords: (none) => validated_updateWhiteboard: (none) => MGA9-64-OKFlags: test_passed_mga9_64?(andrewsfarm) => test_passed_mga9_64+
As per comment #114, I've updated the advisory to ver. 3.3.
(In reply to Dan Fandrich from comment #123) > As per comment #114, I've updated the advisory to ver. 3.3. LOL I not svn ci :S
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGAA-2026-0029.html
Resolution: (none) => FIXEDStatus: ASSIGNED => RESOLVED
(In reply to Thomas Andrews from comment #122) > Morgan, once this has been pushed, if I don't get to it first please edit > the wiki page to let users know it's in the repos. done.
Thank you. As I expected, the email that it had been pushed didn't hit my inbox until after midnight, while I was getting some much-needed beauty sleep.
Hmmm, tried to run it, with dorsync.conf in .config/Mageia edited to have: location="/mnt/crypt1/tony/cauldron" # Full path to the local folder where ISOs will be downloaded. release="mageia10-rc1" # Name of the directory on the rsync server. user="isoqa" # Username used by rsync. plus what I believe to be the appropriate password still, but it crashed. (also tried it with "release="mageia10-rc", same problem. $ dorsync Do you want to Rsync (R), skip Rsync and just dump to usb (D) or quit (Q): r No dorsync.skip file found. Do you really want to download/update all ISOs? Press Y to continue with all ISOs, or any other key to choose which ISOs to select: y Starting rsync.. @ERROR: auth failed on module isos rsync error: error starting client-server protocol (code 5) at main.c(1859) [Receiver=3.2.7] Rsync failed. Exiting. My config error? script error? if I'm putting the wrong data in, perhaps someone can privately email me correct password etc. Tony tablackwell@bigpond.com
All fixed. Password was the problem. Martin kindly updated me privately. Script runs fine now. Thankyou all.