Re: [gentoo-dev] newsitem: openrc-0.28 mounts efivars read only

[Mike Gilbert]

On Wed, Jul 12, 2017 at 5:44 PM, William Hubbs  wrote:
> On Wed, Jul 12, 2017 at 04:03:25PM -0400, Mike Gilbert wrote:
>> On Wed, Jul 12, 2017 at 11:42 AM, William Hubbs  wrote:
>> > OpenRC 0.28 will mount efivars read only by default due to concerns
>> > about users bricking systems by writing to this filesystem unexpectedly.
>> >
>> > Here is the newsitem covering this change.
>> >
>> > William
>> >
>>
>> This will break boot loader installers, like grub-install and bootctl
>> (systemd-boot). Please update any relevant documents on the wiki, or
>> find someone who can do it for you.
>
> I'm not stopping anyone from making those updates, so if someone knows
> what needs to be changed, go for it. :-)
>
> William
>

Give me a few days, and I'll be happy to help with that. I don't have
a lot of free time this week, but I should have some time this
weekend.

Re: [gentoo-dev] newsitem: openrc-0.28 mounts efivars read only

[Lucas Ramage]

I am working on it! Thanks!

On Wed, Jul 12, 2017 at 8:42 PM, Matt Turner  wrote:

> On Wed, Jul 12, 2017 at 5:29 PM, Lucas Ramage 
> wrote:
> > What needs to be changed for the bootloaders? I may be able to assist.
>
> The documentation should be updated to say that with OpenRC 0.28 that
> you'll have to remount efivars as RW before you can install the
> bootloader (e.g., grub-install)
>
> The command I use locally to remount rw (since I have configured
> efivars to be mounted read-only in fstab) is
>
> mount -o remount,rw /sys/firmware/efi/efivars
>
>


-- 

Regards,

[image: View my Portfolio] 

Lucas Ramage / Software Engineer
ramage.luca...@gmail.com / (941)-467-2354

Visit online journal
lramage94.github.io

[image: Google Plus]  [image:
Linkedin] 

Re: [gentoo-dev] newsitem: openrc-0.28 mounts efivars read only

[Matt Turner]

On Wed, Jul 12, 2017 at 5:29 PM, Lucas Ramage  wrote:
> What needs to be changed for the bootloaders? I may be able to assist.

The documentation should be updated to say that with OpenRC 0.28 that
you'll have to remount efivars as RW before you can install the
bootloader (e.g., grub-install)

The command I use locally to remount rw (since I have configured
efivars to be mounted read-only in fstab) is

mount -o remount,rw /sys/firmware/efi/efivars

Re: [gentoo-dev] newsitem: openrc-0.28 mounts efivars read only

[Lucas Ramage]

What needs to be changed for the bootloaders? I may be able to assist.

On Wed, Jul 12, 2017 at 7:04 PM, Matt Turner  wrote:

> On Wed, Jul 12, 2017 at 2:44 PM, William Hubbs 
> wrote:
> > On Wed, Jul 12, 2017 at 04:03:25PM -0400, Mike Gilbert wrote:
> >> On Wed, Jul 12, 2017 at 11:42 AM, William Hubbs 
> wrote:
> >> > OpenRC 0.28 will mount efivars read only by default due to concerns
> >> > about users bricking systems by writing to this filesystem
> unexpectedly.
> >> >
> >> > Here is the newsitem covering this change.
> >> >
> >> > William
> >> >
> >>
> >> This will break boot loader installers, like grub-install and bootctl
> >> (systemd-boot). Please update any relevant documents on the wiki, or
> >> find someone who can do it for you.
> >
> > I'm not stopping anyone from making those updates, so if someone knows
> > what needs to be changed, go for it. :-)
>
> That's now how this works. You can't leave something as crucial as
> boot loader installation documentation in a bad state.
>
> It's your responsibility to ensure that happens.
>
>


-- 

Regards,

[image: View my Portfolio] 

Lucas Ramage / Software Engineer
ramage.luca...@gmail.com / (941)-467-2354

Visit online journal
lramage94.github.io

[image: Google Plus]  [image:
Linkedin] 

Re: [gentoo-dev] newsitem: openrc-0.28 mounts efivars read only

[Matt Turner]

