Re: Release v1.4?

[Efraim Flashner]

On Wed, Jun 22, 2022 at 03:31:34PM +0200, Ludovic Courtès wrote:
> Hi,
> 
> Brian Cully  skribis:
> 
> > Ludovic Courtès  writes:
> >
> >> So plain ‘emacs’ package doesn’t work on Wayland?  That sounds like
> >> a
> >> recipe for a poor user experience, no?
> >
> > The mainline Emacs is not Wayland-native, but it (along with just
> > about everything else) will run fine under XWayland. It's how I've
> > been running it for some time now. The user experience is almost
> > indistinguishable from either the ‘pgtk’ branch or the mainline,
> > X-only branch.
> >
> >> (FWIW folks like me who use exwm, ratpoison, or one of these geeky
> >> tiling window managers probably can’t switch.)
> >
> > This is correct, but I don't see why this should prevent Guix offering
> > the option for Wayland-based compositors/window-managers out of the
> > box as all it does is offer more options for users.
> 
> Sure.
> 
> > Unless I'm misunderstanding something, I don't believe that setting
> > the ‘wayland’ flag to #t in gdm-configuration causes Wayland to be
> > used for your desktop environment, it merely *allows* it to be
> > selected from the greeter. When logging in you can select from Gnome
> > under X, Gnome under Wayland, or other window managers you may have
> > installed under either environment. Without that flag only the X11
> > window managers will be selectable.
> 
> OK, I wasn’t aware of that; if setting ‘wayland?’ to #t is this smooth
> and basically indistinguishable for those who want to stick with X, then
> I guess we should enable it.
> 
> I’m still unsure whether doing is before the release is reasonable,
> given how much we have on our plate.
> 
> Thanks,
> Ludo’.

I think the only real question is what shows up first by default in a
fresh install. I believe by default SDDM will show the window manager
that was last used by default.

My current OS config, when I spin it up in a VM, lists
enlightenment/wayland before enlightenment/X11. I didn't test with
gnome.

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Re: Release v1.4?

[Ludovic Courtès]

Hi,

Brian Cully  skribis:

> Ludovic Courtès  writes:
>
>> So plain ‘emacs’ package doesn’t work on Wayland?  That sounds like
>> a
>> recipe for a poor user experience, no?
>
> The mainline Emacs is not Wayland-native, but it (along with just
> about everything else) will run fine under XWayland. It's how I've
> been running it for some time now. The user experience is almost
> indistinguishable from either the ‘pgtk’ branch or the mainline,
> X-only branch.
>
>> (FWIW folks like me who use exwm, ratpoison, or one of these geeky
>> tiling window managers probably can’t switch.)
>
> This is correct, but I don't see why this should prevent Guix offering
> the option for Wayland-based compositors/window-managers out of the
> box as all it does is offer more options for users.

Sure.

> Unless I'm misunderstanding something, I don't believe that setting
> the ‘wayland’ flag to #t in gdm-configuration causes Wayland to be
> used for your desktop environment, it merely *allows* it to be
> selected from the greeter. When logging in you can select from Gnome
> under X, Gnome under Wayland, or other window managers you may have
> installed under either environment. Without that flag only the X11
> window managers will be selectable.

OK, I wasn’t aware of that; if setting ‘wayland?’ to #t is this smooth
and basically indistinguishable for those who want to stick with X, then
I guess we should enable it.

I’m still unsure whether doing is before the release is reasonable,
given how much we have on our plate.

Thanks,
Ludo’.

Re: Release v1.4?

[Philip McGrath]

On Fri, Jun 17, 2022, at 11:37 AM, Brian Cully via Development of GNU Guix and 
the GNU System distribution. wrote:
> Ludovic Courtès  writes:
>
>> So plain ‘emacs’ package doesn’t work on Wayland?  That sounds 
>> like a
>> recipe for a poor user experience, no?
>
> The mainline Emacs is not Wayland-native, but it (along with just 
> about everything else) will run fine under XWayland. It's how I've 
> been running it for some time now. The user experience is almost 
> indistinguishable from either the ‘pgtk’ branch or the mainline, 
> X-only branch.
>

I'm on a foreign distro, but FWIW I've been using plain Emacs 27 with the KDE 
Plasma Wayland session on HiDPI displays for over a year, and I have no 
complaints. In fact, I didn't even realize Emacs wasn't Wayland-native until 
this thread. I took a look just now at the 'emacs-next-pgtk' package in Guix: 
it does look a bit nicer in a side-by-side comparison, but it's subtle. Either 
way, mostly Emacs just looks like Emacs. So I don't think Emacs should be a 
blocker for enabling Wayland by default.

-Philip

Further thoughts on Xorg "vs" Wayland etc -- was: Re: Release v1.4?

[bokr]

Hi brian, et al,

On +2022-06-17 11:37:18 -0400, Brian Cully via Development of GNU Guix and the 
GNU System distribution. wrote:
> 
> Ludovic Courtès  writes:
> 
> > So plain ‘emacs’ package doesn’t work on Wayland?  That sounds like a
> > recipe for a poor user experience, no?
> 
> The mainline Emacs is not Wayland-native, but it (along with just about
> everything else) will run fine under XWayland. It's how I've been running it
> for some time now. The user experience is almost indistinguishable from
> either the ‘pgtk’ branch or the mainline, X-only branch.
>

Yes, and NB:  Xwayland does not shut out native wayland.

It may even share more nicely than that, depending on system.
On my old Puri.sm Librem13v4 PureOS/amber-variant-of-debian system...
---cut here---start->8---
# $ uname -rv
4.19.0-19-amd64 #1 SMP Debian 4.19.232-1 (2022-03-07)
---cut here---end--->8---
...I can switch back and forth between Xwayland that does
all the stuff that needs X or Xorg (gnome and browsers, and Audacity
and all that) and my hacky experiments with bypassing X and
talking to the compositor in C.

The compositor happily places my pixel buffers on the screen together with
firefox or texworks or whatever else is running, so there is not necessarily
a Wayland "vs" Xorg conflict. YMMV I would guess, but works for me :)

