Wolfgang Rosenauer wrote:

Am 13.12.2016 um 14:03 schrieb Ludwig Nussel:

...

So for the Leap 42 line that means 42.3 based on SLE12 SP3. In anticipation of that OBS already has openSUSE:Leap:42.3 set up as copy of 42.2. It already accepts submissions. Right now mostly to directly integrate 42.2 maintenance updates.

it feels like I'm asking similar questions with every Leap release but somehow as it's only done once a year so I tend to forget ;-)

That's fine, hits me too :-) Some things change over time so it never hurts to ask.

I found https://en.opensuse.org/openSUSE:How_to_contribute_to_Leap but I miss a bit more information there how the development cycle of a Leap version works. E.g. a list like: - all maintenance updates for Leap version-1 are automatically pushed (over the full cycle)

Yes. Until 42.3 itself gets frozen and flagged as maintained distribution.

- all SLE12SPx updates are automatically pushed (over the full cycle)

Yes.

- all packages which came from Factory originally and build against the new Leap project will get updates to current Factory versions

Packages that were already in 42.1 or 42.2 and came from Factory there are not automatically updated. Ie 42.3 started with a mapping that specifies that all packages track maintenance updates from 42.2 resp SLE. Package maintainers have to manually submit an update from Factory to flip the origin to the Factory version.

submitted for review to the packager; only actively accepted reviews will be submitted to Leap

Yes. In general submit requests to leap have to be approved by the package maintainer(s). Package maintainer information is taken from Factory.

- over the full time active submissions from Factory to Leap will be accepted if the package builds and was not coming from SLE12 before; in case a package should be switched from SLE12 to Factory there should be a review process and an argument about that fact

Yes. A bot keeps a watch on attempts to change the origin of packages. The "leap-reviewers" group gets added as reviewer to approve such requests.

- packages which were forked from SLE12 _and_ Factory because of certain reasons should be reviewed if they can possibly be upstreamed back to SLE12 of Factory

Yes.

- new packages in SLE12 or Factory should be reviewed for inclusion into Leap

Yes. Right now new packages are not automatically submitted to 42.3. For Factory we used to do this in batch rounds later in the development process. I'm not sure if there's any reason that would prevent us from doing that right away though.

Please note that the above are just the points which came to my mind. They are not ordered nor complete and probably not even how it works actually. That's why I would like to have such a list consolidated into a wiki page so developers/packagers have a better idea what happens by the process or what needs manual actions. I also think that people have written small tools to create lists and submissions. It would be very nice if we could collect them also in a list so they can be reused easily.

The scripts and bots I know of are maintained in https://github.com/openSUSE/osc-plugin-factory

Therefore please give some feedback if something like the above already exists or if it would be useful if it doesn't.

It is useful. Feel free to extend the cited wiki page with information you miss. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Wolfgang Rosenauer wrote:

Am 09.01.2017 um 13:30 schrieb Ludwig Nussel:

...

It is useful. Feel free to extend the cited wiki page with information you miss.

thanks for the feedback so far.

I have no created https://en.opensuse.org/openSUSE:Leap_development_process

Ludwig, if you could review it once again and probably be a bit more specific what really is happening as part of the process aka what can be relied on?

Thanks! I changed some wordings a bit.

Since it makes a big difference if there a an automatic submission round for Factory updates or if maintainers have to keep in mind for themselves so submit everything desired for Leap.

The tool that does the submission would not submit anything if the package fails to build. So package maintainers cannot rely on automatic forwarding from Factory to Leap in every case. Someone has to double check. What we can guarantee is that maintainers are kept in the loop for approval if an automatic submission happens. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, 2017-01-09 at 15:48 +0100, Manfred Hollstein wrote:

Moin,

On Tue, 13 Dec 2016, 14:03:12 +0100, Ludwig Nussel wrote:

...

Hi,

42.2 is out of the door, time to relax and wait for the Christmas holidays, right? Well, far from that. We have to prepare for the next release.

thinking of 42.2, which caused some heavy thoughts about most of the systems I care about, makes me raising some questions:

1. Gnome Keyring stopped dealing with GPG keys in 42.2;