On Wed, Jul 12, 2017 at 2:44 PM, William Hubbs  wrote:
> On Wed, Jul 12, 2017 at 04:03:25PM -0400, Mike Gilbert wrote:
>> On Wed, Jul 12, 2017 at 11:42 AM, William Hubbs  wrote:
>> > OpenRC 0.28 will mount efivars read only by default due to concerns
>> > about users bricking systems by writing to this filesystem unexpectedly.
>> >
>> > Here is the newsitem covering this change.
>> >
>> > William
>> >
>>
>> This will break boot loader installers, like grub-install and bootctl
>> (systemd-boot). Please update any relevant documents on the wiki, or
>> find someone who can do it for you.
>
> I'm not stopping anyone from making those updates, so if someone knows
> what needs to be changed, go for it. :-)

That's now how this works. You can't leave something as crucial as
boot loader installation documentation in a bad state.

It's your responsibility to ensure that happens.

Re: [gentoo-dev] newsitem: openrc-0.28 mounts efivars read only

[William Hubbs]

On Wed, Jul 12, 2017 at 04:03:25PM -0400, Mike Gilbert wrote:
> On Wed, Jul 12, 2017 at 11:42 AM, William Hubbs  wrote:
> > OpenRC 0.28 will mount efivars read only by default due to concerns
> > about users bricking systems by writing to this filesystem unexpectedly.
> >
> > Here is the newsitem covering this change.
> >
> > William
> >
> 
> This will break boot loader installers, like grub-install and bootctl
> (systemd-boot). Please update any relevant documents on the wiki, or
> find someone who can do it for you.

I'm not stopping anyone from making those updates, so if someone knows
what needs to be changed, go for it. :-)

William



signature.asc
Description: Digital signature

Re: [gentoo-dev] newsitem: openrc-0.28 mounts efivars read only

[Mike Gilbert]

On Wed, Jul 12, 2017 at 11:42 AM, William Hubbs  wrote:
> OpenRC 0.28 will mount efivars read only by default due to concerns
> about users bricking systems by writing to this filesystem unexpectedly.
>
> Here is the newsitem covering this change.
>
> William
>

This will break boot loader installers, like grub-install and bootctl
(systemd-boot). Please update any relevant documents on the wiki, or
find someone who can do it for you.

Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

[Pacho Ramos]

El mié, 12-07-2017 a las 12:38 -0400, William L. Thomson Jr. escribió:
> On Wed, 12 Jul 2017 17:23:43 +0100
> "M. J. Everitt"  wrote:
> 
> > On 12/07/17 17:07, Gordon Pettey wrote:
> > > On Wed, Jul 12, 2017 at 10:14 AM, William L. Thomson Jr.
> > > > wrote:
> > > That is my point. That message is always there. The chance that
> > > it is ignored is very high.
> > > 
> > > 
> > > Stop signs on the road are also always there. If you get arrested
> > > for ignoring it, it is not because the stop signs are always there,
> > > it is because you ignored it. Don't ignore the warning.  
> > 
> > Can't help but think of "special snowflake" here 
> 
> More like saying something to me because it is me, despite that I
> literally pointed that out to others. In a situation that actually
> matters. This should be said to others not me. But everyone feels ilke
> they need to comment something to me, that applies to another, but not
> said to that other.
> 
> Again
> https://archives.gentoo.org/gentoo-dev/message/a0470e1cc2c05afc1e30c09f3f239b2
> 4
> 
> Really funny stuff
> 
> --

After re-reading all the thread again:
https://lists.gt.net/gentoo/dev/327773/?page=1;mh=-1;

I think there is no point in continuing replying forever to this thread as I
think all the technical issues has now being, at least, clarified and forwarded
to the right people. As I have understood most of them belong to Portage team
and now that the bug reports with the concrete suggestions were filled, they
will be able to deal with them (either working on implementing the desired
changes or either declining to do that if they have other opinions based on the
way portage is supposed to be used by us). 

Then, can we please switch to different and more productive things to do? :)

Thanks a lot!

Re: [gentoo-dev] libva/libva-intel-driver/libva-utils ebuild relocation

[Daniel Charles]

On Wed, Jul 12, 2017 at 10:15 AM, Michał Górny  wrote:
> On śro, 2017-07-12 at 10:12 -0700, Daniel Charles wrote:
>> Hello gentoo-dev's
>>
>> Checking on how gentoo is locating ebuild for these 3 packages I found
>> that they're using different folders and overriding driver's name
>>
>> x11-libs/libva
>> x11-libs/libva-intel-driver (overriding package name: intel-vaapi-driver)
>> media-video/libva-utils
>>
>> Since the project moved to github.com/01org, could it possible to
>> relocate all the ebuilds starting with version 1.8.x to a common
>> folder?
>>
>> This would be my proposal
>>
>> media-video/libva
>> media-video/intel-vaapi-driver
>> media-video/libva-utils
>>
>> Driver changed package name when transitioning to the new repository
>> and although that is handled in the current ebuild, a new ebuild name
>> might be helpful here.
>>
>> Let me know your thoughts
>>
>
> Please file a bug mentioning all three (current) packages. We'll assign
> it to the right people.

