Hi guix-devel,
I just sent out https://issues.guix.gnu.org/68005 to remove dxvk 1.5.5, which
as far as I can tell has been broken for a few years now (IIRC I tested as far
back in guix history as wine-staging 5.13 or 5.22 from 2-3 years ago and still
encountered the same errors building dxvk
Hi Andreas,
> Probably so! I will let you decide whether to apply it or to drop the 9.0
> version, both are fine from the core-updates point of view.
I fixed 9.0 in commit dc9c09023a5258de035424169b8e804acfd38cb2, but 9.4
still fails :( Will investigate.
Lars
Am Tue, Apr 18, 2023 at 05:04:35AM + schrieb John Kehayias:
> I took a stab at a few random packages and ended up finding out that
> python-urllib3 needed an update due to our updated
> python-cryptography. Only saw this through test failures of leaf
> packages rather than itself (noted in upst
Am Mon, Apr 17, 2023 at 09:01:20PM +0200 schrieb Lars-Dominik Braun:
> shouldn’t this snippet from 8.10 also work for 9.0?
>(modules '((guix build utils)))
>(snippet
> ;; collections.Iterable was moved to collections.abc in Python
> 3.10.
> '(substit
On Tue, Apr 18, 2023 at 12:55 AM, John Kehayias wrote:
> Oh, looks like no x86_64 builds currently on Cuirass...hopefully
> temporary?
>
Never mind, builds going through now! Okay, I really must get to bed!
Hi Andreas and Guixers,
Again, thanks Andreas for all your work on core-updates!
On Mon, Apr 17, 2023 at 11:03 AM, Andreas Enge wrote:
> Hello,
>
> just a quick update after a night of building on CI.
> Things look generally quite good on x86_64; some things are being rebuilt
> due to the recent
Hi Andreas,
> Well, I would see this as rather an action for a later feature branch.
> Except for removing 9.0 by building 9.4 with 9.2, since 9.0 does not
> build now anyway.
shouldn’t this snippet from 8.10 also work for 9.0?
(modules '((guix build utils)))
(snippet
Am Mon, Apr 17, 2023 at 02:03:14PM -0400 schrieb Maxim Cournoyer:
> I think python is starting to look good here, after a few upgrades.
> It'll cause a rebuild of at least GTK+, so I'll push it a bit later
> today (during the European night).
Nice! I just merged master back, hopefully this is all
Am Mon, Apr 17, 2023 at 07:47:16PM +0200 schrieb Simon Tournier:
> All in all, I am proposing to send a patch for the first path for this
> core-updates cycle and postpone this other path – not doable for this
> cycle; I will resume this story later.
> Andreas, core-updates is frozen but is the for
Hi,
Andreas Enge writes:
> Hello,
>
> just a quick update after a night of building on CI.
> Things look generally quite good on x86_64; some things are being rebuilt
> due to the recent wget update, and that should hopefully also sort out
> i686 rather quickly.
>
> Am Sun, Apr 16, 2023 at 01:09
Hi,
On lun., 17 avril 2023 at 16:12, Lars-Dominik Braun wrote:
> note that the information on haskell.org is not always accurate and thus
> this shorter chain may not actually work. Please give it a try and send
> a patch.
If I read correctly, the current chain is:
7.8.4
->
Hi Simon,
> and instead we could try this shorter one:
>
>7.8.4
> -> 8.0.2 (needs >= 7.10)
> -> 8.4.4 (needs >= 8.0)
> -> 8.8.4 (needs >= 8.4)
> -> 9.2.5 (needs >= 8.6)
>
> WDYT? If no objection, I will give a try.
note that the information on haskell.org is not always accurate and thus
th
On Mon, 17 Apr 2023 at 14:39, Andreas Enge wrote:
>
> Am Mon, Apr 17, 2023 at 02:19:43PM +0200 schrieb Simon Tournier:
> > and instead we could try this shorter one:
> >7.8.4
> > -> 8.0.2 (needs >= 7.10)
>
> Here it looks like we still need 7.10.
Sorry for the typo:
-> 8.0.1 (needs >= 7.8)
Am Mon, Apr 17, 2023 at 11:03:25AM +0200 schrieb Andreas Enge:
> On aarch64 and powerpc, we are still stuck by CI problems.
Things improve! I could reenable sjd-p9 by a little "guix gc". Thanks to
Ricardo for walking me through a few cuirass steps! So we have four more
build slots on powerpc, five
Am Mon, Apr 17, 2023 at 02:19:43PM +0200 schrieb Simon Tournier:
> and instead we could try this shorter one:
>7.8.4
> -> 8.0.2 (needs >= 7.10)
Here it looks like we still need 7.10.
> where ghc-x.y is a full GHC containing the complete testsuite. I
> propose here to replace by ’ghc-x.y/boot
Hi,
On lun., 17 avril 2023 at 11:56, Andreas Enge wrote:
> Am Mon, Apr 17, 2023 at 11:03:25AM +0200 schrieb Andreas Enge:
>> - ghc is taking a long time...
>
> Actually ghc@9.0 fails its tests, which are written in Python (it looks
> like ".abc" needs to be added to collections); but since it is
Am Mon, Apr 17, 2023 at 11:03:25AM +0200 schrieb Andreas Enge:
> - ghc is taking a long time...
Actually ghc@9.0 fails its tests, which are written in Python (it looks
like ".abc" needs to be added to collections); but since it is not needed
for bootstrapping any more, maybe we could drop it?
Wel
Hello,
just a quick update after a night of building on CI.
Things look generally quite good on x86_64; some things are being rebuilt
due to the recent wget update, and that should hopefully also sort out
i686 rather quickly.
Am Sun, Apr 16, 2023 at 01:09:02PM +0200 schrieb Andreas Enge:
> - pyth
Am Mon, Apr 17, 2023 at 08:18:00AM + schrieb Guillaume Le Vaillant:
> I tried to build the 1611 dependents of sbcl on x86-64, and most of them
> build fine. I get only 6 failures, some of them because some
> dependencies like mysql or supercollider are failing to build.
> So overall, Common Lis
Andreas Enge skribis:
> Hello all,
>
> the merge of staging to master, and the subsequent merge of master to
> core-updates did break a few things; but on the positive side, we are
> halfway there with getting rid of the staging and core-updates branches ;-)
> CI has almost c
Hello all,
the merge of staging to master, and the subsequent merge of master to
core-updates did break a few things; but on the positive side, we are
halfway there with getting rid of the staging and core-updates branches ;-)
CI has almost caught up on x86_64; looking at the dashboard at
Am Fri, Apr 14, 2023 at 03:29:01PM -0400 schrieb Maxim Cournoyer:
> The staging branch has been merged to master.
Thanks and congratulations!
> Should we remove the branch from Cuirass and Guix, knowing that teams
> is the way going forward?
Definitely! I will go ahead and do so. If
Hello Maxim,
On Fri, Apr 14, 2023 at 03:29 PM, Maxim Cournoyer wrote:
> Hello,
>
> The staging branch has been merged to master.
>
Nice, thanks!
> Should we remove the branch from Cuirass and Guix, knowing that teams
> is the way going forward?
I also agree with this chang
On Fri, Apr 14, 2023 at 03:29:01PM -0400, Maxim Cournoyer wrote:
> The staging branch has been merged to master.
Thanks!
> Should we remove the branch from Cuirass and Guix, knowing that teams
> is the way going forward?
I am in favor!
Hello,
The staging branch has been merged to master.
Should we remove the branch from Cuirass and Guix, knowing that teams
is the way going forward?
--
Thanks,
Maxim
h a
>> CI evaluation right afterwards?
>
> The second part is automatic right now, ci is configured to build all
> of core-updates.
I concur with Josselin, could you make sure to also merge master into
core-updates?
And could let the CI ends with the last evaluation of staging?
Hi Andreas,
Andreas Enge writes:
> Hello Maxim,
>
> Am Wed, Apr 12, 2023 at 04:38:20PM -0400 schrieb Maxim Cournoyer:
>> I'm planning to merge staging into master soon (tomorrow or friday),
>> unless someone has a problem with it. It includes at least two CVE
>
Hello,
Josselin Poiret writes:
> Hi Maxim,
>
> Maxim Cournoyer writes:
>
>> Hello,
>>
>> I'm planning to merge staging into master soon (tomorrow or friday),
>> unless someone has a problem with it. It includes at least two CVE
>> fixes as well
Am Wed, Apr 12, 2023 at 11:18:26PM +0200 schrieb Josselin Poiret:
> I don't have a particularly strong opinion either way, but if you do
> merge it, could you make sure to also merge master into c-u and launch a
> CI evaluation right afterwards?
The second part is automatic right now, ci is config
Hello Maxim,
Am Wed, Apr 12, 2023 at 04:38:20PM -0400 schrieb Maxim Cournoyer:
> I'm planning to merge staging into master soon (tomorrow or friday),
> unless someone has a problem with it. It includes at least two CVE
> fixes as well as a bunch of updates such as a newer gstreamer
Hi Maxim,
Maxim Cournoyer writes:
> Hello,
>
> I'm planning to merge staging into master soon (tomorrow or friday),
> unless someone has a problem with it. It includes at least two CVE
> fixes as well as a bunch of updates such as a newer gstreamer, ffmpeg,
> qt 5, py
Hello,
I'm planning to merge staging into master soon (tomorrow or friday),
unless someone has a problem with it. It includes at least two CVE
fixes as well as a bunch of updates such as a newer gstreamer, ffmpeg,
qt 5, python-cryptography and a few others, and seems to be close to
mast
s a bit more involved than I'd like.
>
> Okay, so I cherry-picked your staging commits for extra-cmake-modules
> and kcodecs to core-updates, which should bring us further in building KDE
> (once gtk+ is sorted out).
Is gtk+@3 not sorted out? I have it built on my machine. gtk@4
cherry-picked your staging commits for extra-cmake-modules
and kcodecs to core-updates, which should bring us further in building KDE
(once gtk+ is sorted out).
Andreas
hat led me to attempt to upgrade
python-cryptography, which is a bit more involved than I'd like.
As a happy side effect though, I think it'll fix many of the rust
package failures seen on staging that are building on master.
To be continued...
--
Thanks,
Maxim
Hello Maxim,
Am Tue, Mar 28, 2023 at 11:10:01PM -0400 schrieb Maxim Cournoyer:
> It'd be useful if people tested it by reconfiguring their systems with
> it or updating their profiles, and report any issues, as I'd like to
> merge this branch into master in about a week time, if there are no
> blo
Hello Maxim!
Am Wed, Mar 29, 2023 at 08:32:08AM -0400 schrieb Maxim Cournoyer:
> I'll
> gladly volunteer to do the tricky merge after staging is merged into
> master (and removed).
Great, thanks! It should be quite feasible when paying attention to this
special case, but I only di
Hi Andreas!
Andreas Enge writes:
> Hello,
>
> Am Tue, Mar 28, 2023 at 11:10:01PM -0400 schrieb Maxim Cournoyer:
>> I've updated the following dependencies in a group (to try to make
>> things a bit more efficient) on the staging branch; the motivation
>> origina
Am Wed, Mar 29, 2023 at 11:53:22AM +0200 schrieb Andreas Enge:
> The file was removed in commit
> commit 2e7dc813c2b4672f34d135755e928c52c15a1c3a
> Author: Volker Krause
> Date: Sun Feb 19 20:15:29 2023 +0100
> Remove QTextCodec leftovers
> This is all unused internal API now.
> of kcode
Am Wed, Mar 29, 2023 at 11:35:24AM +0200 schrieb Andreas Enge:
> FAIL! : KUsAsciiTextCodecTest::testBrokenBuiltinEncoding() Compared values
> are not the same
>Actual (failConverterState.invalidChars): 1
>Expected (0) : 0
>Loc:
> [/tmp/guix-build-kcodec
Am Wed, Mar 29, 2023 at 11:35:24AM +0200 schrieb Andreas Enge:
> FAIL! : KUsAsciiTextCodecTest::testBrokenBuiltinEncoding() Compared values
> are not the same
We are not the only ones:
https://bugs.gentoo.org/885615
for version 5.99, but there is no patch.
Andreas
Am Tue, Mar 28, 2023 at 11:10:01PM -0400 schrieb Maxim Cournoyer:
> It'd be useful if people tested it by reconfiguring their systems with
> it or updating their profiles, and report any issues
Supposedly the Qt update breaks kcodecs, which in turn breaks most of KDE.
This issue is also present on
Hello,
Am Tue, Mar 28, 2023 at 11:10:01PM -0400 schrieb Maxim Cournoyer:
> I've updated the following dependencies in a group (to try to make
> things a bit more efficient) on the staging branch; the motivation
> originally stemmed from the latest Jami now requiring FFmpeg 6.
that
Hi,
I've updated the following dependencies in a group (to try to make
things a bit more efficient) on the staging branch; the motivation
originally stemmed from the latest Jami now requiring FFmpeg 6.
It'd be useful if people tested it by reconfiguring their systems with
it or upda
Hi,
I'm really interested in Rust 1.60. Is there any progress on merging the
staging branch? I see a lot of commits but I'm not sure whether we come closer
to the merge or drifting away from it.
On Sun, Aug 28, 2022 at 05:56:08PM +0200, Mathieu Othacehe wrote:
>
> Hey Marius,
>
> > The 'staging' branch is in a pretty good shape, let's get it merged!
>
> Nice work!
>
> > I'm fairly rusty when it comes to Cuirass, and don
Hey Marius,
> The 'staging' branch is in a pretty good shape, let's get it merged!
Nice work!
> I'm fairly rusty when it comes to Cuirass, and don't see a button to
> start the jobset here even when authenticated:
>
> https://ci.guix.gnu.org/jobset/
Hi Guix,
The 'staging' branch is in a pretty good shape, let's get it merged!
Highlights from this branch:
* Rust 1.60
* Gstreamer 1.20.3
* Sphinx 5.1.1
* ruby-nokogiri and its dependencies is no longer in the bootstrap path
of TeX Live, so they can be more freely updated o
Hi,
sorry to hijack the thread – I found your post when debugging random
segfaults on the rock64, and just wanted to post a possible solution for
anyone having the same problem.
"pelzflorian (Florian Pelz)" [2022-06-09
19:19:30+0200]:
> (The build of llvm@11 also needed a few retries because gc
On Tue, Jun 14, 2022 at 12:32:13PM +0200, zimoun wrote:
> Hi,
>
> On Mon, 13 Jun 2022 at 09:03, Ludovic Courtès wrote:
>
> > Merged, enjoy! :-)
>
> Cool!
>
>
> > Next up: release and ‘core-updates’.
>
> Do you want to do a ’core-updates’ merge before the release? I think a
> release on Jul
Hi,
On Mon, 13 Jun 2022 at 09:03, Ludovic Courtès wrote:
> Merged, enjoy! :-)
Cool!
> Next up: release and ‘core-updates’.
Do you want to do a ’core-updates’ merge before the release? I think a
release on July would be very welcome. WDYT?
Cheers,
simon
Hello,
Ludovic Courtès writes:
> Hello Guix,
>
> Ludovic Courtès skribis:
>
>> Which means I’ll merge ‘staging’ in ‘master’ tomorrow morning if nothing
>> has collapsed by then. :-)
>
> Merged, enjoy! :-)
Nice!
> Thanks to everyone who helped on the way!
Hello Guix,
Ludovic Courtès skribis:
> Which means I’ll merge ‘staging’ in ‘master’ tomorrow morning if nothing
> has collapsed by then. :-)
Merged, enjoy! :-)
Thanks to everyone who helped on the way!
Next up: release and ‘core-updates’.
Ludo’.
Hi,
Efraim Flashner skribis:
> Let's do it
S… turns out commit e31ab8c24848a7691a838af8df61d3e7097cddbc on
‘master’ unwillingly triggered a rebuild of 2K packages.
It’s too late to revert (they’ve been built anyway), but I’ve merged
‘master’ in ‘staging’ so they can be built there
Hi,
Thiago Jung Bauermann skribis:
> Sorry for the delay. I've built some packages from the staging branch on
> powerpc64le-linux (including Emacs, which brings in a lot of stuff) and
> it seems good.
That’s good news, thanks for testing!
Ludo’.
ay. I've built some packages from the staging branch on
powerpc64le-linux (including Emacs, which brings in a lot of stuff) and
it seems good.
--
Thanks
Thiago
On June 11, 2022 9:53:14 AM UTC, "Ludovic Courtès" wrote:
>Hi,
>
>Efraim Flashner skribis:
>
>> My main concern is that so few of the missing items are queued to be
>> built.
>
>I wonder if that info is accurate.
>
>For instance, https://ci.guix.gnu.org/build/716980/details shows the
>derivati
Ludovic Courtès writes:
> It went from 17.1% to 17.3% in two days, even though the AArch64
> machines have been busy all along it seems. Maybe they’ve been
> processing the backlog that had accumulated on ‘master’ rather than the
> things we care about.
Per https://issues.guix.gnu.org/55848, i
Hi,
Efraim Flashner skribis:
> My main concern is that so few of the missing items are queued to be
> built.
I wonder if that info is accurate.
For instance, https://ci.guix.gnu.org/build/716980/details shows the
derivation for /gnu/store/2smylcjq5cppxcrj2mn229hlmh6bf7w4-libxft-2.3.3.
It is qu
On Thu, Jun 09, 2022 at 09:02:14PM +0200, pelzflorian (Florian Pelz) wrote:
> I will try again with staging at 091eb323ba27. But it will take a
> long time; feel free to proceed regardless.
All my manifest built and runs on rock64 aarch64. Thank you all!
Regards,
Florian
> >> ‘guix weather -s i686-linux’ says 89% (which is underestimated, because
> >> it wrongfully checks for all the packages, including unsupported
> >> packages), which sounds good.
> >>
> >> We have to check for AArch64 & co. Any takers?
> &g
On Thu, Jun 09, 2022 at 09:02:14PM +0200, pelzflorian (Florian Pelz) wrote:
> I will try again with staging at 091eb323ba27.
llvm@11 was built successfully. Sorry for the noise.
Regards,
Florian
On Thu, Jun 09, 2022 at 08:41:21PM +0300, Efraim Flashner wrote:
> I know I've built llvm@11 and mesa on aarch64 hardware for staging.
Oh I see I'm missing the last merge; I'm still at commit b422687cbd.
I will try again with staging at 091eb323ba27. But it will take a
long
On Thu, Jun 09, 2022 at 07:19:30PM +0200, pelzflorian (Florian Pelz) wrote:
> On Mon, Jun 06, 2022 at 11:17:47PM +0200, Ludovic Courtès wrote:
> > We have to check for AArch64 & co. Any takers?
> >
> > Overall it seems to me we should be able to merge ‘staging’ wi
On Mon, Jun 06, 2022 at 11:17:47PM +0200, Ludovic Courtès wrote:
> We have to check for AArch64 & co. Any takers?
>
> Overall it seems to me we should be able to merge ‘staging’ within a
> couple of days. Thoughts?
>
> Ludo’.
>
I mostly succeeded in updating my roc
all the packages, including unsupported
>> packages), which sounds good.
>>
>> We have to check for AArch64 & co. Any takers?
>>
>> Overall it seems to me we should be able to merge ‘staging’ within a
>> couple of days. Thoughts?
>
> Currently ci.guix.gn
good.
>
> We have to check for AArch64 & co. Any takers?
>
> Overall it seems to me we should be able to merge ‘staging’ within a
> couple of days. Thoughts?
Currently ci.guix.gnu.org isn't building any of the aarch64 packages,
and it looks like it hasn't since about
Hi,
Ludovic Courtès skribis:
> Thanks for the heads-up! I think merging ‘staging’ should be
> top-priority. People are welcome to upgrade/reconfigure from it with:
>
> guix time-machine --branch=staging -- …
>
> Remaining things to check:
>
> - [ ] system test
Hi!
Christopher Baines skribis:
> There is starting to be some information in the QA data service instance:
>
>
> https://data.qa.guix.gnu.org/compare-by-datetime/package-derivations?base_branch=master&base_datetime=&target_branch=staging&target_datetime=&sys
Ludovic Courtès writes:
> Hopefully we’ll get a clearer picture in the coming days…
There is starting to be some information in the QA data service instance:
https://data.qa.guix.gnu.org/compare-by-datetime/package-derivations?base_branch=master&base_datetime=&target_bra
tforms and see if I can do something
> about the rust inputs for python-cryptography, to shorten the graph a
> bit and note which crates are "locked" in their current versions.
OK.
>> Besides, since mrustc was updated on ‘staging’, does that new version
>> better support pla
Hi,
zimoun skribis:
> On Sun, 15 May 2022 at 22:55, Ludovic Courtès wrote:
>
>> I propose freezing tomorrow evening, Monday 16th ca. 8PM CEST.
>> How does that sound?
>
> LGTM. The branch is now frozen and receive only fixes, right?
An update: ci.guix wasn’t building much lately due to a bug
Hi,
On Sun, 15 May 2022 at 22:55, Ludovic Courtès wrote:
> I propose freezing tomorrow evening, Monday 16th ca. 8PM CEST.
> How does that sound?
LGTM. The branch is now frozen and receive only fixes, right?
Note the «Aborted» status on <https://ci.guix.gnu.org/jobset/staging&g
for python-cryptography, to shorten the graph a
bit and note which crates are "locked" in their current versions.
> Besides, since mrustc was updated on ‘staging’, does that new version
> better support platforms other than x86_64?
I hear we should be able to do aarch64 with our n
e keep the old 3.3.1 for use on
non-x86_64 platforms? Would that even work?
Besides, since mrustc was updated on ‘staging’, does that new version
better support platforms other than x86_64?
Thanks for the heads-up,
Ludo’.
Hi Guix!
Ludovic Courtès skribis:
> zimoun skribis:
>
>> The schedule could be:
>>
>> + freeze the ’staging’ branch on the Sun May, 8th
>> + fix until it is ready, targeting the Sun, May 22th
>> + prepare a release for June
>
> So now I look ridi
python-cryptography now depends on rust. We're going to need 3.4.8 from
the 3.4 series for the other architectures. Currently
python-cryptography@36.0.1 is gating about 3000 packages.
--
Efraim Flashner אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality
Hi,
On Sun, 08 May 2022 at 00:04, Ludovic Courtès wrote:
> zimoun skribis:
>
>> The schedule could be:
>>
>> + freeze the ’staging’ branch on the Sun May, 8th
>> + fix until it is ready, targeting the Sun, May 22th
>> + prepare a release for June
&g
Hi!
zimoun skribis:
> The schedule could be:
>
> + freeze the ’staging’ branch on the Sun May, 8th
> + fix until it is ready, targeting the Sun, May 22th
> + prepare a release for June
So now I look ridiculous for being derailed myself… But yes, something
like this offset
Hi,
Ludovic Courtès writes:
> Hi!
>
> The ‘staging’ branch is open! Which means that changes with “between
> 300 and 1,800 rebuilds” (info "(guix) Submitting Patches") can go there;
> now’s the time to (re)send package updates in that ballpark.
Just to be c
ded for that.
Cool! I am in for ungrafting things. :-)
> I think we should aim for a freeze in one or two weeks, merging in three
> weeks, and resume work on the new release to be done sometime after the
> merge.
The schedule could be:
+ freeze the ’staging’ branch on the Sun May, 8th
+
Hi!
The ‘staging’ branch is open! Which means that changes with “between
300 and 1,800 rebuilds” (info "(guix) Submitting Patches") can go there;
now’s the time to (re)send package updates in that ballpark.
Incidentally, I was considering ungrafting things on that branch, even
tho
Leo Prikler writes:
> It appears that back in the day they were reverted with
> 918a099e7422fe8ad3464dc5a1b4f60843297742 before a staging merge on
> February 1st. If nothing else happened on staging since, someone will
> need to revert the revert or apply the patches themselv
but these patches are still in 'staging' branch.
>
> Tho these patches will trigger rebuild of almost all qt applications,
> but I think six month is so long, and these patches can also help fix
> some icon issues of qt application. Can someone tell me the status of
> it?
If t
Hello Guix!
In January I'm following up a series of
patches(https://issues.guix.gnu.org/45784) that fixes Qt build
system to honor user's environment variable. It has been six months now,
but these patches are still in 'staging' branch.
Tho these patches will trigger rebu
Hey,
> The network team asks me to test it now. Could you please give it a
> try?
I ran a few tests, it seems to work perfectly! It's really impressive
how Wireguard is easy to set up. I think it deserves a complete Guix
service :).
--8<---cut here---start-
Mathieu Othacehe writes:
>> Yes, this should be okay. Does this mean that we can get rid of all the
>> other ports that we previously requested?
>
> Yes, the SSH tunnels and the associated open ports shouldn't be useful
> anymore, as we'll be able to route all the build nodes traffic through
>
Hello,
> Yes, this should be okay. Does this mean that we can get rid of all the
> other ports that we previously requested?
Yes, the SSH tunnels and the associated open ports shouldn't be useful
anymore, as we'll be able to route all the build nodes traffic through
the VPN.
> If you’re sure
Hi Mathieu,
sorry for missing this message (and all the others).
Leo pointed me to this message on IRC. (Thanks!)
> The easier way to proceed could be to create a VPN for the remote build
> machines that are not on berlin local network. Wireguard could be a good
> candidate. That would mean th
Leo Famulari skribis:
> The staging branch has been merged to master in commit
> 75b775e81b5a81a59656eeba8811b42f45d503da
>
> Hooray!
>
> Thanks to everyone that helped out with bug reports, fixes, CI
> assistance, etc.
Yay! And thank *you* for coordinating this effort a
The staging branch has been merged to master in commit
75b775e81b5a81a59656eeba8811b42f45d503da
Hooray!
Thanks to everyone that helped out with bug reports, fixes, CI
assistance, etc.
There is some discussion about changes to the branch workflow:
https://lists.gnu.org/archive/html/guix-devel
On Mon, Feb 01, 2021 at 08:43:19PM +, Christopher Baines wrote:
> > Efraim Flashner writes:
> >
> >> On Mon, Feb 01, 2021 at 12:14:03PM +0100, Hartmut Goebel wrote:
> >>> Hi,
> >>>
> >>> maybe the process should be the other way
Mark H Weaver writes:
> Efraim Flashner writes:
>
>> On Mon, Feb 01, 2021 at 12:14:03PM +0100, Hartmut Goebel wrote:
>>> Hi,
>>>
>>> maybe the process should be the other way round:
>>>
>>> staging -> "staging-frozen"
Efraim Flashner writes:
> On Mon, Feb 01, 2021 at 12:14:03PM +0100, Hartmut Goebel wrote:
>> Hi,
>>
>> maybe the process should be the other way round:
>>
>> staging -> "staging-frozen" -> master
>> no "staging-next"
>
> I
On Mon, Feb 01, 2021 at 12:14:03PM +0100, Hartmut Goebel wrote:
> Hi,
>
> maybe the process should be the other way round:
>
> staging -> "staging-frozen" -> master
> no "staging-next"
I really like this idea
> This would allow committers to us
Hi,
maybe the process should be the other way round:
staging -> "staging-frozen" -> master
no "staging-next"
This would allow committers to use the same workflow all the time. No
need for any technical solution preventing to push to staging.
--
Regards
Hartmu
sary.
Ah, I see now that 'git push' has the "--no-verify" option, which causes
it to skip the pre-push hook. Sure, that sounds workable.
> Alternatively, one could include some control sequence in the commit
> message. For example,
>
> Allow-Frozen: staging
It&#
he commit
message. For example,
Allow-Frozen: staging
Regards,
Jakub Kądziołka
Leo Famulari writes:
> On Sun, Jan 31, 2021 at 12:26:10AM -0500, Leo Famulari wrote:
>> On Sun, Jan 31, 2021 at 01:06:45AM +0100, Ricardo Wurmus wrote:
>> > I tried to upgrade my i686-linux system to staging. I reconfigured
>> > successfully, but I had to hold
On Sun, Jan 31, 2021 at 12:26:10AM -0500, Leo Famulari wrote:
> On Sun, Jan 31, 2021 at 01:06:45AM +0100, Ricardo Wurmus wrote:
> > I tried to upgrade my i686-linux system to staging. I reconfigured
> > successfully, but I had to hold back a package upgrade that depends on
>
1 - 100 of 455 matches
Mail list logo