This seems to me like it demonstrates an opportunity to encourage developers
to get their feet wet with X-server-indepedent apps. (That doesn't mean
giving up all the graphics and font software that paints pixels into buffers --
it "just" factors out the buffer compositing)

My system also permits switching to a framebuffer ( /dev/fb0 ) tty3 based
environemt, while leaving the gnome gui stuff running.
Ctl-Alt-F3 gets me a console login prompt. Ctl-Alt-F2 switches me back,
whether I logged out of the console shell or not.

If you are a member of the video group, you can read and write the
frame buffer as a 1920x1080x4 byte mmap whose address you can get
with an ioctl. Other geometries are of course possble. 

I wrote some C to poke character cells from the kernel sun12x22 font.
Long time ago. I have been meaning to port my pixelpoking to wayland,
and have wip stuff, which I will share at some point :)

The reason I was in frame buffer mode today was the gnome side got
total locked, so I thought I could Ctl-Alt-F3 and kill off stuck bits.
Which I did -- killed the whole GUI side, in the end. An alernative
to rescue/maintenace mode, before going there, IOW.

But since I was there in console fb mode, I wanted to check that
my old font demo worked. It did :)

BUT: Fn Prt Sc had no hook like in gnome, so I wanted to save the
display. Guess what you can do?

To make a screenshot:
xz -kzc /dev/fb0 > some_xzss_name.xz
To display such a screen-shot:
xz -dc some_xzss_name.xz > /dev/fb0

This works fast, and the compression is better than the .png files from
gnome's screenshots. Of course this doess not coordinate with anything else
that may be painting the screen, so it will get mixed with updates in sometimes
curious ways, since the compositor avoids update screen areas it thinks haven't
changed. If you poke pixels there, they'll stay until the compositor gets 
someting
new for that area,

I'll try to attach one I made. It shows all the kernel sun12x22.c characters
with bounding boxes in red and hex index numbers at the array edges.

Maybe this dual fb0 and Xwayland capabilty could help someone?
You get it all "for free" with some systems, and it doesn't demand anything.

There is tricky stuff going on though. So no warranties
from me on any of this info :)


> > (FWIW folks like me who use exwm, ratpoison, or one of these geeky
> > tiling window managers probably can’t switch.)
>

I don't know how much work, but I would guess they can be made
to work alongside wayland, if not using wayland to best advanage.

Best would be to wean emacs of X, IWT.

Otherwise they can probably play nicely on the same back end,
not sharing screen space maybe, but flipping between with some key hit.

A quick check on if you have drm-driven displays:

---cut here---start->8---
# $ head /sys/class/drm/*/status
==> /sys/class/drm/card0-DP-1/status <==
disconnected

==> /sys/class/drm/card0-eDP-1/status <==
connected

==> /sys/class/drm/card0-HDMI-A-1/status <==
disconnected
---cut here---end--->8---

BTW, if you want to hack native wayland, I recommend [0]
to start with. The examples mostly worked for me.

but so much is developing so fast that things
like using anonymous files and mmap-ing them to pass
to wayland as private buffers may show up only
while your're looking for something else on stackoverflow
or wikipedia or reddit or ... you may miss it.

[0] https://wayland-book.com/introduction.html

Sorry to interpose so much, the context for "this" (I think) was:

--8<---cut here-

Re: Release v1.4?

[Development of GNU Guix and the GNU System distribution.]

Ludovic Courtès  writes:

So plain ‘emacs’ package doesn’t work on Wayland?  That sounds 
like a

recipe for a poor user experience, no?


The mainline Emacs is not Wayland-native, but it (along with just 
about everything else) will run fine under XWayland. It's how I've 
been running it for some time now. The user experience is almost 
indistinguishable from either the ‘pgtk’ branch or the mainline, 
X-only branch.


(FWIW folks like me who use exwm, ratpoison, or one of these 
geeky

tiling window managers probably can’t switch.)


This is correct, but I don't see why this should prevent Guix 
offering the option for Wayland-based compositors/window-managers 
out of the box as all it does is offer more options for users.


I have no objection to defaulting to Wayland, but my gut feeling 
is that
we have enough on our plate for 1.4 already, so I’d rather delay 
that

post-release.


Unless I'm misunderstanding something, I don't believe that 
setting the ‘wayland’ flag to #t in gdm-configuration causes 
Wayland to be used for your desktop environment, it merely 
*allows* it to be selected from the greeter. When logging in you 
can select from Gnome under X, Gnome under Wayland, or other 
window managers you may have installed under either 
environment. Without that flag only the X11 window managers will 
be selectable.


-bjc

Re: Release v1.4?

[Josselin Poiret]

Hello,

Ludovic Courtès  writes:
> So plain ‘emacs’ package doesn’t work on Wayland?  That sounds like a
> recipe for a poor user experience, no?