Submitted here: https://bugs.gentoo.org/show_bug.cgi?id=624724

Thanks

-- 
Daniel.
>
> --
> Best regards,
> Michał Górny

Re: [gentoo-dev] libva/libva-intel-driver/libva-utils ebuild relocation

[Michał Górny]

On śro, 2017-07-12 at 10:12 -0700, Daniel Charles wrote:
> Hello gentoo-dev's
> 
> Checking on how gentoo is locating ebuild for these 3 packages I found
> that they're using different folders and overriding driver's name
> 
> x11-libs/libva
> x11-libs/libva-intel-driver (overriding package name: intel-vaapi-driver)
> media-video/libva-utils
> 
> Since the project moved to github.com/01org, could it possible to
> relocate all the ebuilds starting with version 1.8.x to a common
> folder?
> 
> This would be my proposal
> 
> media-video/libva
> media-video/intel-vaapi-driver
> media-video/libva-utils
> 
> Driver changed package name when transitioning to the new repository
> and although that is handled in the current ebuild, a new ebuild name
> might be helpful here.
> 
> Let me know your thoughts
> 

Please file a bug mentioning all three (current) packages. We'll assign
it to the right people.

-- 
Best regards,
Michał Górny


signature.asc
Description: This is a digitally signed message part

[gentoo-dev] libva/libva-intel-driver/libva-utils ebuild relocation

[Daniel Charles]

Hello gentoo-dev's

Checking on how gentoo is locating ebuild for these 3 packages I found
that they're using different folders and overriding driver's name

x11-libs/libva
x11-libs/libva-intel-driver (overriding package name: intel-vaapi-driver)
media-video/libva-utils

Since the project moved to github.com/01org, could it possible to
relocate all the ebuilds starting with version 1.8.x to a common
folder?

This would be my proposal

media-video/libva
media-video/intel-vaapi-driver
media-video/libva-utils

Driver changed package name when transitioning to the new repository
and although that is handled in the current ebuild, a new ebuild name
might be helpful here.

Let me know your thoughts

Thanks.

-- 
Daniel

Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

[William L. Thomson Jr.]

On Wed, 12 Jul 2017 17:23:43 +0100
"M. J. Everitt"  wrote:

> On 12/07/17 17:07, Gordon Pettey wrote:
> > On Wed, Jul 12, 2017 at 10:14 AM, William L. Thomson Jr.
> > > wrote:

> > That is my point. That message is always there. The chance that
> > it is ignored is very high.
> >
> >
> > Stop signs on the road are also always there. If you get arrested
> > for ignoring it, it is not because the stop signs are always there,
> > it is because you ignored it. Don't ignore the warning.  
> Can't help but think of "special snowflake" here 

More like saying something to me because it is me, despite that I
literally pointed that out to others. In a situation that actually
matters. This should be said to others not me. But everyone feels ilke
they need to comment something to me, that applies to another, but not
said to that other.

Again
https://archives.gentoo.org/gentoo-dev/message/a0470e1cc2c05afc1e30c09f3f239b24

Really funny stuff

--
-- 
William L. Thomson Jr.


pgpdqJA9f1X5O.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

[William L. Thomson Jr.]

On Wed, 12 Jul 2017 11:07:00 -0500
Gordon Pettey  wrote:

> On Wed, Jul 12, 2017 at 10:14 AM, William L. Thomson Jr.
>  wrote:
>
> > That is my point. That message is always there. The chance that it
> > is ignored is very high.
> >
> >
> Stop signs on the road are also always there. If you get arrested for
> ignoring it, it is not because the stop signs are always there, it is
> because you ignored it. Don't ignore the warning.

And again another commenting who did not follow the thread. Talking to
the wrong person, replying at the wrong point.

Who is ignoring warnings? Me or others?
https://archives.gentoo.org/gentoo-dev/message/a0470e1cc2c05afc1e30c09f3f239b24