This is a good thing. Gnome Keyring's implementation of the gpg agent protocol has been heavily broken for years, breaking all but the most basic gpg2 usage. See e.g. https://wiki.gnupg.org/GnomeKeyring.

as a result    users of Thunderbird+Enigmail, Mutt+gpg-extensions etc. are driving    nuts due to repeatedly typing in their passphrase every once in    a while. This could be overcome (== worked-around) by using the    former GNOME Keyring version 3.16.0 (see also boo#1012371).

I can't quite follow. Enigmail can cache passwords for a configurable amount of idle time. mutt+gpg should be able to use regular gpg-agent, no? Regards Martin

2. What is the alternative suggested to that change in 42.2?    A newer version of pinentry was mentioned in GNOME Keyring's    changelog, but it appears that none of the versions available for    Leap 42.2 actually *fix* the problem.

This is a significant issue to all of the users of Leap 42.2 I'm taking care of here, so, with respect to a similar situation we had, when 42.1 had been released (boo#953100), I'm asking to take care of such user visible changes. What will be the suggested/recommended way to get GNOME and GPG happy with each other?

TIA, cheers.

l8er manfred

-- Dr. Martin Wilck <mwilck@suse.com>, Tel. +49 (0)911 74053 2107 SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 2017-04-04 a las 18:07 +0200, Manfred Hollstein escribió:

Moin,

...

I don't actually have a problem with mutt+gpg; the first trouble for non-experienced users arises when they get asked for the GPG passphrase (they didn't get asked before when gnome-keyring still worked). Worse is that the standard configuration doesn't seem to actually work (at least not for me):

gpg2-2.0.24-5.5.x86_64 enigmail-1.9.5-1.4.x86_64 MozillaThunderbird-45.8.0-39.1.x86_64

(if I'm not mistaken, these are the current versions on openSUSE Leap 42.2). Whenever a Thunderbird user clicks on a GPG encrypted or signed message, it results in message popup from Enigmail describing an error in the communication between GnuPG and gpg-agent. IIRC, long ago I had a similar problem on TW, but there we switched to gpg2-2.1 at some time, which is when the problem went away.

Yes, it happens on Gnome and XFCE, because there is no agent (mentioned on the release notes). I had to install it and make sure it starts. Or disable the agent in the gnu gpg config file. It works OK with both Pine and Thunderbird, on leap 42.2 - -- Cheers Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAljj2GwACgkQja8UbcUWM1wtdAD/X0pZtEtyF2ObEb0guTav2Yqf 2pn9ZLvAAtoSNBFxC7oA/A1VIdvSAvztt+U3U46UGP3VCoFJMiSkr6FOfChXnOym =h87x -----END PGP SIGNATURE-----

04.04.2017 20:49, Manfred Hollstein пишет:

If the "agent" is disabled, you have to type your passphrase every once in a while (in Thunderbird+enigmail), right?

Have you tried increasing max-cache-ttl and default-cache-ttl?

On 04/04/17 02:25 PM, Andrei Borzenkov wrote:

04.04.2017 20:49, Manfred Hollstein пишет:

...

If the "agent" is disabled, you have to type your passphrase every once in a while (in Thunderbird+enigmail), right?

Have you tried increasing max-cache-ttl and default-cache-ttl?

Yes. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 2017-01-09 15:48, Manfred Hollstein wrote:

thinking of 42.2, which caused some heavy thoughts about most of the systems I care about, makes me raising some questions:

1. Gnome Keyring stopped dealing with GPG keys in 42.2; as a result users of Thunderbird+Enigmail, Mutt+gpg-extensions etc. are driving nuts due to repeatedly typing in their passphrase every once in a while. This could be overcome (== worked-around) by using the former GNOME Keyring version 3.16.0 (see also boo#1012371).

2. What is the alternative suggested to that change in 42.2? A newer version of pinentry was mentioned in GNOME Keyring's changelog, but it appears that none of the versions available for Leap 42.2 actually *fix* the problem.

I'm using a workaround on XFCE, which uses the gnome stack for many things. The trick is using the standard gpg agent instead. On one computer I had to create a new user and compare the resulting working setup, then repair the main user, on another computer it worked out of the box. I assume that what I use should also work on Gnome. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)