It does, but only through XWayland which is not ideal, and doesn't look
as good as Emacs on native X or emacs-pgtk on Wayland (font rendering in
XWayland isn't as good as either of those).

> (FWIW folks like me who use exwm, ratpoison, or one of these geeky
> tiling window managers probably can’t switch.)

Maybe someone would love to write ewwm? :p

> Yeah, understood.  (I think we should have a section in the manual
> documenting, with actual examples, how to set up Wayland!)
>
> Surely there’s a geek audience who expects Wayland, and another geek
> audience who needs X for their tools; in between, there’s probably a lot
> of people who’s fine either way.

What I was advocating was only to change GDM's default mode to Wayland,
not force everyone to use a Wayland compositor!  The reason is that GDM
running in X mode will not pick up Wayland sessions, whereas GDM running
in Wayland mode will happily list and launch both types.  Also, note
that X software can run on Wayland through XWayland, which is part of
the official xorg project and works quite well, minus some small
wrinkles such as the one noted above.

> I have no objection to defaulting to Wayland, but my gut feeling is that
> we have enough on our plate for 1.4 already, so I’d rather delay that
> post-release.
>
> WDYT?

Seems ok to me, since in any case most people trying out Guix in a VM
will `guix pull` before `guix reconfigure`'ing, as long as we do that at
some point it will work OOTB for them.  We can postpone all of this for
after the release.

Best,
-- 
Josselin Poiret

Re: Release v1.4?

[Ludovic Courtès]

Hi,

Josselin Poiret  skribis:

> I'm not sure, it does seem like a fraction of people use it on IRC but
> then again it's more likely that Wayland users would talk about it, X
> being the default.  If there are no outstanding bugs with Wayland Gnome
> though, I think it'd be a better choice: no tearing in the default
> configuration, and better designed.  GUI Toolkits seem to have adapted
> pretty well, and we still have XWayland for the rest.  The most glaring
> non-Wayland app would be Emacs, but emacs-next-pgtk is fully
> Wayland-native.

So plain ‘emacs’ package doesn’t work on Wayland?  That sounds like a
recipe for a poor user experience, no?

(FWIW folks like me who use exwm, ratpoison, or one of these geeky
tiling window managers probably can’t switch.)

> For me the #1 reason though is onboarding experience: take a user of
> another distro that uses their favorite Wayland compositor, and wants to
> try out Guix.  They install it through the Guix installer, and don't
> understand (yet) how to read the whole documentation and write their own
> config file fully.  They add sway to their system packages, reconfigure,
> but next reboot GDM doesn't show Sway in the available sessions; they then
> decide it's not worth their time and go back to their old distro.  This
> default change would make sure that it Just Works Out of The Box™ on
> first install.

Yeah, understood.  (I think we should have a section in the manual
documenting, with actual examples, how to set up Wayland!)

Surely there’s a geek audience who expects Wayland, and another geek
audience who needs X for their tools; in between, there’s probably a lot
of people who’s fine either way.

I have no objection to defaulting to Wayland, but my gut feeling is that
we have enough on our plate for 1.4 already, so I’d rather delay that
post-release.

WDYT?

Ludo’.

Re: Release v1.4?

[Josselin Poiret]

Hello,

Ludovic Courtès  writes:
>> * switching gdm-configuration-wayland? to #t, so that the OOB experience
>> with Wayland sessions is better.
>
> Perhaps I’m biased because I use Xorg, but I wonder how good a default
> that is?  To put it differently, what fraction of the user base uses
> Wayland?

I'm not sure, it does seem like a fraction of people use it on IRC but
then again it's more likely that Wayland users would talk about it, X
being the default.  If there are no outstanding bugs with Wayland Gnome
though, I think it'd be a better choice: no tearing in the default
configuration, and better designed.  GUI Toolkits seem to have adapted
pretty well, and we still have XWayland for the rest.  The most glaring
non-Wayland app would be Emacs, but emacs-next-pgtk is fully
Wayland-native.

For me the #1 reason though is onboarding experience: take a user of
another distro that uses their favorite Wayland compositor, and wants to
try out Guix.  They install it through the Guix installer, and don't
understand (yet) how to read the whole documentation and write their own
config file fully.  They add sway to their system packages, reconfigure,
but next reboot GDM doesn't show Sway in the available sessions; they then
decide it's not worth their time and go back to their old distro.  This
default change would make sure that it Just Works Out of The Box™ on
first install.

For the other deprecation changes, I agree, let's just wait a bit longer.

Best,
-- 
Josselin Poiret

Re: Release v1.4?

[Gábor Boskovits]

Hello,

Ludovic Courtès  ezt írta (időpont: 2022. jún. 15., Sze
11:12):

> Hello!
>
> Josselin Poiret  skribis:
>
> > Should we also make use of the point release to remove some deprecated
> > things/switch some defaults?  I'm thinking of:
> > * removing the swap-devices deprecation warning and compatibility code;
> > * removing the bootloader-configuration-target warning and compatibility
> > code;
>
> I don’t think we can do that because there hasn’t been any new release
> in the meantime, unfortunately.  Better wait for a few months after 1.4.
>
> > * switching gdm-configuration-wayland? to #t, so that the OOB experience
> > with Wayland sessions is better.
>
> Perhaps I’m biased because I use Xorg, but I wonder how good a default
> that is?  To put it differently, what fraction of the user base uses
> Wayland?
>

Do you think we can use download statistics to estimate this?
>

Regards,
g_bor

>
> Thanks,
> Ludo’.
>
>

Re: Release v1.4?

[Ludovic Courtès]

Hello!

Josselin Poiret  skribis:

> Should we also make use of the point release to remove some deprecated
> things/switch some defaults?  I'm thinking of:
> * removing the swap-devices deprecation warning and compatibility code;
> * removing the bootloader-configuration-target warning and compatibility
> code;

I don’t think we can do that because there hasn’t been any new release
in the meantime, unfortunately.  Better wait for a few months after 1.4.

> * switching gdm-configuration-wayland? to #t, so that the OOB experience
> with Wayland sessions is better.

Perhaps I’m biased because I use Xorg, but I wonder how good a default
that is?  To put it differently, what fraction of the user base uses
Wayland?

Thanks,
Ludo’.

Re: Release v1.4?

[Josselin Poiret]

Hello everyone,

Ludovic Courtès  writes:

> Thanks for the heads-up!  I think merging ‘staging’ should be
> top-priority.  People are welcome to upgrade/reconfigure from it with:

I'm currently running on staging with no bugs to report (x86_64-linux)!

Should we also make use of the point release to remove some deprecated
things/switch some defaults?  I'm thinking of:
* removing the swap-devices deprecation warning and compatibility code;
* removing the bootloader-configuration-target warning and compatibility
code;
* switching gdm-configuration-wayland? to #t, so that the OOB experience
with Wayland sessions is better.

All of those have roughly been in Guix for ~6 months, so it would seem
fair to me to move on.  There may be many other deprecations that we
could remove, but those are the ones I'm aware of, feel free to add your
own :)

I have patches for the 3 above, if we agree to move on with this (with a
NEWS entry for the third).

WDYT?
-- 
Josselin Poiret

Re: Release v1.4?