Guess you missed where I was pointing out important warnings others
were ignoring. Much more so than the generic output that is always
present with emerge -C/--unmerge.

Also in what country do you get arrested for running a stop sign?

-- 
William L. Thomson Jr.


pgpL9CyAAquYA.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

[M. J. Everitt]

On 12/07/17 17:07, Gordon Pettey wrote:
> On Wed, Jul 12, 2017 at 10:14 AM, William L. Thomson Jr.
> > wrote:
>
> On Thu, 13 Jul 2017 01:03:00 +1000
> Sam Jorna > wrote:
>
> > $ emerge -C apg
> >  * This action can remove important packages! In order to be safer,
> > use
> >  * `emerge -pv --depclean ` to check for reverse dependencies
> > before
> >  * removing packages.
>
> That is my point. That message is always there. The chance that it is
> ignored is very high.
>
>
> Stop signs on the road are also always there. If you get arrested for
> ignoring it, it is not because the stop signs are always there, it is
> because you ignored it. Don't ignore the warning.
Can't help but think of "special snowflake" here 

*cue flamewar...*


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

[Gordon Pettey]

On Wed, Jul 12, 2017 at 10:14 AM, William L. Thomson Jr. 
wrote:

> On Thu, 13 Jul 2017 01:03:00 +1000
> Sam Jorna  wrote:
>
> > $ emerge -C apg
> >  * This action can remove important packages! In order to be safer,
> > use
> >  * `emerge -pv --depclean ` to check for reverse dependencies
> > before
> >  * removing packages.
>
> That is my point. That message is always there. The chance that it is
> ignored is very high.
>
>
Stop signs on the road are also always there. If you get arrested for
ignoring it, it is not because the stop signs are always there, it is
because you ignored it. Don't ignore the warning.

Re: [gentoo-dev] newsitem: openrc-0.28 mounts efivars read only

[M. J. Everitt]

On 12/07/17 16:42, William Hubbs wrote:
> OpenRC 0.28 will mount efivars read only by default due to concerns
> about users bricking systems by writing to this filesystem unexpectedly.
>
> Here is the newsitem covering this change.
>
> William
>
Very sensible .. I seem to recall something about systemd doing the
reverse by default .. and this becoming a regular occurrence.

+1 for sanity.



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] newsitem: openrc-0.28 mounts efivars read only

[William Hubbs]

OpenRC 0.28 will mount efivars read only by default due to concerns
about users bricking systems by writing to this filesystem unexpectedly.

Here is the newsitem covering this change.

William

Title: Mounting efivars read only
Author: William Hubbs 
Content-Type: text/plain
Posted: 2017-07-15
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: <=sys-apps/openrc-0.28

OpenRC 0.28 mounts efivars read only due to concerns about changes in
this file system making systems unbootable.  If you need to change something
in this path, you will need to re-mount it read-write, make the change
and re-mount it read-only.

Also, you can override this behavior by adding a line for efivars to
fstab if you want efivars mounted read-write.

For more information on this issue, see the following url:

https://github.com/openrc/openrc/issues/134


signature.asc
Description: Digital signature

Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

[Sam Jorna]

On 13/07/17 00:19, William L. Thomson Jr. wrote:
> It is YOUR comments that are funny, and going in a circular argument
> just to be argumentative and bringing nothing useful to the discussion.
> Which should be over now that bugs are filed

I'm not trying to be argumentative or antagonistic, I'm trying to
understand how your replacement warning differs from what's already
available and adds value.

>> '--depclean foo' is the user removing something they /are/ aware of
>> *if it's not a dependency*.
> 
> That does not work the same. It will not remove a package from world.

$ grep apg /var/lib/portage/world
app-admin/apg

$ emerge -C apg
 * This action can remove important packages! In order to be safer, use
 * `emerge -pv --depclean ` to check for reverse dependencies before
 * removing packages.

>>> Unmerging in: 5 4 3 2 1
>>> Unmerging (1 of 1) app-admin/apg-2.3.0b-r5...

...

$ grep apg /var/lib/portage/world
app-admin/apg

$ emerge -c apg

Calculating dependencies... done!
>>> Calculating removal order...

>>> Unmerging in: 5 4 3 2 1
>>> Unmerging (1 of 1) app-admin/apg-2.3.0b-r5...

> Clearly you are having a hard time grasping this very simple concept.
> I am done, reply if you like, but this thread is serious noise now...

Clearly, hence why I was trying to understand what difference your
proposal offered. But since we're moving on to serious things now, I
guess I /am/ done with this thread.

