Re: [Tails-dev] Help required: test suite vs. Tor bootstrapping on buster
intrigeri (2020-07-31): > I've looked at the logs you've sent me and unfortunately, this did not > help me understand what's happening. > > Sharing the *.journal and Tor log artifacts could give us more clues, > perhaps. Full directory for that run shared in the tarball available at: https://cloud.debamax.com/s/LaMQZ4PpxrHD9cJ > > https://gitlab.tails.boum.org/tails/tails/-/issues/17689 > > I have a potential lead and asked for more info there. Replied there. Cheers, -- Cyril 'kibi' Brulebois (c...@riseup.net) signature.asc Description: PGP signature ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Fixing Torrent files for 4.9
emma peel (2020-07-29): > I am not a master (no logs, no masters!) but: > > In my experience you can > > - download a torrent to a location > - stop it (without deleting the contents) > - start another torrent with the same file names This seems to work just fine with rtorrent indeed. My download tests (checking download starts) were stuck at 99% and suddenly finished when I replaced the Torrent files (without touching the temporary files from the old Torrent files). > I have tried adding the files to my torrent download folder with scp, > but when rehashing i could not convince the app they were the correct > file. Right, the initial Torrent files were referencing the wrong files (due to the signing issues I encountered), so feeding your client the right files wouldn't be enough to convince it you had the buggy files it was expecting… Following a green light via tails-rm@ (thanks), I've regenerated the Torrent files without resigning anything, replaced the Torrent files on our bittorrent server, and updated them on the website as well: https://tails.boum.org/torrents/files/ https://gitlab.tails.boum.org/tails/tails/-/commit/fef8cd8a4a9f390e20d4e3039ea22c4d6b3c0a5d Hopefully that's it for 4.9… Maybe we should make sure downloading over bittorrent finishes, and not only starts? (In that case, please file a ticket against the release process doc.) Nowadays I'd imagine it would be easier to do so than during the many releases where Torrent seeding was broken… Sorry for the hassle. Cheers, -- Cyril 'kibi' Brulebois (c...@riseup.net) signature.asc Description: PGP signature ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Fixing Torrent files for 4.9
Hi, So, I had some troubles generating + signing Torrent files (for some reasons, my GPG hardware token refused my user PIN several times, and I had to iterate/restart; see below for why those topics are intertwined), and it seems the generated Torrent files are starting to download just fine (as checked per release process), but don't let users reach full completion; some issues with asc vs. sig files, which wouldn't be entirely unrelated to the issues I encountered while releasing. Would it seem OK for me to try and re-generate Torrent files (making extra sure they contain the same kind of files as previous Torrent files had, and not the apparently broken set of files they currently do)? I'm not sure which part(s) might need some signing, but anything related to signatures is flashing red alarms here, since it could invalidate some reproducibility properties (our release process highlights that once a given point is reached, the GPG hardware token must be stowed away and never touched back). And I'm also not sure whether publishing the new Torrent files with similar names but different contents could be an issue (I'm no Torrent/DHT master). Please let me know whether/how I should try and get stuff fixed. Relevant part of the release process: https://tails.boum.org/contribute/release_process/#index16h1 Of the blue, I would expect uncoupling signing (already done, already used to move data around on various servers, so likely OK), and Torrent generation might do the trick, and generating new Torrent files without resigning anything might work. What do you think? Cheers, -- Cyril 'kibi' Brulebois (c...@riseup.net) signature.asc Description: PGP signature ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Tails 4.10 release, testing schedule
Hi, We haven't decided otherwise at the moment, so by default I'll be the release manager for Tails 4.10, scheduled to be released on 2020-08-25 (Mozilla seems to still agree :)). This will be a bugfix release. Manual testers, please report whether you are available for testing on 2020-08-25 (and possibly the day before) to me privately. Cheers, -- Cyril 'kibi' Brulebois (c...@riseup.net) signature.asc Description: PGP signature ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Requesting help: mass-unsubscribe from notifications
intrigeri (2020-07-28): > I was confused and unclear. I've sent you the list of issues for which > you're in the list of "participants", which I believe is a superset of > the list of issues to which you've been subscribed automatically: even > if you've opted out of notifications for such an issue earlier, you're > still in the list of participants, so the issue appears on the list > I've sent you. I suppose this explains the discrepancy you've noted. Oh, that makes total sense, ta. > > Also, what happens if I make sure notifications are off for each item on > > that list (which is my plan in the few next minutes)? Do they get turned > > on again if I get mentioned? > > I'm pretty sure that regardless of your current subscription status on > a given issue, you'll get a notification if you're mentioned (that's > what @mention is for, after all). Good, that was my main worry… > But: > > - I don't know if this re-enables notifications on that issue. > > - I don't know what happens if you participate again in that issue, >i.e. whether GitLab will re-enable notifications. I can see good >reasons for both potential behaviors. … and now that GitLab traffic should be more reasonable, I should be able to spend some time checking the notification status next time I get some poke via GitLab. Thanks for your help, much appreciated. Cheers, -- Cyril 'kibi' Brulebois (c...@riseup.net) signature.asc Description: PGP signature ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Help required: test suite vs. Tor bootstrapping on buster
Cyril Brulebois (2020-07-28): > This is hindering: > - my general ability to test Tails; > - my specific ability to check locally what failed in Jenkins, namely >all of features/additional_software_packages.feature > > Looking at XMPP logs (I didn't check what's happening now) from May, and > skipping some explanations: > | [2020-05-05 22:59:49] kibi: I'm not seeing any HTTPS packets with the test > suite > | [2020-05-05 22:59:57] kibi: Hard to get the time if you don't ask for it, > right? > | [2020-05-05 23:29:07] kibi: not an issue when running the VM separately (on > the same machine), not an issue when running the test suite on stretch > (different machine), not an issue on baremetal. > | [2020-05-05 23:29:22] kibi: I think a bug or undocumented requirement when > running the test suite on buster. > > Any insight appreciated… > > Tests failing on Jenkins are a pain enough on their own, we don't need > additional problems for developers or release managers on their local > systems… At the time I wrote this call for help, it felt strange not to have filed a bug report at the time… I actually did, this is: https://gitlab.tails.boum.org/tails/tails/-/issues/17689 Cheers, -- Cyril 'kibi' Brulebois (c...@riseup.net) signature.asc Description: PGP signature ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Requesting help: mass-unsubscribe from notifications
intrigeri (2020-07-28): > Cyril Brulebois (2020-07-27): > > Having being responsible for a number of releases lately, I've been > > automatically “subscribed” to any tickets I ever touched, even if only > > to push back the target version (Redmine) / milestone (GitLab) to the > > next release. > > It sounds like a bug in the algorithm our migration scripts have used > to identify issues for which you should be subscribed to :/ Okay… > > but that doesn't seem to be sufficient, as I'm still getting > > notifications for issues I didn't participate (besides adjusting > > target version/milestone)… > > > > The signal-to-noise ratio of my gitlab folder is therefore very very > > very low… :( > > > > Help welcome! > > After sending this message, I'm going to send you links to the 143 > issues you're currently subscribed to, generated by the attached script. Then I'm not sure I understand what “being currently subscribed to” means. For example, looking at the first ones, the notification slider was “off” already? https://gitlab.tails.boum.org/tails/accounting/-/issues/16961 https://gitlab.tails.boum.org/tails/accounting/-/issues/16831 Also, what happens if I make sure notifications are off for each item on that list (which is my plan in the few next minutes)? Do they get turned on again if I get mentioned? Or am I going to miss GitLab traffic? Cheers, -- Cyril 'kibi' Brulebois (c...@riseup.net) signature.asc Description: PGP signature ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Help required: test suite vs. Tor bootstrapping on buster
intrigeri (2020-07-28):
> That sounds annoying indeed! I'm happy to try to help. To do so, I'll
> need the debug log (saved as debug.log by the test suite).
Great, thanks.
In the meanwhile, I had cleaned up all temporary directories, rebooted
the machine, etc. to be extra sure. I've just started the test suite
again, this way:
kibi@hamburg:~/work/clients/tails/release-checkout.git$ sudo TMPDIR=~/TT \
./run_test_suite --capture --view\
--iso ../isos.git/tails-amd64-4.9/tails-amd64-4.9.iso\
--old-iso ../isos.git/tails-amd64-4.8/tails-amd64-4.8.iso\
-- features/additional_software_packages.feature
It has now reached the first failure, so hopefully you'll have something
to fish in there?
Cheers,
--
Cyril 'kibi' Brulebois (c...@riseup.net)
[34m00:00:06.554304781: chutney: stop[0m
[34m00:00:07.686086929: chutney: configure[0m
[34m00:00:16.039273609: chutney: start[0m
[34m00:00:18.424530565: chutney: wait_for_bootstrap[0m
[34m00:01:34.655573000: chutney: status[0m
[36m@product[0m [36m@check_tor_leaks[0m
Feature: Additional software
As a Tails user
I may want to install softwares not shipped in Tails
And have them installed automatically when I enable persistence in the Greeter
[37mCheckpoint: I have started Tails from DVD without network and stopped
at Tails Greeter's login screen[0m
[32m Given the network is unplugged[0m
[34m00:01:35.644254329: try_for: attempt 1 (0.01s elapsed of 20s)...[0m
[34m00:01:35.647249747: try_for: failed by code block returning failure[0m
[34m00:01:35.747555489: try_for: attempt 2 (0.11s elapsed of 20s)...[0m
[34m00:01:35.750508870: try_for: failed by code block returning failure[0m
[34m00:01:35.850799879: try_for: attempt 3 (0.21s elapsed of 20s)...[0m
[34m00:01:35.853773427: try_for: failed by code block returning failure[0m
[34m00:01:35.954032525: try_for: attempt 4 (0.32s elapsed of 20s)...[0m
[34m00:01:35.957641830: try_for: failed by code block returning failure[0m
[34m00:01:36.057920096: try_for: attempt 5 (0.42s elapsed of 20s)...[0m
[34m00:01:36.061504055: try_for: failed by code block returning failure[0m
[34m00:01:36.161769627: try_for: attempt 6 (0.52s elapsed of 20s)...[0m
[34m00:01:36.166938054: try_for: success![0m
[32m And I start the computer[0m
[34m00:01:36.168154870: try_for: attempt 1 (0.01s elapsed of 180s)...[0m
[34m00:01:36.183443054: Screen: waiting for TailsBootMenuSyslinux.png[0m
[34m00:01:38.314739427: Screen: found TailsBootMenuSyslinux.png at (262,
416)[0m
[34m00:01:38.325674212: Keyboard: pressing: Tab[0m
[34m00:01:38.387505105: Screen: waiting for TailsBootMenuKernelCmdline.png[0m
[34m00:01:39.12791: Screen: found TailsBootMenuKernelCmdline.png at (581,
638)[0m
[34m00:01:39.128960378: try_for: success![0m
[34m00:01:39.129185069: Keyboard: typing: autotest_never_use_this_option
blacklist=psmouse [0m
[34m00:01:42.216322438: Keyboard: pressing: Return[0m
[34m00:01:42.278179485: Screen: waiting for TailsGreeter.png[0m
[34m00:02:14.394211590: Screen: found TailsGreeter.png at (511, 214)[0m
[34m00:02:14.394615690: try_for: attempt 1 (0.01s elapsed of 90s)...[0m
[34m00:02:14.394856868: Remote shell: calling as root: echo 'hello?'[0m
[34m00:02:14.585313222: Remote shell: call returned: [0, "hello?\n", ""][0m
[34m00:02:14.585531578: try_for: success![0m
[34m00:02:14.592722999: Mouse: clicking left button at (1023, 384)[0m
[34m00:02:15.699243584: Remote shell: calling as root: service tor status[0m
[34m00:02:15.839768258: Remote shell: call returned: [3, "● tor.service -
Anonymizing overlay network for TCP (multi-instance-master)\n Loaded: loaded
(/lib/systemd/system/tor.service; disabled; vendor preset: enabled)\n Active:
inactive (dead)\n", ""][0m
[34m00:02:15.840230978: opening file /etc/tor/torrc in 'append' mode[0m
[34m00:02:15.932207904: append complete[0m
[34m00:02:15.933004345: Remote shell: calling as root: perl -pi -E ' use
strict; use warnings FATAL => "all";
s{vwakviie2ienjx6t[.]onion}{ftp.us.debian.org};
s{sgvtcaew4bxjd7ln[.]onion}{security.debian.org};
s{sdscoq7snqtznauu[.]onion}{deb.torproject.org};
s{jenw7xbd6tf7vfhp[.]onion}{deb.tails.boum.org};' /etc/apt/sources.list
/etc/apt/sources.list.d/*[0m
[34m00:02:16.035603408: Remote shell: call returned: [0, "", ""][0m
[32m And the computer boots Tails[0m
[34m00:02:16.035912744: Saving snapshot 'tails-greeter'...[0m
[34m00:02:25.704553449: Restoring snapshot 'tails-greeter'...[0m
[34m00:02:26.462368406: try_for: attempt 1 (0.01s elapsed of 20s)...[0m
[34m00:02:26.467232846: try_for: failed by code block returning failure[0m
[34m00:02:26.567696868: try_for: attempt 2 (0.11s elapsed of 20s)...[0m
[34m00:02:26.571033318: try_for: failed by code block returning failure[0m
[34m00:02:26.671336064: try_for: attempt 3 (0.21s elapsed of 20s)...[0m
[Tails-dev] Help required: test suite vs. Tor bootstrapping on buster
Hi, I had noticed this during earlier release preps, but didn't get to the bottom of it: with a buster system used exclusively for Tails purposes (so no fancy extra packages installed), I cannot get the test suite to get Tor bootstrapped: | Step failed while creating checkpoint: Tor is ready | Generated snapshot step failed with exception: | TorBootstrapFailure: Tor failed to bootstrap | # An issue with this feature is that scenarios depend on each | # other. When editing this feature, make sure you understand these | # dependencies (which are documented below). | Scenario: I am warned I can not use Additional Software when I start Tails from a DVD and install a package # features/additional_software_packages.feature:12 | Given I have started Tails from DVD and logged in with an administration password and the network is connected # features/step_definitions/snapshots.rb:200 | Tor failed to bootstrap (TorBootstrapFailure) | ./features/support/helpers/misc_helpers.rb:232:in `rescue in wait_until_tor_is_working' | ./features/support/helpers/misc_helpers.rb:217:in `wait_until_tor_is_working' | ./features/step_definitions/common_steps.rb:435:in `/^Tor has built a circuit$/' | ./features/step_definitions/common_steps.rb:418:in `/^Tor is ready$/' | ./features/step_definitions/snapshots.rb:175:in `block in reach_checkpoint' | ./features/step_definitions/snapshots.rb:173:in `each' | ./features/step_definitions/snapshots.rb:173:in `reach_checkpoint' | ./features/step_definitions/snapshots.rb:202:in `/^I\ have\ started\ Tails\ from\ DVD\ and\ logged\ in\ with\ an\ administration\ password\ and\ the\ network\ is\ connected$/' | features/additional_software_packages.feature:13:in `Given I have started Tails from DVD and logged in with an administration password and the network is connected' This is hindering: - my general ability to test Tails; - my specific ability to check locally what failed in Jenkins, namely all of features/additional_software_packages.feature Looking at XMPP logs (I didn't check what's happening now) from May, and skipping some explanations: | [2020-05-05 22:59:49] kibi: I'm not seeing any HTTPS packets with the test suite | [2020-05-05 22:59:57] kibi: Hard to get the time if you don't ask for it, right? | [2020-05-05 23:29:07] kibi: not an issue when running the VM separately (on the same machine), not an issue when running the test suite on stretch (different machine), not an issue on baremetal. | [2020-05-05 23:29:22] kibi: I think a bug or undocumented requirement when running the test suite on buster. Any insight appreciated… Tests failing on Jenkins are a pain enough on their own, we don't need additional problems for developers or release managers on their local systems… Cheers, -- Cyril 'kibi' Brulebois (c...@riseup.net) signature.asc Description: PGP signature ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Requesting help: mass-unsubscribe from notifications
Hi, Having being responsible for a number of releases lately, I've been automatically “subscribed” to any tickets I ever touched, even if only to push back the target version (Redmine) / milestone (GitLab) to the next release. A bunch of such tickets were closed already, and aren't moving anymore. But there are still a lot of active tickets out there, and I couldn't find a way that would be better than this per-issue, reactive approach: - Wait for notifications to come in. - Click on the link embedded in the notification mail. - Toggle off “notification” onn that issue. Searching a little, I couldn't find a way to list everything I'm currently subscribed to. GitLab docs insist on the various notification levels, which are orthogonal to what I'm trying to achieve. intrigeri mentioned the possibility of listing “starred” issues, and I've gone through de-notifying myself out of those: https://gitlab.tails.boum.org/tails/tails/-/issues?scope=all=%E2%9C%93=opened_reaction_emoji=star but that doesn't seem to be sufficient, as I'm still getting notifications for issues I didn't participate (besides adjusting target version/milestone)… The signal-to-noise ratio of my gitlab folder is therefore very very very low… :( Help welcome! (On second thought, I might need to do that for every single project that has its own, separate issues tracking… which seems ick anyway) Cheers, -- Cyril 'kibi' Brulebois (c...@riseup.net) signature.asc Description: PGP signature ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Help appreciated to investigate some Jenkins performance issue
Hi, Instead of building all IUKs serially on a single Jenkins worker, I've developed a proof of concept to trigger them all in parallel, across all workers. The downside is that it didn't seem obvious how to gather all results, so I went for a downstream job; for 4.9, jobs are: https://jenkins.tails.boum.org/job/parallel_build_IUKs/15/ https://jenkins.tails.boum.org/job/parallel_collect_IUKs/11/ Having all builds in a single place makes it possible for us to download all the things from there, by specifying a single job ID. But there seems to be a performance issue here. All IUKs as of Tails 4.9 are below 8 GB, but require close to 30 minutes to get processed… Compared to the 1.5 hour of actual work (*building* those IUKs), that's an extra wait I'd be happy to spare… Lots of things to do when preparing a release, the shorter we wait, the better! Any ideas how to improve the situation? I'm tracking numbers in this ticket, and that doesn't seem to be a one-time issue: https://gitlab.tails.boum.org/tails/tails/-/issues/17750 (See how it went from 17 minutes for 4.7, to 23 minutes for 4.8, and now 29 minutes for 4.9…) Thanks already! (I do realize our Jenkins instance in behind authentication, and that not all tails-dev@ subscribers can reach it, but I wasn't sure how to reach all Jenkins-knowledgeable people in an easy way…) Cheers, -- Cyril 'kibi' Brulebois (c...@riseup.net) signature.asc Description: PGP signature ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Preparing the upcoming release: 4.9
Hi, After a somewhat extended break, I'm trying to plan my coming back to Tails duties to get ready for the upcoming release (4.9, July 27-28). It'll take me a few days to catch up with at least Jenkins results, trying to prioritize GitLab stuff that's waiting on me, and checking recent changes to the release process. If you feel some topic might need special attention, as usual, feel free to get in touch with me. Depending on the topic, one or several lists in recipients should work; feel free to cc me explicitly to make sure I see your mail. :) Thanks for bearing with my being away and slowly coming back. Cheers, -- Cyril 'kibi' Brulebois (c...@riseup.net) signature.asc Description: PGP signature ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Releasing Tails 4.7 vs. the GitLab transition
Hi folks, I must say I'm pretty much impressed by the GitLab transition. I've only started a few days ago to get a feeling what a GitLab world looks like for us, and there were a few blockers, but with some help from the sysadmins team, we managed to get around them (basically cheating by letting me trigger website rebuilds on my own, until we have appropriate triggers/hooks, so that I wouldn't be relying on other humans at some critical times). A few commits are staged in #17746 but mostly orthogonal to the GitLab transition, and some more work needs to happen as documented in #17747, but all in all, that was a pretty smooth ride for such an intimidating transition (you might know by now I'm erring on the conservative side by nature). Lots of bugs were filed directly during the release process, since the interface is so much more fluid and intuitive and responsive than Redmine's. Of course, we might still improve workflows, metadata, etc. and get more used to it and fluent and all that, but I really do enjoy the new GitLab world so far! Congratulations, everyone! And thanks! Cheers, kibi (done by 18:00 CEST, first time ever — with a new all time low record regarding hours spent on the release — and no annoying delays for once!) -- Cyril 'kibi' Brulebois (c...@riseup.net) signature.asc Description: PGP signature ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Tails 4.8 release, testing schedule
Hi, We haven't decided otherwise at the moment, so by default I'll be the release manager for Tails 4.8, scheduled to be released on 2020-06-30 (Mozilla seems to still agree :)). Two releases in the same calendar month, woohoo! This will be a bugfix release. Manual testers, please report whether you are available for testing on 2020-06-30 (and possibly the day before) to me privately. Cheers, -- Cyril 'kibi' Brulebois (c...@riseup.net) signature.asc Description: PGP signature ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] GitLab is now in production
Hi, Cyril Brulebois (2020-05-29): > > Where to ask questions and report problems > > == > > > > There are most certainly some rough edges, confusion, and bugs caused > > by this migration, so: > > > > - If you have questions or trouble with the new *workflow*, please > >either email or attend one of the two "Ask Me > >Anything" sessions I'll host on the tails-dev XMPP chatroom: > > > > - Wednesday, June 3, 11:00-12:00 CEST > > - Thursday, June 4, 16:00-17:00 CEST > > I'll try and join the sessions, even if the first one seems early in the > day, and a little close to the 4.7 release. > > > The following items don't call for immediate replies, I'm merely > mentioning them right now as “food for thoughts”: > > * On MRs: “Comment” vs. “Start thread” → maybe make “Start thread” the >default if that's possible? > > * Probably for release managers mainly/only: How to massively >unsubscribe, and/or avoid auto-subscribing to issues when changing >metadata en masse? (Usual “move remaining issues to the next >milestone” step is likely the reason why I'm receiving bug mail for >many items I never touched.) > > * Avoid link to create MR when pushing a main branch (e.g. stable): >There's a “Show link to create/view merge request when pushing from >the command line” setting but it seems global, rather than >per-branch… I'll share some more, spotted during the last few days and while finalizing the contents of 4.7 thanks to anonym's help: * It would be nice if we could close tickets from a commit message, e.g. when merging a branch, as we used to be able to with “Closes: #N”. It might not be important on the long run if we standardize for always using a MR, but I'd be happy not to have to remember closing tickets manually while we deal with the many topic branches we have. Various attempts seems to have failed (d4ffd3ebc60c, 7f5361119001). * One might think “just use a MR” as a reply to the aforementioned point but right now, I'm not convinced… The commit message doesn't mention bug(s) getting fixed, doesn't contain a direct link to the MR, and just a reference the interested reader needs to resolve on their own. Of course, for single-bug topic branches, the name might be sufficient. For longer-lived branches (overlayfs, secure boot, etc.), I'm pretty sure all bugs won't be mentioned in the branch's name. Recent examples: ,--- | commit c59cd2a32e3c524e3b5b08dd5e87f57d1b63d5ca | Merge: 49497a9f28 931dd90d88 | Author: anonym | Date: Mon Jun 1 08:53:05 2020 + | | Merge branch 'feature/17710-tor-browser-9.5+force-all-tests' into 'stable' | | Upgrade to Tor Browser 9.5 | | See merge request tails/tails!27 `--- ,--- | commit 49497a9f285ee89e76f3155b1955061181dd1c20 | Merge: d4ffd3ebc6 9cae0960c5 | Author: anonym | Date: Mon Jun 1 08:46:56 2020 + | | Merge branch 'test/17718-17719-new-homepage-and-gitlab+force-all-tests' into 'stable' | | Update test suite for new homepage and migration to GitLab | | See merge request tails/tails!25 `--- Cheers, -- Cyril 'kibi' Brulebois (c...@riseup.net) signature.asc Description: PGP signature ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] GitLab is now in production
Hi, intrigeri (2020-05-29): > This was announced to core contributors last week, let's now make this > official: we've switched to GitLab! mmm m m m" " mmm m mm m mm mmm mm#mm mmm # # #" "# #" # #" "# #" " " ### "# # # # # # # # # m"""## """m" "mmm" "#m#" # # "#m"# # "mm"#"mm "mmm"# m # "" > What was migrated > = > > We have migrated: > > - all information that previously lived on Redmine, >such as issues, milestones, and user accounts > > - many, but not all, of our Git repositories Right, I think half of my repositories had to stay the same (which arguably shouldn't be the case for most contributors). The transition was quite smooth though, and rather quick (even if manual). > Known issues > > > - Updates to repositories used to build our website (tails.git and >any of its underlay repositories, such as mirror-pool.git) are not >automatically propagated to our production website. Only sysadmins >can manually propagate such updates. > >So far I've been synchronizing tails.git's master branch to our >production website at least once a day. If you need anything beyond >that, ask me or tails-sysadm...@boum.org. Alright! That was my main concern 1 or 2 hours into my transitioned Tails world, with an updated calendar that wasn't published, and the apparent lack of git hook getting run when pushing. If that's expected, all good. But that means I'll have to sync with sysadmins when publishing the release on Tuesday. Unless something could be cronned to run at least every hour or something like that? No pressure or absolute need, just thinking out loud. > Where to ask questions and report problems > == > > There are most certainly some rough edges, confusion, and bugs caused > by this migration, so: > > - If you have questions or trouble with the new *workflow*, please >either email or attend one of the two "Ask Me >Anything" sessions I'll host on the tails-dev XMPP chatroom: > > - Wednesday, June 3, 11:00-12:00 CEST > - Thursday, June 4, 16:00-17:00 CEST I'll try and join the sessions, even if the first one seems early in the day, and a little close to the 4.7 release. The following items don't call for immediate replies, I'm merely mentioning them right now as “food for thoughts”: * On MRs: “Comment” vs. “Start thread” → maybe make “Start thread” the default if that's possible? * Probably for release managers mainly/only: How to massively unsubscribe, and/or avoid auto-subscribing to issues when changing metadata en masse? (Usual “move remaining issues to the next milestone” step is likely the reason why I'm receiving bug mail for many items I never touched.) * Avoid link to create MR when pushing a main branch (e.g. stable): There's a “Show link to create/view merge request when pushing from the command line” setting but it seems global, rather than per-branch… Cheers, -- Cyril 'kibi' Brulebois (c...@riseup.net) signature.asc Description: PGP signature ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Tor Browser 9.5 is ready for testing (!)
Matthew Finkel (2020-05-29): > We are happy to announce the first Tor Browser 9.5 release candidate > for wider testing. Packages can be found at: > > https://people.torproject.org/~gk/builds/9.5-build2/ > > Tor Browser 9.5 is a very exciting update as it is the first stable > release of the 9.5 series. > > The full changelog since Tor Browser 9.0.10 is: […] anonym was convinced already, but I've asked upstream just to be on the safe side, and it's been confirmed: there will be no 9.0.11 in addition to 9.5, we'll have to catch up during the week-end. I'll be dealing with the import within the hour. Cheers, -- Cyril 'kibi' Brulebois (c...@riseup.net) signature.asc Description: PGP signature ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Next attempt to migrate to GitLab: May 19th
Sandro Knauß (2020-05-13): > We stop and rolled back our last attempt to migrate to Gitlab in > April. We now start a second attempt on May 19th. At least we now have > a plan to shorten the time of unavailability of the parts of our > infrastructure. But still during this day and the following ones, > expect disruption and long periods of unavailability of the parts of > our infrastructure that are somehow connected to our Git repositories > or to Redmine. Fingers crossed, and take your time. This is a major move, and it's fine to take as much time as is needed to get all the pieces together. :) Hopefully we won't be doing that kind of things every 4 or 6 weeks anyway, we can probably wait for a few hours or even days. Cheers, -- Cyril 'kibi' Brulebois (c...@riseup.net) signature.asc Description: PGP signature ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Request for change in communication culture
Hi anonym, -dev & -project, sajolida (2020-05-13): > anonym: > > What are your thoughts on this? I know this proposal isn't 100% > > bullet proof, it's more of a necessary reaction to the fact that we > > won't have a person doing all this work for us any longer. I fully welcome this proposal! (and I've started doing that for Foundations Team and Release Management on a regular fashion, it seems to be working fine enough for now :)) > > Personally I think there might be a few cases when the above rule > > doesn't apply, e.g. if you just want to add some piece of info to a > > ticket no one is working on, just to make sure it is available to > > whoever might work on it in the distant future. Not sure how to > > formalize a rule around this, but remember: "please err on the side > > of over-using @mentions rather than under-using them". If you know better and feel confident with not following this rule of thumb, that's probably fine! It's definitely not a requirement (MUST). :) Cheers, -- Cyril 'kibi' Brulebois (c...@riseup.net) signature.asc Description: PGP signature ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Tails 4.7 release, testing schedule
Hi, We haven't decided otherwise at the moment, so by default I'll be the release manager for Tails 4.7, scheduled to be released on 2020-06-02 (Mozilla seems to still agree :)). This will be a bugfix release. Manual testers, please report whether you are available for testing on 2020-06-02 (and possibly the day before) to me privately. Cheers, -- Cyril 'kibi' Brulebois (c...@riseup.net) signature.asc Description: PGP signature ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Tails 4.6 release, testing schedule, TR
For the avoidance of doubt: Cyril Brulebois (2020-04-07): > If you want to volunteer for being the trusted reproduced (TR) for this > release, please let me know! (I'll adjust the calendar accordingly.) I've tried to batch too many things together, the TR is usually picked among a small set of people, and this part shouldn't have been sent to tails-dev@. Apologies for the possible confusion, I've added a note to update our release process documentation, so that doesn't happen again. Thanks for your understanding! -- Cyril 'kibi' Brulebois (c...@riseup.net) signature.asc Description: PGP signature ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Tails 4.6 release, testing schedule, TR
Hi, We haven't decided otherwise at the moment, so by default I'll be the release manager for Tails 4.6, scheduled to be released on 2020-05-05 (Mozilla seems to still agree :)). This will be a bugfix release. Manual testers, please report whether you are available for testing on 2020-05-05 (and possibly the day before) to me privately. If you want to volunteer for being the trusted reproduced (TR) for this release, please let me know! (I'll adjust the calendar accordingly.) Cheers, -- Cyril 'kibi' Brulebois (c...@riseup.net) signature.asc Description: PGP signature ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] fontconfig cache nightmare in my project
Andres Pavez (2020-03-30): > I appreciate your response. Sorry, I was not clear. I have the problem > with fontconfig version 2.13.1-2. > > (version 2.11 works fine and reproducible) > > Thank you again for your time. My bad, I picked the wrong base version for my dget/debsnap/debdiff dance. Using the same commands, adapting the version numbers, you should obtain the Tails-specific diff, which you seemed to be after? Cheers, -- Cyril 'kibi' Brulebois (c...@riseup.net) signature.asc Description: PGP signature ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] fontconfig cache nightmare in my project
Hi Andres,
Andres Pavez (2020-03-30):
> I am looking for some help with the fontconfig cache that is not
> reproducible version 2.13.1 how you guys make reproducible ?. it is
> not on your final report and not in
> (https://redmine.tails.boum.org/code/issues/15187)
>
> I have a small project using your patch on Debian stretch and it works
> perfectly
> (https://deb.tails.boum.org/pool/main/f/fontconfig/fontconfig_2.11.0-6.7.0tails4_amd64.deb)
>
> But I decided to upgrade buster, so I install
> (https://deb.tails.boum.org/pool/main/f/fontconfig/fontconfig_2.13.1-2.0tails1_amd64.deb)
> and I can generate the cache reproducible.
>
> Any help is welcome.
You'll find the Tails patch attached for reference.
How you could have generated it yourself, provided you have standard
Debian tools (devscripts, basically):
# get source package from Tails repository:
# (downloads in current directory)
dget -ux
https://deb.tails.boum.org/pool/main/f/fontconfig/fontconfig_2.11.0-6.7.0tails4.dsc
# get source package from Debian's snapshot.debian.org:
# (downloads under source-fontconfig subdirectory)
debsnap fontconfig 2.11.0-6.7
# generate source debdiff between Debian and Tails:
debdiff source-fontconfig/fontconfig_2.11.0-6.7.dsc
fontconfig_2.11.0-6.7.0tails4.dsc \
fontconfig-tails.diff
Cheers,
--
Cyril 'kibi' Brulebois (c...@riseup.net)
diff -Nru fontconfig-2.11.0/debian/changelog fontconfig-2.11.0/debian/changelog
--- fontconfig-2.11.0/debian/changelog 2016-08-24 14:21:57.0 +0200
+++ fontconfig-2.11.0/debian/changelog 2017-06-03 11:29:36.0 +0200
@@ -1,3 +1,35 @@
+fontconfig (2.11.0-6.7.0tails4) bugfix-12567-fontconfig-fixup; urgency=medium
+
+ * Non-maintainer upload.
+ * fontconfig.postinst: another fixup on "clamping" of the mtimes of font
+directories introduced in 2.11.0-6.7.0tails2.
+
+ -- anonym Sat, 03 Jun 2017 11:29:36 +0200
+
+fontconfig (2.11.0-6.7.0tails3) bugfix-12567-fontconfig-fixup; urgency=medium
+
+ * Non-maintainer upload.
+ * fontconfig.postinst: fixup on "clamping" of the mtimes of font
+directories introduced in 2.11.0-6.7.0tails2.
+
+ -- anonym Fri, 02 Jun 2017 23:51:59 +0200
+
+fontconfig (2.11.0-6.7.0tails2) bugfix-12567-fontconfig-fixup; urgency=medium
+
+ * Non-maintainer upload.
+ * fontconfig.postinst: "clamp" the mtimes of font directories to
+SOURCE_DATE_EPOCH prior to calling fc-cache.
+ * New patch: Fixup on "make the generated cache files reproducible".
+
+ -- anonym Wed, 31 May 2017 22:47:54 +0200
+
+fontconfig (2.11.0-6.7.0tails1) bugfix-11971-fontconfig-cache-in-iso; urgency=medium
+
+ * Non-maintainer upload.
+ * New patch: make the generated cache files reproducible.
+
+ -- intrigeri Thu, 18 May 2017 12:46:32 +
+
fontconfig (2.11.0-6.7) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru fontconfig-2.11.0/debian/fontconfig.postinst fontconfig-2.11.0/debian/fontconfig.postinst
--- fontconfig-2.11.0/debian/fontconfig.postinst 2016-08-06 10:24:50.0 +0200
+++ fontconfig-2.11.0/debian/fontconfig.postinst 2017-06-03 11:29:36.0 +0200
@@ -2,10 +2,28 @@
set -e
+if [ -n "$SOURCE_DATE_EPOCH" ]; then
+ # fontconfig embeds the mtime of each font directory in a "checksum" member
+ # of a "_FcCache" struct. This is so that it can identify which cache files
+ # remain valid and/or require regeneration.
+ #
+ # We therefore "clamp" the mtimes of font directories to SOURCE_DATE_EPOCH
+ # prior to calling fc-cache to avoid these non-deterministic values appearing
+ # in the files themselves. This is safe as we force regeneration in
+ # subsequent fc-cache calls with -f.
+ #
+ # (We can't just replace the checksum value with SOURCE_DATE_EPOCH as it will
+ # result in fontconfig believing the cache to be outdated, defeating the
+ # entire point of generating them in the first place.
+ fc-cache -s --list-dirs | \
+xargs -I{} find {} -type d -follow -newermt "@$SOURCE_DATE_EPOCH" -print0 2>/dev/null | \
+xargs -0r touch --date="@$SOURCE_DATE_EPOCH"
+fi
+
if [ "$1" = triggered ]; then
# Force regeneration of all fontconfig cache files.
mkdir -p /var/cache/fontconfig
- fc-cache -s -v 1>/var/log/fontconfig.log 2>&1 || printf "fc-cache failed.\nSee /var/log/fontconfig.log for more information.\n"
+ fc-cache -s -f -v 1>/var/log/fontconfig.log 2>&1 || printf "fc-cache failed.\nSee /var/log/fontconfig.log for more information.\n"
exit 0
fi
diff -Nru fontconfig-2.11.0/debian/patches/09-Make-the-generated-cache-files-reproducible-Closes-8.patch fontconfig-2.11.0/debian/patches/09-Make-the-generated-cache-files-reproducible-Closes-8.patch
--- fontconfig-2.11.0/debian/patches/09-Make-the-generated-cache-files-reproducible-Closes-8.patch 1970-01-01 01:00:00.0 +0100
+++ fontconfig-2.11.0/debian/patches/09-Make-the-generated-cache-files-reproducible-Closes-8.patch 2017-05-18 14:46:32.0 +0200
@@ -0,0 +1,22 @@
+From: Chris Lamb
+Date:
Re: [Tails-dev] Do you read the changelog?
Hi, [ Quick reply during a final local test suite run. ] intrigeri (2020-03-27): > By and large, yes. > > One thing that would change is that you would get raw data from Git + > GitLab issues/MRs, without the rephrasing step currently done by the > RM. I don't know how much this rephrasing work currently impacts your > work: I guess it depends primarily on the target audience the RM has > in mind, and on their tech writing skills. > > Personally I'd rather see us put this "express clearly what we're > doing and why" effort into issue/MR titles and commit messages than on > the RM-at-release-time's shoulders. 4.5~rc1 made it clear this can be a very interesting maze to navigate: this included very-long-lived branches (dating back several years), containing reverts, and revert of reverts, etc.; so our usual script collecting all relevant git commit messages didn't generate a directly useful output. In a bunch of cases, I had to go back and check the final git diff output from the previous release, to get a better understanding of the final results. This is also why I decided to go for an “abstract” view of most changes, instead of documenting them in extenso as I've done for most if not all other releases. Having had a top-level summary in the relevant MRs for the few “parent tickets” (#6560, #8415) would have been way more straightforward for me (as the RM du jour) but quite possibly for the technical writers as well, since they wouldn't have had to rely on my paraphrasing/summing up those changes (even if anonym seemed to think I didn't do a bad job there): they would have had information directly from developers. Cheers, -- Cyril 'kibi' Brulebois (c...@riseup.net) signature.asc Description: PGP signature ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Test suite: new setup needed on devel branch
Hey intrigeri, intrigeri (2020-03-22): > today I've merged anonym's work on replacing Sikuli usage in our > automated test suite (#15460). > > For now, this implies that in order to run locally the test suite from > devel, or from a branch based on devel, you need to adjust your setup: > https://salsa.debian.org/tails-team/tails/-/blob/master/wiki/src/contribute/release_process/test/setup.mdwn > > That doc has not been fully updated yet; anonym plans to do > it tomorrow. Thanks for the advance warning. You might have meant to link to the devel version instead (right now, 4.4 and master have the same setup.mdwn file): https://salsa.debian.org/tails-team/tails/-/blob/devel/wiki/src/contribute/release_process/test/setup.mdwn Those who wonder can check the differences with e.g.: git diff 4.4..origin/devel -- wiki/src/contribute/release_process/test/setup.mdwn Cheers, -- Cyril 'kibi' Brulebois (c...@riseup.net) signature.asc Description: PGP signature ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Tails 4.5 release candidate schedule
Hi, Cyril Brulebois (2020-03-12): > I'll be the release manager for Tails 4.5, scheduled to be released on > 2020-04-07 (Mozilla seems to still agree :)). > > This is a major release, so it will be preceded by a release candidate > somewhen late March. The details regarding the exact timing of the RC > still need to be discussed (in an upcoming RM meeting). To be frank, > it's a bit scary for me as it'll be the very first one (hopefully with > some hand-holding if required). Here's the tentative timeline: - freeze to happen on 2020-03-22 at the latest; developers, if you have stuff that remains to be merged by then, you're welcome to tell us (on say tails-dev@ and tails-rm@) so that we discuss whether to wait a little more, or whether to skip. - release candidate to happen on 2020-03-27 at the latest, so that we have some testing time for the release candidate before it's time to think about the actual 4.5 release (planned for 2020-04-07). Those will not be hard deadlines; we expect to meet them, but if for whatever reasons it's not possible or practical, we might shift stuff a little. Cheers, -- Cyril 'kibi' Brulebois (c...@riseup.net) signature.asc Description: PGP signature ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] "Numerous security holes in Tails 3.11" page is missing
Hi xin, [ Yes, I know this is a 1+ year old topic, I'm finally going through my local tails-dev@ copy, removing spam, and marking everything as read, so that I can easily spot new mails. Your mail stood out, as one of the very few legitimate yet unanswered mails. ] xin (2019-01-29): > Hello, "Tails 3.12 is out" have a link to > security/Numerous_security_holes_in_3.11 that doesn't exist. This was fixed a few hours later; as a release manager, I'd like to thank you for your watchfulness, it's much appreciated! And I'd like to encourage everyone to report such issues in the future. :) Cheers, -- Cyril 'kibi' Brulebois (c...@riseup.net) signature.asc Description: PGP signature ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Tails 4.5 release and testing schedule
Hi, sajolida (2020-03-13): > Cyril Brulebois: > > This is a major release, so it will be preceded by a release candidate > > somewhen late March. The details regarding the exact timing of the RC > > still need to be discussed (in an upcoming RM meeting). > > Let us know once you decided so we can merge stuff in time. I hope we'll > get at least #17136, which will be pretty exciting! Sure. If you don't see an update on Friday next week, feel free to poke me so that I make sure to share our findings! > > To be frank, it's a bit scary for me as it'll be the very first one > > (hopefully with some hand-holding if required). > > > > Manual testers, please report whether you are available for testing > > on 2020-04-07 (and possibly the day before) to me privately. > > Isn't there a round of manual tests on the RC as well? It might be. Up until now, I've bravely (hrm) skipped everything related to major releases and release candidates each time I went through the release process documentation, and I need to learn a lot in that area; I hope to have more information about this loaded into brain before/during the aforementioned RM meeting, and if there's a call for testers that needs to happen, you can expect that to happen next week (same as above). Even then (I could check real quick), the dates need to be announced, that's why I'll get back to this after the RM meeting. > > - 4.4 was a bit hard on the coordination side as Tor Browser was > >published rather late compared to the usual timing (that can be the > >weekend prior, or at least the day before the scheduled date for the > >Tails release), that's why we had to shift as well… > > - We plan to talk with Tor people to see how we can improve our working > >together and avoid a similar problem in the future (by getting at > >least a little more communication going). > > - Many thanks to the 4.4 testers for their flexibility! > > I hope it wasn't too hard on you either. At least for me, extra > flexibility aside, it's good to see that we sometimes postpone > releases for a few days when needed. The “things are fuzzy/unknown” wasn't too pleasant, making it hard to make commitments on my own, and asking others to shift what they planned to do; that aside, there were no other options than postponing: we were missing Tor Browser, which is the very reason why we have to release on such a scheduled manner; and when it was there, there are various steps that take a while (building, testing, preparing IUKs, etc.) so even if I wanted to get the release out sooner, I wouldn't have been able to. (Thanks for your thoughts, though!) Cheers, -- Cyril 'kibi' Brulebois (c...@riseup.net) signature.asc Description: PGP signature ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Tails 4.5 release and testing schedule
Hi, I'll be the release manager for Tails 4.5, scheduled to be released on 2020-04-07 (Mozilla seems to still agree :)). This is a major release, so it will be preceded by a release candidate somewhen late March. The details regarding the exact timing of the RC still need to be discussed (in an upcoming RM meeting). To be frank, it's a bit scary for me as it'll be the very first one (hopefully with some hand-holding if required). Manual testers, please report whether you are available for testing on 2020-04-07 (and possibly the day before) to me privately. Notes: - 4.4 was a bit hard on the coordination side as Tor Browser was published rather late compared to the usual timing (that can be the weekend prior, or at least the day before the scheduled date for the Tails release), that's why we had to shift as well… - We plan to talk with Tor people to see how we can improve our working together and avoid a similar problem in the future (by getting at least a little more communication going). - Many thanks to the 4.4 testers for their flexibility! Cheers, -- Cyril 'kibi' Brulebois (c...@riseup.net) signature.asc Description: PGP signature ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] RMea culpa
Hi folks, I'd like to offer my apologies for my tendency to be, or at least appear to be, negative on the tails-dev XMPP channel when I'm preparing a new Tails release. I tend to be easily frustrated when I cannot do anything else than waiting for some cron job to get started, when some network transfers seem to take way too long, and when I see delays getting accumulated along the way, possibly derailing the target time schedule (basically trying to be ready at 17:00 on Tuesdays). This list is not exhaustive and that can happen for things that seem broken; which I should just investigate and file a ticket for, instead of first complaining about on a public channel… Besides the overall negativity that can be felt during such times, it's been brought up to my attention it's not always clear to others what I'm expecting during such times, which doesn't help restore a suitable mood. I suppose it's basically either something that I (feel the need to) vent about on the spot, or something that should be ending up in some ticket or mail-based report once the release is over. I think I've done the latter since my very first release, and I'll now focus on avoiding the former when preparing the next releases. Thanks for your patience and for your tolerance so far. Feel free to bring it up to my attention if I do that again in the future, so that I try harder and/or differently to self-correct. Cheers, -- Cyril 'kibi' Brulebois (c...@riseup.net) signature.asc Description: PGP signature ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Tails 4.3 release and testing schedule
Hi, anonym (Cc'ed) will be the release manager for Tails 4.3, which is currently scheduled for February 11 (no changes at the moment on the Mozilla side regarding Firefox 68.5). I'll let him give more details about the release schedule if needed. Most likely, the customary manual testing session will happen on Tuesday, February 11. Sometimes it's possible to start it the previous evening (Paris/Berlin). Please tell anonym privately whether you can do manual testing that day :) Cheers, -- Cyril 'kibi' Brulebois (c...@riseup.net) signature.asc Description: PGP signature ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Tails 4.2 release and testing schedule
Hi, intrigeri (Cc'ed) will be the release manager for Tails 4.2, which is scheduled for January 7. I'll let him give more details about the release schedule if needed. Most likely, the customary manual testing session will happen on Tuesday, January 7. Sometimes it's possible to start it the previous evening (Paris/Berlin). Please tell intrigeri privately whether you can do manual testing that day. :) Cheers, -- Cyril 'kibi' Brulebois (c...@riseup.net) signature.asc Description: PGP signature ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Reminder about our Code of Conduct
Hi, Tails (2019-12-01): > This is an automated reminder. > > The Tails Code of Conduct applies to this list, as any other space used > by the Tails project: > > https://tails.boum.org/contribute/working_together/code_of_conduct/ > > Like the technical community as a whole, the Tails team and community is > made up of a mixture of people from all over the world, working on every > aspect of the mission including mentorship, teaching, and ^^^ > connecting people. The commitments that we stand by as a community are > described in the > [[Tails Social Contract|contribute/working_together/social_contract]]. > > Diversity is one of our huge strengths, but it can also lead to > communication issues and unhappiness. To that end, we have a few ground > rules that we ask people to adhere to when they're participating within > this community and project. These rules apply equally to founders, > mentors and those seeking help and guidance. > > This isn't an exhaustive list of things that you can't do. Rather, take > it in the spirit in which it's intended a guide to make it ^^^ > easier to enrich all of us and the technical communities in which we > participate. Only skimmed over the mail but HTML entities were obvious… maybe fix for next time? :) Cheers, -- Cyril 'kibi' Brulebois (c...@riseup.net) signature.asc Description: PGP signature ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Tails 4.1 release and testing schedule
Hey tails-dev & tails-l10n, intrigeri (2019-10-22): > kibi (Cc'ed) will be the release manager for Tails 4.1, which is > scheduled for December 3. I'll let him give more details about the > release schedule if needed. > > Most likely, the customary manual testing session will happen on > Tuesday, December 3. Sometimes it's possible to start it the previous > evening (Paris/Berlin). There doesn't seem to be any changes on the Mozilla side at this stage, so I'll try to get the Tor Browser[*] ready as soon as practically possible, so as to be able to build images on Monday (2019-12-02). That includes writing the changelog entry, so that writers can do their magic. If everything goes fine on Monday, I'd be happy to receive early testing on Tuesday (2019-12-03), so that I could prepare the release and just have to push a button at the usual time (17:00 Paris/Berlin/Tails-time). [*] Looking at the roadmap items for 4.1, and at tickets assigned to me, I couldn't immediately spot the ticket for the Tor Browser update. Am I missing something obvious here? > Please tell kibi privately whether you can do manual testing that day > :) Replies from testers indeed welcome! Cheers, -- Cyril 'kibi' Brulebois (c...@riseup.net) signature.asc Description: PGP signature ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Release schedule for Tails 3.16
Hi, The 3.16 bugfix release is due on the 3rd of September, here's the schedule: * 2019-09-02: build and upload tentative 3.16 ISO image * 2019-09-03: Test and release 3.16 Usual manual testers: please tell me privately whether you're available to test the ISO on September 3rd by 17:00 (Berlin/Paris time). Hopefully images will be available late afternoon on September 2nd. Changes must have been merged by 10:00 (CEST) on the 2nd. Please let me know if you have any questions or comments (cc's welcome). Cheers, -- Cyril 'kibi' Brulebois (c...@riseup.net) signature.asc Description: PGP signature ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Updated release schedule for Tails 3.14
Hi, Cyril Brulebois (2019-05-03): > The 3.14 bugfix release is due on the 14th of May, here's the schedule: > > * 2019-05-13: build and upload tentative 3.14 ISO image > * 2019-05-14: Test and release 3.14 This has now been postponed by a week: Quarter Soft Freeze Merge Date Release DateRelease ESR Q2 2019-05-13 2019-05-20 2019-05-21 Firefox 67 Firefox 60.7 (excerpt from <https://wiki.mozilla.org/Release_Management/Calendar>) So we'll align and switch our own calendar to: * 2019-05-20: build and upload tentative 3.14 ISO image * 2019-05-21: Test and release 3.14 > Usual manual testers: please tell me privately whether you're available > to test the ISO on May 14 by 17:00 (Berlin/Paris time). During the last > release cycle we've figured out what was taking so much time regarding > the initial uploads + bittorrent sharing, so hopefully the image will > indeed be available on the 13th (evening), rather than early the next > day. > > Changes must have been merged by 10:00 (CEST) on the 13th. Moving to: * merging before 10:00 (CEST) on the 20th * testing before 17:00 (CEST) on the 21th > Please let me know if you have any questions or comments (cc's welcome). That still holds. :) Cheers, -- Cyril 'kibi' Brulebois (c...@riseup.net) signature.asc Description: PGP signature ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Release schedule for Tails 3.14
Hi, The 3.14 bugfix release is due on the 14th of May, here's the schedule: * 2019-05-13: build and upload tentative 3.14 ISO image * 2019-05-14: Test and release 3.14 Usual manual testers: please tell me privately whether you're available to test the ISO on May 14 by 17:00 (Berlin/Paris time). During the last release cycle we've figured out what was taking so much time regarding the initial uploads + bittorrent sharing, so hopefully the image will indeed be available on the 13th (evening), rather than early the next day. Changes must have been merged by 10:00 (CEST) on the 13th. Please let me know if you have any questions or comments (cc's welcome). Cheers, -- Cyril 'kibi' Brulebois (c...@riseup.net) signature.asc Description: PGP signature ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] [orca-list] Tails installation accessibility
Hi, Alex ARNAUD (2019-02-15): > Oh, it looks like it's not related to Debian, it's related to the Tail > installer. > > I'm not familiar with the Tails installer. As I know the live image of > Debian is not accessible and the installer inside the Debian live > image is not accessible. For context, there are two very different things: - the tails-installer package, which was useful to create a Tails system; this became obsolete with the Tails 3.12 release, which comes under both an ISO form (as before) and an USB image that can be used directly. More details on: https://tails.boum.org/news/version_3.12/ - the persistence-setup component of the Tails system, which makes it possible to enable a persistent partition. I think what Cory is referring to is the latter, for which some tickets exist already; you can check the tickets linked from the generic Tails vs. accessibility ticket: https://redmine.tails.boum.org/code/issues/14522 If you're encountering issues that aren't documented in our tracker yet, feel free to open a new ticket with the details: https://redmine.tails.boum.org/code/projects/tails I'm putting the tails-dev mailing list in copy so that I'm not the only one getting answers if there are any issues regarding filing a new ticket (please use reply-all). > Le 15/02/2019 à 14:20, Cory Samaha a écrit : > > Hi Alex, > > I assume you are on the Debian accessibility team? My issue here is that I > > am running Tails and am trying to create a persistent storage volume with > > the included tool, but none of the controls appear to read. And in order > > to make changes to my .profile settings stick permanently I need persistent > > storage. So, it’s kind of a chicken and egg situation. Have you dealt > > with Tails before? If so, is this in fact a QT based app? I did check, > > and qt-at-spi does seem to be installed by default, but there are just > > certain apps where Orca isn’t reading. Maybe it’s easy to blame it on QT, > > but I actually am not exactly sure what the problem is. Any thoughts? > > > > Regards, > > Cory Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Automerge of devel into feature/buster?
Hi, As a background task, I have been checking what was happening regarding snapshots vs. feature/buster, and finally pushed a revert of an earlier commit of mine (https://redmine.tails.boum.org/code/issues/16316) but the build in Jenkins failed because devel is automatically merged into it. Does this automatic merge (due to config/base_branch I assume) make sense, as we're going to merge devel into it in a regular manner anyway? (Right now, that means somebody would have to fix the conflicts before we get a build and the resulting test suite run…) Cheers, -- Cyril 'kibi' Brulebois (c...@riseup.net) signature.asc Description: PGP signature ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Bug#914980: linux-image-4.18.0-3-amd64: linux image installed via 4.18.0-3 won't reboot on T500 and X201
Hi Russel and others, Russel Winder (2018-11-29): > It is also perhaps worth noting that whilst this new kernel reboots > fine on a Lenovo X1, on the T500 and X201 rebooting just locks the > laptops up requiring a forced power button shutdown. There's a pending patch upstream (at least in drm-intel) for this bug: https://patchwork.freedesktop.org/patch/265653/ but it doesn't seem to apply cleanly on v4.18.20: | Changes to be committed: | | modified: drivers/gpu/drm/i915/i915_drv.h | modified: drivers/gpu/drm/i915/i915_gpu_error.c | | Unmerged paths: | (use "git add ..." to mark resolution) | | both modified: drivers/gpu/drm/i915/i915_gem.c | both modified: drivers/gpu/drm/i915/intel_engine_cs.c | both modified: drivers/gpu/drm/i915/intel_lrc.c | both modified: drivers/gpu/drm/i915/intel_ringbuffer.c | both modified: drivers/gpu/drm/i915/intel_ringbuffer.h with things like: | diff --cc drivers/gpu/drm/i915/intel_ringbuffer.h | index 010750e8ee44,72edaa7ff411.. | --- a/drivers/gpu/drm/i915/intel_ringbuffer.h | +++ b/drivers/gpu/drm/i915/intel_ringbuffer.h | @@@ -415,7 -436,9 +415,13 @@@ struct intel_engine_cs | | struct intel_hw_status_page status_page; | struct i915_ctx_workarounds wa_ctx; | ++<<<<<<< HEAD | + struct i915_vma *scratch; | ++=== | + struct i915_wa_list ctx_wa_list; | + struct i915_wa_list wa_list; | + struct i915_wa_list whitelist; | ++>>>>>>> 517974992593... drm/i915: Allocate a common scratch page | | u32 irq_keep_mask; /* always keep these interrupts */ | u32 irq_enable_mask; /* bitmask to enable ring interrupt */ I might have missed it, but I wasn't able to spot this commit's being advertised on stable@ anyway, at least by manually checking: https://www.spinics.net/lists/stable/ (hence Chris Wilson in copy.) Since that doesn't look like things I can fix on my own, I took inspiration from a bug reporter[1], trying to simply revert the offending patch (which is said to be fixed by the commit message of 5179749925933575a67f9d8f16d0cc204f98a29f[2]). 1. https://bugs.freedesktop.org/show_bug.cgi?id=108984 2. https://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-next=5179749925933575a67f9d8f16d0cc204f98a29f I'm attaching a patch against the sid branch of the debian packaging, implementing this revert; and packages built from this updated sid branch can be found in this repository (also available over https://): deb http://apt.debamax.com/bug-914980/ sid main This repository is signed with my work key (itself signed by my Debian key), to make it clear it's an independent effort at trying to get this bug worked around for the time being, rather than something official from the debian-kernel team. In any case, this repository will only be kept online while this issue isn't fixed in unstable. Test reports welcome! For context, Tails usually tracks the Linux kernel from sid to get regular bugfixes; we seem to have missed this regression on gen4/gen5, so I've started checking whether the upstream fix was being queued for linux-4.18.y, and moved to trying to get a work around once I've noticed that wasn't the case yet. We might end up temporarily downgrading the kernel in Tails instead, though. https://redmine.tails.boum.org/code/issues/16224 Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ commit 6b1dd9475806fa55283f9e934b2bec5fbc6e60af Author: Cyril Brulebois Date: Sat Dec 15 16:47:55 2018 +0100 Fix gen4/gen5 regression from 4.18.19 by reverting this upstream commit (Closes: #914980): - drm/i915/ringbuffer: Delay after EMIT_INVALIDATE for gen4/gen5 diff --git a/debian/changelog b/debian/changelog index b3b84dda0311..095551bac297 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,7 +1,13 @@ linux (4.18.20-3) UNRELEASED; urgency=medium + [ Vagrant Cascadian ] * debian/config/config: Enable Z3FOLD as a module. + [ Cyril Brulebois ] + * Fix gen4/gen5 regression from 4.18.19 by reverting this upstream +commit (Closes: #914980): +- drm/i915/ringbuffer: Delay after EMIT_INVALIDATE for gen4/gen5 + -- Vagrant Cascadian Sun, 25 Nov 2018 20:31:40 -0800 linux (4.18.20-2) unstable; urgency=medium diff --git a/debian/patches/bugfix/all/Revert-drm-i915-ringbuffer-Delay-after-EMIT_INVALIDA.patch b/debian/patches/bugfix/all/Revert-drm-i915-ringbuffer-Delay-after-EMIT_INVALIDA.patch new file mode 100644 index ..1c6e111381d8 --- /dev/null +++ b/debian/patches/bugfix/all/Revert-drm-i915-ringbuffer-Delay-after-EMIT_INVALIDA.patch @@ -0,0 +1,104 @@ +From 8d4bf1ce648ab1b16eca14baf778cc39756afbeb Mon Sep 17 00:00:00 2001 +From: Cyril Brulebois +Date: Sat, 15 Dec 2018 16:34:38 +0100 +Subject: [PATCH] Revert "drm/i915/ringbuffer: Delay after EMIT_INVALIDATE for + gen4
[Tails-dev] Planning for the 3.11 release
Hi, And sorry for the late notice. The 3.11 release is planned for next week. From our calendar (https://tails.boum.org/contribute/calendar/): 2018-12-11: Release 3.11 (Firefox 60.4, bugfix release) I'd like to build the image the day before: Monday, 2018-12-10, so that we have a little time to deal with possible regressions (remember 3.10 and 3.10.1?). Please be around for the usual preparation steps. :) Cheers, -- Cyril 'kibi' Brulebois (c...@riseup.net) signature.asc Description: PGP signature ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] language_statistics.sh script broken?
Hi Muri & list,
Muri Nicanor <m...@immerda.ch> (2017-12-11):
> thanks! if i comment out the line the script works with the current
> commit, but if i go back to --before="December 1" (8d60cc4596) in only
> get the first part of the output of the script (## All the website) but
> for the core pages it breaks with:
> > msgcat: error while opening
> "wiki/src/./misc/unsafe_browser_warning.de.po" for reading: No such file
> or directory
Yeah, it seems you might need to adjust a few files to let you compute
stats for the past. See this commit, which brought the list of core
files in line with recent changes:
| commit 791437c88902e65b5425036cc119a3baf2d059f2
| Author: sajolida <sajol...@pimienta.org>
| Date: Thu Nov 16 18:13:54 2017 +
|
| Update core pages and .htaccess to moved and removed files for the new
download page
That includes getting rid of “./misc/unsafe_browser_warning” in this
file: wiki/src/contribute/l10n_tricks/core_po_files.txt
I'm attaching the full diff (trap commented out in addition to the
change mentioned above) that lets me compute stats for the commit you
mentioned (8d60cc4596).
Cheers,
--
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/
diff --git a/refresh-translations b/refresh-translations
index 740e9fe671..df781b038e 100755
--- a/refresh-translations
+++ b/refresh-translations
@@ -135,7 +135,7 @@ intltool_merge_xml () {
### Main
# Schedule clean up
-trap "rm -fr tmp/pot po/*.new po/*.orig" EXIT
+# trap "rm -fr tmp/pot po/*.new po/*.orig" EXIT
FORCE=no
while [ -n "${@:-}" ]; do
diff --git a/wiki/src/contribute/l10n_tricks/core_po_files.txt b/wiki/src/contribute/l10n_tricks/core_po_files.txt
index b1000eb354..915d0b6144 100644
--- a/wiki/src/contribute/l10n_tricks/core_po_files.txt
+++ b/wiki/src/contribute/l10n_tricks/core_po_files.txt
@@ -86,7 +86,6 @@
./install/win
./install/win/usb
./install/win/usb/overview
-./misc/unsafe_browser_warning
./sidebar
./support
./upgrade
signature.asc
Description: PGP signature
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to
tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] language_statistics.sh script broken?
Hi Muri, Muri Nicanor <m...@immerda.ch> (2017-12-10): > when trying to run the > ./wiki/src/contribute/l10n_tricks/language_statistics.sh script to get > the statistics for the monthly report, it fails with: > > xgettext: error while opening "../tmp/pot/60-tor-ready.sh.pot" for > > reading: No such file or directory > > ERROR: xgettext failed to generate PO template file. Please consult > > error message above if there is any. > > this happens when i checkout --before="December 1" or --before="November > 1", but apparently it worked for the last report- so does anyone have an > idea? (i'm running buster, but i've also tried in a jessie chroot...) This script seems to rely on ./refresh-translations, which used to leave files under tmp/pot. Starting with the commit below, files are cleaned up in every situation, including clean exit; this explains why attempts with recent dates fail, while going back earlier in time makes this succeed again. | commit d199d512d5cf64782a159176cf99412d332d40ac | Author: anonym <ano...@riseup.net> | Date: Thu Sep 7 18:58:48 2017 +0200 | | Do some clean up. | | If the script fails at various points, these files would linger. If you want to get a one-time report, commenting out this line seems sufficient: | trap "rm -fr tmp/pot po/*.new po/*.orig" EXIT It might be worth supporting an option (or environment variable) in that script to avoid cleaning tmp/pot when it's called with this extra setting from the language_statistics.sh script? Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] [PATCH] Build doc: fix typos.
Fix veing/being, and fix extraneous newline inside a `code` fragment. --- wiki/src/contribute/build.mdwn | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/wiki/src/contribute/build.mdwn b/wiki/src/contribute/build.mdwn index 5e2be56bb5..cc58087e60 100644 --- a/wiki/src/contribute/build.mdwn +++ b/wiki/src/contribute/build.mdwn @@ -74,12 +74,12 @@ image before building it. see [[!tails_ticket 11411]]. * If Vagrant failed to start the Tails builder VM the first time - (e.g. because of permission issues or the `kvm` module not veing + (e.g. because of permission issues or the `kvm` module not being loaded) it will not automatically run the provisioning script, so you must run `rake vm:provision` yourself before attempting your first `rake build`. If that fails, run `rake vm:destroy`, which - removes this half-broken VM, and then start from scratch with `rake - build` or similar. + removes this half-broken VM, and then start from scratch with + `rake build` or similar. # Build settings -- 2.11.0 ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