[Maxim Cournoyer]

Hello,

vi...@riseup.net writes:

> On 2022-06-06 01:57, zimoun wrote:
>> Hi,
>> 
>> On Fri, 03 Jun 2022 at 18:41, Ludovic Courtès  wrote:
>> 
>>>   guix time-machine --branch=staging -- …
>>>
>>> Remaining things to check:
>>>
>>>   - [ ] system tests
>>>   - [ ] status on non-x86_64 architectures
>> 
>> I agree.  To me, it is part of the same effort.  From my point of view,
>> we missed the window for releasing at the previous core-updates merge.
>> I would like to avoid to miss it. :-)
>> 
>> Somehow, we all have various constraints on our agenda so if we do not
>> set some deadlines in advance, it is hard to free some slots compared to
>> the continuous other “urgent” tasks from elsewhere.
>> 
>> My email is a call (July is a proposal) for synchronizing our agenda and
>> agree on some deadlines and make them happen.
>> 
>> 
>> Cheers,
>> simon
>
> can i help with the system tests?
>
> how do i do those?

You can run them locally with 'make check-system' (beware: some are
expensive).

Thanks!

Maxim

Re: Release v1.4?

[vidak]

On 2022-06-06 01:57, zimoun wrote:
> Hi,
> 
> On Fri, 03 Jun 2022 at 18:41, Ludovic Courtès  wrote:
> 
>>   guix time-machine --branch=staging -- …
>>
>> Remaining things to check:
>>
>>   - [ ] system tests
>>   - [ ] status on non-x86_64 architectures
> 
> I agree.  To me, it is part of the same effort.  From my point of view,
> we missed the window for releasing at the previous core-updates merge.
> I would like to avoid to miss it. :-)
> 
> Somehow, we all have various constraints on our agenda so if we do not
> set some deadlines in advance, it is hard to free some slots compared to
> the continuous other “urgent” tasks from elsewhere.
> 
> My email is a call (July is a proposal) for synchronizing our agenda and
> agree on some deadlines and make them happen.
> 
> 
> Cheers,
> simon

can i help with the system tests?

how do i do those?

~vidak

Re: Release v1.4?

[zimoun]

Hi,

On Fri, 03 Jun 2022 at 18:41, Ludovic Courtès  wrote:

>   guix time-machine --branch=staging -- …
>
> Remaining things to check:
>
>   - [ ] system tests
>   - [ ] status on non-x86_64 architectures

I agree.  To me, it is part of the same effort.  From my point of view,
we missed the window for releasing at the previous core-updates merge.
I would like to avoid to miss it. :-)

Somehow, we all have various constraints on our agenda so if we do not
set some deadlines in advance, it is hard to free some slots compared to
the continuous other “urgent” tasks from elsewhere.

My email is a call (July is a proposal) for synchronizing our agenda and
agree on some deadlines and make them happen.


Cheers,
simon

Re: Release v1.4?

[Ludovic Courtès]

Hello!

zimoun  skribis:

> Schedule a release is the occasion to tackle some not-so-fun tasks as
> merging the ’staging’ branch [1], many upgrades as Haskell [2] or Julia,
> etc.

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 tests
  - [ ] status on non-x86_64 architectures

Ludo’.

Re: Release v1.4 (or 2.0): process and schedule ?

[Ludovic Courtès]

Hello!

For the record, I created a few days ago an issue to keep track of
progress towards the release by blocking it with issues that we think
must be fixed before we release:

  https://issues.guix.gnu.org/53214

Click on “Details” to see the blocking issues.

Hopefully it’ll allow everyone of us to better understand what remains
to be done and to add (and remove!) blockers.

Ludo’.

Re: Release v1.4 (or 2.0): process and schedule ?

[Maxim Cournoyer]

Hi Chris,

Chris Marusich  writes:

[...]

> With Ludo's feedback, I was able to fix 52940 without rebuilding the
> world in commit 195bb1fb9d55d8e5187d669c63a3cde747fc5f64 on master.  Can
> you try merging master into your version-1.4.0 branch?

Awesome!  As you may have noticed, today version-1.4.0 was merged back
into master.

> At this point in time, I'm unaware of any issues that would be
> show-stoppers for for powerpc64le-linux.  As a reminder, issues
> important to powerpc64le-linux can be seen by searching for issues
> tagged with the "guix" user's powerpc64le-linux Debbugs usertag:
>
> https://debbugs.gnu.org/cgi-bin/pkgreport.cgi?tag=powerpc64le-linux;users=guix
>
> I'll keep my eye out for other potential powerpc64le-linux issues and
> see what I can do to help in the days/weeks to come.

Thanks for keeping these powerpc64le issues in check!

Cheers,

Maxim

Re: Release v1.4 (or 2.0): process and schedule ?

[Vagrant Cascadian]

On 2021-12-26, Maxim Cournoyer wrote:
> Vagrant Cascadian  writes:
>> On 2021-12-19, Maxim Cournoyer wrote:
>>> zimoun  writes:
 Now core-updates-frozen is merged.  Now The Big Change [1 ]is done.  Do
 we go for v1.4 or v2.0?
...
>> Would it be appropriate to fix the ~700 low-hanbging fruit issues that
>> are identified by:
>>
>>   guix lint --checkers=description,synopsis
>>
>> It is not the most exciting work technically, but it is relatively easy,
>> and low risk, maybe the worst it does is put a bit more work on
>> translators...
>>
>> Maybe there are also other low hanging fruit guix lint knows about that
>> would not be particularly disruptive?
>>
>> It is not particularly urgent for a release, per se, but I suspect it
>> will just grow and grow without some sort of cycle to address such
>> trivial issues... and doing such cleanup before making a release would
>> aim for a higher standard of craftspersonship. :)
>
> About the current status, I'm nearing on pushing a version-1.4.0 branch
> which is based on master with a few more (core-ish) updates.  There's
> still a few days ahead of that, so if you manage to get many of this
> kind of problems fixed & merged in master they can easily be included in
> the next release.

I managed to get ~150 fixes in before version-1.4.0 was merged...