-- 
Sam Jorna (wraeth) 
GnuPG Key: D6180C26



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: taking a break from arches stabilization

[Pacho Ramos]

El mié, 12-07-2017 a las 09:13 -0500, William Hubbs escribió:
> On Wed, Jul 12, 2017 at 02:30:34PM +0200, Kristian Fiskerstrand wrote:
> > On 07/12/2017 01:59 PM, Michael Palimaka wrote:
> > > If it's not a stable candidate then why do you use this as an example
> > > against build testing-based stabilisations? If there are known issues it
> > > should never reach the arch teams in the first place.
> > 
> > This might be the crux of things, as long as automatic stabilization is
> > not triggered by some set of rules (e.g 30 days in ~arch) , and still
> > requires manual trigger by, preferably, the maintainer there is likely
> > no issue.
> 
> This doesn't make sense. If I have to trigger automatic stabilization, it
> isn't automatic any more.
> 
> I think with an appropriate set of rules automatic stabilization would
> be fine. For example:
> 
> - foo-2.0 has been in ~arch for 30 days
> - there are no open bugs against foo-2.0
> - an older version of foo is stable
> - all of the dependencies of foo-2.0 are stable
> 
> If those conditions are met, in theory there shouldn't be any problem
> with stabilizing foo-2.0.
> 
> If foo-2.0 is not a stabilization candidate, there probably should be an
> open bug in bugzilla stating why it isn't.
> 
> Thanks,
> 
> William
> 

Also please note that, when we were filling that automatic bug reports, there
were still an additional 60 days timeout (I think it was 60 days.. but I don't
remember if even 90 days) to allow maintainers to react. Only if nothing was
noted in relevant bug reports, arches were CCed automatically by the script 

Re: [gentoo-dev] taking a break from arches stabilization

[Sergey Popov]

10.07.2017 20:22, Agostino Sarubbo пишет:
> Hi all.
> 
> every time that I attach my tmux session to see what happens on irc, I always 
> see the same discussion about the 'minor' arches status.
> Since I joined gentoo(2011) I worked on all arches except hppa, I put more 
> effort in amd64 and less where I saw other people work on it (arm,alpha)
> But every time the magic phrase is that those arches are unmaintained.
> 
> Now, since I work on these arches just to help, i.e. I don't have any 
> business 
> and I do non have any installation of those arches and the work I'm doing is 
> not appreciated at all I decided to stop for now.
> If your dream is to put sparc and ia64 to ~arch, go ahead, I have no 
> objections.
> I will take a break also from amd64 and x86...let's see how things will 
> change.
> 