Wondering if it would be possible to also merge or cherry-pick:

  757a7978dd3de98d5bb033d27fd5a613038b4dc5
  gnu: trytond-*: Fix grammar.

  3c43f2b4f54dead73ce19427eb1e364581b7f2e0
  gnu: julia-bioalignments: Fix spelling.

That would fix a few more of these sorts of issues, and only affects
synopsis and description strings in small ways.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Release v1.4 (or 2.0): process and schedule ?

[Chris Marusich]

Hi Maxim,

Maxim Cournoyer  writes:

> Hello Chris,
>
> Chris Marusich  writes:
>
>> Maxim Cournoyer  writes:
>>
>>> About the current status, I'm nearing on pushing a version-1.4.0 branch
>>> which is based on master with a few more (core-ish) updates.  There's
>>> still a few days ahead of that, so if you manage to get many of this
>>> kind of problems fixed & merged in master they can easily be included in
>>> the next release.
>>
>> There is a problem that currently prevents "guix pull" from succeeding
>> for powerpc64le-linux on master.  I'd like to resolve it before the
>> release if possible.  The problem is here, including a patch to fix it:
>>
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=52940
>>
>> [...]
>
> Since the version-1.4.0 branch I've been polishing locally still hasn't
> been published nor built, there's still time to apply the patch without
> any consideration for world rebuilds to that branch (at this point we
> want the changes to be low risk ones though, but that sounds like one).

With Ludo's feedback, I was able to fix 52940 without rebuilding the
world in commit 195bb1fb9d55d8e5187d669c63a3cde747fc5f64 on master.  Can
you try merging master into your version-1.4.0 branch?

At this point in time, I'm unaware of any issues that would be
show-stoppers for for powerpc64le-linux.  As a reminder, issues
important to powerpc64le-linux can be seen by searching for issues
tagged with the "guix" user's powerpc64le-linux Debbugs usertag:

https://debbugs.gnu.org/cgi-bin/pkgreport.cgi?tag=powerpc64le-linux;users=guix

I'll keep my eye out for other potential powerpc64le-linux issues and
see what I can do to help in the days/weeks to come.

Now that the "guix" package is building successfully again on master, I
can finally build up-to-date versions of cuirass and
guix-build-coordinator.  Although it isn't directly related to the
release, I think I will resume my efforts to add a new powerpc64le-linux
node to the build farm.

-- 
Chris

PGP: https://savannah.gnu.org/people/viewgpg.php?user_id=106836


signature.asc
Description: PGP signature

Re: Release v1.4 (or 2.0): process and schedule ?

[Maxim Cournoyer]

Hello Chris,

Chris Marusich  writes:

> Maxim Cournoyer  writes:
>
>> About the current status, I'm nearing on pushing a version-1.4.0 branch
>> which is based on master with a few more (core-ish) updates.  There's
>> still a few days ahead of that, so if you manage to get many of this
>> kind of problems fixed & merged in master they can easily be included in
>> the next release.
>
> There is a problem that currently prevents "guix pull" from succeeding
> for powerpc64le-linux on master.  I'd like to resolve it before the
> release if possible.  The problem is here, including a patch to fix it:
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=52940
>
> This patch is relatively simple, but it will rebuild many packages for
> all architectures because it modifies guix/build/gremlin.scm, which is
> used by the gnu-build-system.  How can I integrate this change into the
> 1.4.0 release?
>
> Normally I would commit such a change to core-updates.  However, if I do
> that, then the change probably won't make it into master or the
> version-1.4.0 branch in time.  Is there an opportunity to put the change
> somewhere so that it will make it into the release?  I'm not sure.
>
> Here's my proposal.  Since the bug may very well be benign, I could
> apply a simple work-around to master that just skips the failing test on
> powerpc64le-linux.  I could then apply the actual fix to core-updates.
> Later, after master has been merged to core-updates, I could re-enable
> the test on core-updates.  This would allow "guix pull" to succeed for
> powerpc64le-linux on master without rebuilding the world, and the
> correct fix would still be applied on core-updates for a later release.
>
> Do you think that would work?

Since the version-1.4.0 branch I've been polishing locally still hasn't
been published nor built, there's still time to apply the patch without
any consideration for world rebuilds to that branch (at this point we
want the changes to be low risk ones though, but that sounds like one).

Thanks,

Maxim

Re: Release v1.4 (or 2.0): process and schedule ?

[Chris Marusich]

Maxim Cournoyer  writes:

> About the current status, I'm nearing on pushing a version-1.4.0 branch
> which is based on master with a few more (core-ish) updates.  There's
> still a few days ahead of that, so if you manage to get many of this
> kind of problems fixed & merged in master they can easily be included in
> the next release.

There is a problem that currently prevents "guix pull" from succeeding
for powerpc64le-linux on master.  I'd like to resolve it before the
release if possible.  The problem is here, including a patch to fix it:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=52940

This patch is relatively simple, but it will rebuild many packages for
all architectures because it modifies guix/build/gremlin.scm, which is
used by the gnu-build-system.  How can I integrate this change into the
1.4.0 release?

Normally I would commit such a change to core-updates.  However, if I do
that, then the change probably won't make it into master or the
version-1.4.0 branch in time.  Is there an opportunity to put the change
somewhere so that it will make it into the release?  I'm not sure.

Here's my proposal.  Since the bug may very well be benign, I could
apply a simple work-around to master that just skips the failing test on
powerpc64le-linux.  I could then apply the actual fix to core-updates.
Later, after master has been merged to core-updates, I could re-enable
the test on core-updates.  This would allow "guix pull" to succeed for
powerpc64le-linux on master without rebuilding the world, and the
correct fix would still be applied on core-updates for a later release.

Do you think that would work?

-- 
Chris

PGP: https://savannah.gnu.org/people/viewgpg.php?user_id=106836


signature.asc
Description: PGP signature

Re: Release v1.4 (or 2.0): process and schedule ?

[Maxim Cournoyer]

Hello,

Ludovic Courtès  writes:

> Hello!
>
> Maxim Cournoyer  skribis:
>
>> About the current status, I'm nearing on pushing a version-1.4.0 branch
>> which is based on master with a few more (core-ish) updates.  There's
>> still a few days ahead of that, so if you manage to get many of this
>> kind of problems fixed & merged in master they can easily be included in
>> the next release.
>
> Before the first RC, I’d like to push the latest ‘guix style’ changes:
> .
>
> Do we enter string freeze before the first RC?  I forgot how we did it
> last time.

I remember the string freeze was a bit early last time, given the
release also took time to be polished and shipped, but I think it also
was useful.  Integrating translation changes should occur not too late
as they can introduce build issues that need to be resolved, blocking a
release.

Thank you,

Maxim

Re: Release v1.4 (or 2.0): process and schedule ?

[Vagrant Cascadian]

On 2022-01-03, Ludovic Courtès wrote:
> Vagrant Cascadian  skribis:
>> On 2021-12-21, Vagrant Cascadian wrote:
>
> [...]
>
>>> Would it be appropriate to fix the ~700 low-hanbging fruit issues that
>>> are identified by:
>>>
>>>   guix lint --checkers=description,synopsis
>
> [...]
>
>> Could guix style be adapted to apply some of these changes? Some of them
>> are simple things like trailing whitespace, for example.
>
> Trailing whitespace in synopses and descriptions?  It sure could do
> that¹.  Even non-ambiguous issues like “This packages” I guess?
...
> ¹  brings “styling rules”; we could
>   add styling rules for such things.

I also suspect that a majority of the problems I recently fixed were
introduced by using importers; could guix style and/or guix lint be
integrated with the importers too?


live well,
  vagrant

Re: Release v1.4 (or 2.0): process and schedule ?

[Ludovic Courtès]

Hello!

Maxim Cournoyer  skribis:

> About the current status, I'm nearing on pushing a version-1.4.0 branch
> which is based on master with a few more (core-ish) updates.  There's
> still a few days ahead of that, so if you manage to get many of this
> kind of problems fixed & merged in master they can easily be included in
> the next release.

Before the first RC, I’d like to push the latest ‘guix style’ changes:
.

Do we enter string freeze before the first RC?  I forgot how we did it
last time.

Thanks,
Ludo’.

Re: Release v1.4 (or 2.0): process and schedule ?

[Ludovic Courtès]

Hello!

Vagrant Cascadian  skribis:

> On 2021-12-21, Vagrant Cascadian wrote:

[...]

>> Would it be appropriate to fix the ~700 low-hanbging fruit issues that
>> are identified by:
>>
>>   guix lint --checkers=description,synopsis

[...]

> Could guix style be adapted to apply some of these changes? Some of them
> are simple things like trailing whitespace, for example.

Trailing whitespace in synopses and descriptions?  It sure could do
that¹.  Even non-ambiguous issues like “This packages” I guess?

Thanks,
Ludo’.

¹  brings “styling rules”; we could
  add styling rules for such things.

Re: Release v1.4 (or 2.0): process and schedule ?

[Maxim Cournoyer]

Hi Vagrant,

Vagrant Cascadian  writes:

> On 2021-12-19, Maxim Cournoyer wrote:
>> zimoun  writes:
>>> Now core-updates-frozen is merged.  Now The Big Change [1 ]is done.  Do
>>> we go for v1.4 or v2.0?
>>
>> As I've mentioned previously, I'd go for a 1.4.0 release, since overall
>> we've refined and improved (greatly!) what we already had rather than
>> introduced something revolutionary.  I'd keep a 2.0.0 for when we have
>> p2p distributed substitutes, a custom graphical tool and/or integration
>> with the 'Software' application in GNOME, this kind of big user-facing
>> changes.  But that's just my personal opinion :-).  If the majority
>> feels a 2.0.0 is more suitable, I won't mind.
>>
>>> In both case, what is the target for a release date?  I propose January
>>> 31rst.  WDYT?
>>
>> I'd like to fix #52051 before issuing the first release candidate (RC).
>> Assuming this can be made before the end of January with the first RC
>> coming out around New Year, and that the kind of collaboration I've seen
>> in the last weeks continues at the same intensity, this seems
>> achievable.
>
> Would it be appropriate to fix the ~700 low-hanbging fruit issues that
> are identified by:
>
>   guix lint --checkers=description,synopsis
>
> It is not the most exciting work technically, but it is relatively easy,
> and low risk, maybe the worst it does is put a bit more work on
> translators...
>
> Maybe there are also other low hanging fruit guix lint knows about that
> would not be particularly disruptive?
>
> It is not particularly urgent for a release, per se, but I suspect it
> will just grow and grow without some sort of cycle to address such
> trivial issues... and doing such cleanup before making a release would
> aim for a higher standard of craftspersonship. :)

About the current status, I'm nearing on pushing a version-1.4.0 branch
which is based on master with a few more (core-ish) updates.  There's
still a few days ahead of that, so if you manage to get many of this
kind of problems fixed & merged in master they can easily be included in
the next release.

HTH,

Maxim

Re: Release v1.4 (or 2.0): process and schedule ?

[Vagrant Cascadian]

On 2021-12-21, Vagrant Cascadian wrote:
> On 2021-12-19, Maxim Cournoyer wrote:
>> zimoun  writes:
>>> In both case, what is the target for a release date?  I propose January
>>> 31rst.  WDYT?
>>
>> I'd like to fix #52051 before issuing the first release candidate (RC).
>> Assuming this can be made before the end of January with the first RC
>> coming out around New Year, and that the kind of collaboration I've seen
>> in the last weeks continues at the same intensity, this seems
>> achievable.
>
> Would it be appropriate to fix the ~700 low-hanbging fruit issues that
> are identified by:
>
>   guix lint --checkers=description,synopsis
>
> It is not the most exciting work technically, but it is relatively easy,
> and low risk, maybe the worst it does is put a bit more work on
> translators...
>
> Maybe there are also other low hanging fruit guix lint knows about that
> would not be particularly disruptive?
>
> It is not particularly urgent for a release, per se, but I suspect it
> will just grow and grow without some sort of cycle to address such
> trivial issues... and doing such cleanup before making a release would
> aim for a higher standard of craftspersonship. :)
>
>
> I can maybe try to help stir up a coordinated effort, if folks are
> interested in pursuing this line of thinking!