It's sad, i wish you will return to this - you are doing great job for
all arches! I know how tedious this work could be - i was active arch
team member some time ago(but not anymore :-().

-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Quality Assurance project lead



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

[William L. Thomson Jr.]

On Wed, 12 Jul 2017 16:40:11 +1000
"Sam Jorna (wraeth)"  wrote:

> If my concern in removing a package was whether it was a dependency,
> it would make more sense to use --depclean in the first place. If I'm
> using --unmerge, it's because I want the package unmerged regardless.

But you can't remember what you installed or ate for dinner. What if you
are removing something you need?

> > Didn't you just say something about meaningful output vs noise?
> > That is always outputted and ends up becoming what you are saying.
> > Funny!  
> >
> And your suggesting adding more noise to it... Funny, I know.

No a warning that mentions the package not being removed is not noise.
It is useful output, like the warnings that exist for other things now.

I guess in your opinion this warning is noise to you.

!!! 'sys-devel/gcc' is part of your system profile.
!!! Unmerging it may be damaging to your system.

It is YOUR comments that are funny, and going in a circular argument
just to be argumentative and bringing nothing useful to the discussion.
Which should be over now that bugs are filed

> > Depclean the user is cleaning things they are not aware of. Unmerge
> > the user is removing something directly. They may think they do not
> > need it.  
> 
> No.
> 
> '--depclean' is the user removing things they are not aware of.

You literally just re-typed what I did above replacing cleaning with
removing. Are you paying any attention?

> '--depclean foo' is the user removing something they /are/ aware of
> *if it's not a dependency*.

That does not work the same. It will not remove a package from world.

> '--unmerge foo' is the user explicitly removing something regardless
> of whether it's a dependency.

BUT they are warned now for things that are in a profile or set. Thus
they should be warned if a dependency. Its simply, but clearly your
having a hard time grasping.

> Therefore, '--depclean foo' can be seen as a safe '--unmerge foo'
> which, from what I understand, is what you're aiming for.

No, as they are not the same. You cannot remember what you ate. Please
stop trying to assume what I am after. Clearly we are very different. I
know what I ate last night...

> That's what the current warning to --unmerge says - removing packages
> can break things, so please make sure this isn't a dependency and you
> really want to remove this.

They do not say anything about dependencies. It says the same message
for everything. In some cases for system and set packages you get a
warning.

> How does replacing one warning with another warning that may or may
> not be meaningful ("maybe it's a dep, maybe it isn't" as opposed to
> "this can be dangerous, please make sure you know what you're doing")
> make it any better?

It is not replacing a warning. It is adding the same warning that exist
in other situations in one it does not exists now, removing
dependencies.

Clearly you are having a hard time grasping this very simple concept.
I am done, reply if you like, but this thread is serious noise now...

-- 
William L. Thomson Jr.


pgpI3YxGNphyg.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: taking a break from arches stabilization

[William Hubbs]

On Wed, Jul 12, 2017 at 02:30:34PM +0200, Kristian Fiskerstrand wrote:
> On 07/12/2017 01:59 PM, Michael Palimaka wrote:
> > If it's not a stable candidate then why do you use this as an example
> > against build testing-based stabilisations? If there are known issues it
> > should never reach the arch teams in the first place.
> 
> This might be the crux of things, as long as automatic stabilization is
> not triggered by some set of rules (e.g 30 days in ~arch) , and still
> requires manual trigger by, preferably, the maintainer there is likely
> no issue.

This doesn't make sense. If I have to trigger automatic stabilization, it
isn't automatic any more.

I think with an appropriate set of rules automatic stabilization would
be fine. For example:

- foo-2.0 has been in ~arch for 30 days
- there are no open bugs against foo-2.0
- an older version of foo is stable
- all of the dependencies of foo-2.0 are stable

If those conditions are met, in theory there shouldn't be any problem
with stabilizing foo-2.0.

If foo-2.0 is not a stabilization candidate, there probably should be an
open bug in bugzilla stating why it isn't.

Thanks,

William



signature.asc
Description: Digital signature

[gentoo-dev] Future of Desktop-effects project

[Sergey Popov]

Hi.

It is sad to say, but i have no time for compiz anymore.
Personally, I do not use it anymore for around six months(i have
migrated from KDE with compiz as WM to pure fluxbox on both of my
workstations).

And, to be honest, there is no progress in desktop-effects overlay
either[1].

As i am the only member of project i suggest this masterplan:

- set timeout for a week from current date(so, deadline would be Jul 19,
2017);
- if any of the developers want to take maintainership - please join the
project
- if no developers will volunteer, but there will be user, who would
like to fix stuff and work with proxy maintainers - please set
maintainership correctly
- after deadline happens and no other of developers join the project, i
will request disbanding it and move all packages, that are still under
project maintenance to maintainer-needed

Not sure what to do with overlay when project will be disbanded though.

Packages, that are maintained by desktop-effects project[2]:

dev-python/compizconfig-python
x11-apps/fusion-icon
x11-libs/compiz-bcop
x11-libs/compizconfig-backend-gconf
x11-libs/compizconfig-backend-kconfig4
x11-libs/libcompizconfig
x11-misc/3dfb
x11-misc/3dfm
x11-misc/ccsm
x11-misc/simple-ccsm
x11-plugins/compiz-plugins-extra
x11-plugins/compiz-plugins-main
x11-plugins/compiz-plugins-unsupported
x11-themes/emerald-themes
x11-wm/compiz
x11-wm/compiz-fusion
x11-wm/emerald

Open bugs on these packages can be seen by this query[3]

[1] - https://gitweb.gentoo.org/proj/desktop-effects.git/
[2] - listed using 'portageq --no-filters
--maintainer-email=desktop-effe...@gentoo.org -n'
[3] -
https://bugs.gentoo.org/buglist.cgi?cmdtype=runnamed_id=3587404=desktop-effects

-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Quality Assurance project lead



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: taking a break from arches stabilization

[Marek Szuba]

On 2017-07-12 00:26, Kristian Fiskerstrand wrote:

>> Question is what's more a problem: Having an outdated stable
>> package because nobody cared about stabilizing a new version (in
>> most cases this will end with a rushed stabilization once a
>> security bug was fixed in the package) or move a package in time
>> from ~ARCH to ARCH and deal with the fallout sometimes.
> Easy, keep the working package any time
Seconded.

That said, let me repeat something I mentioned during the last
discussion about stabilisation procedures: for me at least the problem
with stabilisation has never really been with version upgrades, it's
with packages which do not even have a single stable version. For
reference, as of right now my "version bump" keyword file lists 8 atoms
(half of them referring to GIMP-2.9, which should not be stabilised
anyway) - whereas my "not in stable" file lists 61.

-- 
MS



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: taking a break from arches stabilization

[Kristian Fiskerstrand]

On 07/12/2017 01:59 PM, Michael Palimaka wrote:
> If it's not a stable candidate then why do you use this as an example
> against build testing-based stabilisations? If there are known issues it
> should never reach the arch teams in the first place.

This might be the crux of things, as long as automatic stabilization is
not triggered by some set of rules (e.g 30 days in ~arch) , and still
requires manual trigger by, preferably, the maintainer there is likely
no issue.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: taking a break from arches stabilization

[Michael Palimaka]

On 07/12/2017 07:26 AM, Kristian Fiskerstrand wrote:> That presumes that
the maintainer is the one calling for the
> stabilization, and it is not an automated procedure simply due to 30
> days in ~arch. In this particular case, look for the number of bug
> reports filed in Gentoo for the issue.

All of the past automated stabilisation request initiatives did look for
open bugs against a package before filing any request.

> 
> But the main risk is certainly not built testing, it is breaking
> operational live stable systems.

I'm not sure exactly what you mean by this. Build testing is a process
and not a risk. When ebuilds are moved to stable, there's risk of
breakage at both build time and runtime.

Most runtime issues will either be known by the maintainer (who can then
block the stabilisation) or smoked out during the usual ~arch waiting
period.

Build time issues are more tricky. One of the reasons we have arch
testers is to ensure that something that built fine in ~arch will still
build fine on an otherwise stable system.

I've encountered a number of ebuilds marked stable that failed to build
on an all-stable system but built fine on an all-testing system. I've
never encountered a single ebuild that failed to run correctly on an
all-stable system but ran fine on an all-testing system.

I don't think it's practical to demand detailed runtime testing by an
arch tester for every stabilisation request (which we know doesn't
happen in practice anyway). There's also many packages where it may be
prudent to do more than just build testing.

I think the answer lies somewhere in the middle. We need to recognise
that we have very limited arch testing resources and focus them where it
will have the most impact. We have a "runtime testing required" field on
stable bugs now - let's use it, and let's be smart about it. Looking at
the current open bugs, I see some good examples where runtime testing
was requested (eg. sys-devel/gcc-config) and some examples where I
really question what value we get from an arch tester's time (eg.
app-text/htmldoc).