Could guix style be adapted to apply some of these changes? Some of them
are simple things like trailing whitespace, for example.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Release v1.4 (or 2.0): process and schedule ?

[Vagrant Cascadian]

On 2021-12-19, Maxim Cournoyer wrote:
> zimoun  writes:
>> Now core-updates-frozen is merged.  Now The Big Change [1 ]is done.  Do
>> we go for v1.4 or v2.0?
>
> As I've mentioned previously, I'd go for a 1.4.0 release, since overall
> we've refined and improved (greatly!) what we already had rather than
> introduced something revolutionary.  I'd keep a 2.0.0 for when we have
> p2p distributed substitutes, a custom graphical tool and/or integration
> with the 'Software' application in GNOME, this kind of big user-facing
> changes.  But that's just my personal opinion :-).  If the majority
> feels a 2.0.0 is more suitable, I won't mind.
>
>> In both case, what is the target for a release date?  I propose January
>> 31rst.  WDYT?
>
> I'd like to fix #52051 before issuing the first release candidate (RC).
> Assuming this can be made before the end of January with the first RC
> coming out around New Year, and that the kind of collaboration I've seen
> in the last weeks continues at the same intensity, this seems
> achievable.

Would it be appropriate to fix the ~700 low-hanbging fruit issues that
are identified by:

  guix lint --checkers=description,synopsis

It is not the most exciting work technically, but it is relatively easy,
and low risk, maybe the worst it does is put a bit more work on
translators...

Maybe there are also other low hanging fruit guix lint knows about that
would not be particularly disruptive?

It is not particularly urgent for a release, per se, but I suspect it
will just grow and grow without some sort of cycle to address such
trivial issues... and doing such cleanup before making a release would
aim for a higher standard of craftspersonship. :)


I can maybe try to help stir up a coordinated effort, if folks are
interested in pursuing this line of thinking!


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Release v1.4 (or 2.0): process and schedule ?

[zimoun]

Hi,

On Mon, 20 Dec 2021 at 22:24, Ludovic Courtès  wrote:

> Same here.  But first it’d be nice to come up with a summary of what we
> did in ‘core-updates’ because I think we’ve all forgotten most of it.
> :-)

A summary as a ChangeLog or a summary as a blog post? :-)


Cheers,
simon

Re: Release v1.4 (or 2.0): process and schedule ?

[Ludovic Courtès]

Hi,

zimoun  skribis:

> On Sun, 19 Dec 2021 at 21:12, Maxim Cournoyer  
> wrote:
>> zimoun  writes:
>
>>> Now core-updates-frozen is merged.  Now The Big Change [1 ]is done.  Do
>>> we go for v1.4 or v2.0?
>>
>> As I've mentioned previously, I'd go for a 1.4.0 release, since overall
>> we've refined and improved (greatly!) what we already had rather than
>> introduced something revolutionary.  I'd keep a 2.0.0 for when we have
>> p2p distributed substitutes, a custom graphical tool and/or integration
>> with the 'Software' application in GNOME, this kind of big user-facing
>> changes.  But that's just my personal opinion :-).  If the majority
>> feels a 2.0.0 is more suitable, I won't mind.
>
> I do not have a strong opinion either.

Same here.  But first it’d be nice to come up with a summary of what we
did in ‘core-updates’ because I think we’ve all forgotten most of it.
:-)

[...]

>>> In both case, what is the target for a release date?  I propose January
>>> 31rst.  WDYT?
>>
>> I'd like to fix #52051 before issuing the first release candidate (RC).
>> Assuming this can be made before the end of January with the first RC
>> coming out around New Year, and that the kind of collaboration I've seen
>> in the last weeks continues at the same intensity, this seems
>> achievable.
>
> To me,
>
>  - adapt the importers with the new style is also a thing
>  - various guix home minor fixes discussed [1] by Xinglu, Andrew and
>Ludo, a blog post would be neat too. :-)

Agreed on all this.

I’d also like to see if we can avoid the two-step “make release” process
by updating the ‘guix’ package once only.

And also see if we can arrange for ‘guix system init’ to hard-link files
instead of copying them during the normal installation process
(currently it copies files from /tmp to /gnu on the installation media).

Probably at some point we should open a bug for the release and mark
other items as blockers, like we did for the previous release.  One of
us could then keep track of things and send weekly updates, say (it’s
best if it’s someone not too deeply involved with the actual release
hacks!).

Ludo’.

Re: Release v1.4 (or 2.0): process and schedule ?

[Bengt Richter]

Hi all,

On +2021-12-19 21:12:36 -0500, Maxim Cournoyer wrote:
> Hi Simon,
> 
> zimoun  writes:
> 
> > Hi,
> >
> > Now core-updates-frozen is merged.  Now The Big Change [1 ]is done.  Do
> > we go for v1.4 or v2.0?
> 
> As I've mentioned previously, I'd go for a 1.4.0 release, since overall
> we've refined and improved (greatly!) what we already had rather than
> introduced something revolutionary.  I'd keep a 2.0.0 for when we have
> p2p distributed substitutes, a custom graphical tool and/or integration
> with the 'Software' application in GNOME, this kind of big user-facing
> changes.  But that's just my personal opinion :-).  If the majority
> feels a 2.0.0 is more suitable, I won't mind.
> 
> > In both case, what is the target for a release date?  I propose January
> > 31rst.  WDYT?
> 
> I'd like to fix #52051 before issuing the first release candidate (RC).
> Assuming this can be made before the end of January with the first RC
> coming out around New Year, and that the kind of collaboration I've seen
> in the last weeks continues at the same intensity, this seems
> achievable.
> 
> [...]
> 
> >> The lesson of v1.0.1 [#,@] is: please help in testing the
> >> installer. :-)
> 
> Yes, I also feel we should give the installer a lot of testing; it seems
> many people have had issues with it, especially when dealing with newer
> EFI machines.  Unfortunately I don't have such a machine available for
> testing myself...
>