> Nowhere was it claimed that the arc
> testers are responsible for it, but it certainly doesn't coincide, at
> any point, with "The main risk of breakage of a package moving from
> testing to stable is always at build time anyway."
In a previous post you stated:
> currently gnupg 2.1.21 scdaemon bug will
> happily sign a third party public keyblock's UID using signature subkey
> on smartcard, which results in useless signature that doesn't have any
> effect, but the application builds fine.
>
> This means gnupg 2.1.21 is not a candidate for stabilization, but it
certainly builds fine.

If it's not a stable candidate then why do you use this as an example
against build testing-based stabilisations? If there are known issues it
should never reach the arch teams in the first place.

Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

[Sam Jorna (wraeth)]

On 12/07/17 16:06, William L. Thomson Jr. wrote:
> On Wed, 12 Jul 2017 15:49:14 +1000
> "Sam Jorna (wraeth)"  wrote:
>>
>> I have trouble remembering what I ate for dinner last night, let alone
>> what I may or may not have merged a week, month or year ago, or what
>> options I used when merging it.
> 
> And if you used --oneshot, it is also saying you are not maintaining
> your system or ever running --depclean. Since anything you installed
> via --oneshot would be removed with --depclean.

If my concern in removing a package was whether it was a dependency, it
would make more sense to use --depclean in the first place. If I'm using
--unmerge, it's because I want the package unmerged regardless.

>>> What harm does a warning do?  
>>
>> Depends on the user, which can't really be avoided, but means that
>> warnings should be clear and meaningful, otherwise they become
>> background noise.
> 
> The example in the bug is as clear is it can get.
> 
> !!! 'sys-devel/gcc' is a dependency of another package on your system
> or
> !!! 'sys-devel/gcc' is a package not found in system profile or world
> or
> !!! 'sys-devel/gcc' may not have been installed by you
> or
> some other message
> 
>> Such as:
>>
>> emerge --unmerge dev-python/keyring
>>  * This action can remove important packages! In order to be safer,
>> use
>>  * `emerge -pv --depclean ` to check for reverse dependencies
>> before
>>  * removing packages.
> 
> Didn't you just say something about meaningful output vs noise? That is
> always outputted and ends up becoming what you are saying. Funny!

And your suggesting adding more noise to it... Funny, I know.

 or may have been installed as an orphan but is now a
 dependency.   
>>>
>>> Now being a dependency the warning would be valid.  
>>
>> "Sometimes being accurate" is not the most noble of goals.
> 
> What?
> 
>> So the idea is to duplicate the functionality of '--depclean
>> 
> 
> NO!!!
> 
> emerge --depclean gcc 
> 
> is not the same as 
> 
> emerge --umerge gcc
> 
> Depclean the user is cleaning things they are not aware of. Unmerge the
> user is removing something directly. They may think they do not need it.

No.

'--depclean' is the user removing things they are not aware of.

'--depclean foo' is the user removing something they /are/ aware of *if
it's not a dependency*.

'--unmerge foo' is the user explicitly removing something regardless of
whether it's a dependency.

Therefore, '--depclean foo' can be seen as a safe '--unmerge foo' which,
from what I understand, is what you're aiming for.

>> ' without actually checking to see if the package is a
>> dependency,
> 
> Word it how ever. If the user did not install, they should be warned on
> removal of a package they did not install.

That's what the current warning to --unmerge says - removing packages
can break things, so please make sure this isn't a dependency and you
really want to remove this.

>> only whether it is listed in a set; or to check if it's a
>> dependency of /something/ and, if so, redirect the user to the
>> command they should be using anyway?
> 
> You mean like emerge --unmerge does already that you pointed out
> above. After mentioning useful messages vs noise.  Again funny!

How does replacing one warning with another warning that may or may not
be meaningful ("maybe it's a dep, maybe it isn't" as opposed to "this
can be dangerous, please make sure you know what you're doing") make it
any better?

-- 
Sam Jorna (wraeth)
GnuPG ID: D6180C26



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

[William L. Thomson Jr.]

On Wed, 12 Jul 2017 15:49:14 +1000
"Sam Jorna (wraeth)"  wrote:
>
> I have trouble remembering what I ate for dinner last night, let alone
> what I may or may not have merged a week, month or year ago, or what
> options I used when merging it.

And if you used --oneshot, it is also saying you are not maintaining
your system or ever running --depclean. Since anything you installed
via --oneshot would be removed with --depclean.

> > What harm does a warning do?  
> 
> Depends on the user, which can't really be avoided, but means that
> warnings should be clear and meaningful, otherwise they become
> background noise.

The example in the bug is as clear is it can get.

!!! 'sys-devel/gcc' is a dependency of another package on your system
or
!!! 'sys-devel/gcc' is a package not found in system profile or world
or
!!! 'sys-devel/gcc' may not have been installed by you
or
some other message

> Such as:
> 
> emerge --unmerge dev-python/keyring
>  * This action can remove important packages! In order to be safer,
> use
>  * `emerge -pv --depclean ` to check for reverse dependencies
> before
>  * removing packages.

Didn't you just say something about meaningful output vs noise? That is
always outputted and ends up becoming what you are saying. Funny!
 
> >> or may have been installed as an orphan but is now a
> >> dependency.   
> > 
> > Now being a dependency the warning would be valid.  
> 
> "Sometimes being accurate" is not the most noble of goals.

What?

> So the idea is to duplicate the functionality of '--depclean
> 

NO!!!

emerge --depclean gcc 

is not the same as 

emerge --umerge gcc

Depclean the user is cleaning things they are not aware of. Unmerge the
user is removing something directly. They may think they do not need it.

>' without actually checking to see if the package is a
> dependency,

Word it how ever. If the user did not install, they should be warned on
removal of a package they did not install.

> only whether it is listed in a set; or to check if it's a
> dependency of /something/ and, if so, redirect the user to the
> command they should be using anyway?

You mean like emerge --unmerge does already that you pointed out
above. After mentioning useful messages vs noise.  Again funny!

-- 
William L. Thomson Jr.


pgpQjPL9OBJa_.pgp
Description: OpenPGP digital signature