This seems, IIUC, like a FLOSS way to deliver multiple versions of guix
in the form of a collection of bootable ISOs in a single bootable image
for easy trial on various systems.
WDYT?

[0] https://www.theregister.com/2021/12/10/friday_foss_fest/?td=keepreading-btm
[1] git clone 'https://github.com/ventoy/Ventoy.git'

> >> How does it sound?
> >>
> >> Last, Guix is a “rolling-release“, so what does it mean ‘release’? :-)
> >> The main argument for releasing, IMHO, is communication and so attract
> >> potential new users. :-)
> 
> To me, it's a milestone that can be communicated and provides a more
> thoroughly tested (in theory) Guix installation image.
>
> Thanks for helping shape the release plan,
> 
> Maxim
> 
-- 
Regards,
Bengt Richter

Re: Release v1.4 (or 2.0): process and schedule ?

[zimoun]

On Mon, 20 Dec 2021 at 10:04, zimoun  wrote:

>> I'd like to fix #52051 before issuing the first release candidate (RC).
>> Assuming this can be made before the end of January with the first RC
>> coming out around New Year, and that the kind of collaboration I've seen
>> in the last weeks continues at the same intensity, this seems
>> achievable.

>  - adapt the importers with the new style is also a thing
>  - various guix home minor fixes discussed [1] by Xinglu, Andrew and
>Ludo, a blog post would be neat too. :-)

Also this:

   http://issues.guix.gnu.org/issue/51319

Cheers,
simon

Re: Release v1.4 (or 2.0): process and schedule ?

[zimoun]

Hi Maxim,

On Sun, 19 Dec 2021 at 21:12, Maxim Cournoyer  wrote:
> zimoun  writes:

>> Now core-updates-frozen is merged.  Now The Big Change [1 ]is done.  Do
>> we go for v1.4 or v2.0?
>
> As I've mentioned previously, I'd go for a 1.4.0 release, since overall
> we've refined and improved (greatly!) what we already had rather than
> introduced something revolutionary.  I'd keep a 2.0.0 for when we have
> p2p distributed substitutes, a custom graphical tool and/or integration
> with the 'Software' application in GNOME, this kind of big user-facing
> changes.  But that's just my personal opinion :-).  If the majority
> feels a 2.0.0 is more suitable, I won't mind.

I do not have a strong opinion either.  On the other hand, all the
changes are incremental over a relatively large period of time, other
said, each change is not revolutionary but all in all, they can be
considered as.  The revolution of the Sun is made by 365 small changes
and each day compared one by one looks really similar – aside climate
change or tropical/equatorial latitude – and at the end, seasons appear.

Anyway, I won’t mind equally. :-)


>> In both case, what is the target for a release date?  I propose January
>> 31rst.  WDYT?
>
> I'd like to fix #52051 before issuing the first release candidate (RC).
> Assuming this can be made before the end of January with the first RC
> coming out around New Year, and that the kind of collaboration I've seen
> in the last weeks continues at the same intensity, this seems
> achievable.

To me,

 - adapt the importers with the new style is also a thing
 - various guix home minor fixes discussed [1] by Xinglu, Andrew and
   Ludo, a blog post would be neat too. :-)


1: 



Cheers,
simon

Re: Release v1.4 (or 2.0): process and schedule ?

[raingloom]

On Sun, 19 Dec 2021 21:12:36 -0500
Maxim Cournoyer  wrote:

> Hi Simon,
> 
> zimoun  writes:
> 
> > Hi,
> >
> > Now core-updates-frozen is merged.  Now The Big Change [1 ]is done.
> >  Do we go for v1.4 or v2.0?  
> 
> As I've mentioned previously, I'd go for a 1.4.0 release, since
> overall we've refined and improved (greatly!) what we already had
> rather than introduced something revolutionary.  I'd keep a 2.0.0 for
> when we have p2p distributed substitutes, a custom graphical tool
> and/or integration with the 'Software' application in GNOME, this
> kind of big user-facing changes.  But that's just my personal opinion
> :-).  If the majority feels a 2.0.0 is more suitable, I won't mind.

Agreed, if we go by something like semver.

Re: Release v1.4 (or 2.0): process and schedule ?

[Maxim Cournoyer]

Hi Simon,

zimoun  writes:

> Hi,
>
> Now core-updates-frozen is merged.  Now The Big Change [1 ]is done.  Do
> we go for v1.4 or v2.0?

As I've mentioned previously, I'd go for a 1.4.0 release, since overall
we've refined and improved (greatly!) what we already had rather than
introduced something revolutionary.  I'd keep a 2.0.0 for when we have
p2p distributed substitutes, a custom graphical tool and/or integration
with the 'Software' application in GNOME, this kind of big user-facing
changes.  But that's just my personal opinion :-).  If the majority
feels a 2.0.0 is more suitable, I won't mind.

> In both case, what is the target for a release date?  I propose January
> 31rst.  WDYT?

I'd like to fix #52051 before issuing the first release candidate (RC).
Assuming this can be made before the end of January with the first RC
coming out around New Year, and that the kind of collaboration I've seen
in the last weeks continues at the same intensity, this seems
achievable.

[...]

>> The lesson of v1.0.1 [#,@] is: please help in testing the
>> installer. :-)

Yes, I also feel we should give the installer a lot of testing; it seems
many people have had issues with it, especially when dealing with newer
EFI machines.  Unfortunately I don't have such a machine available for
testing myself...

>> How does it sound?
>>
>> Last, Guix is a “rolling-release“, so what does it mean ‘release’? :-)
>> The main argument for releasing, IMHO, is communication and so attract
>> potential new users. :-)

To me, it's a milestone that can be communicated and provides a more
thoroughly tested (in theory) Guix installation image.

Thanks for helping shape the release plan,

Maxim