Re: [gentoo-dev] News Item: GnuCash 2.7+ Breaking Change

2018-01-16 Thread Róbert Čerňanský
On Tue, 16 Jan 2018 22:19:15 +
"M. J. Everitt" <m.j.ever...@iee.org> wrote:

> On 16/01/18 21:56, Róbert Čerňanský wrote:
> > On Tue, 16 Jan 2018 15:58:11 +0100
> > Kristian Fiskerstrand <k...@gentoo.org> wrote:
> >  
> >> On 01/16/2018 03:45 PM, Aaron W. Swenson wrote:  
> >>> Given the situation, we have a choice: Remove GnuCash altogether,
> >>> or press ahead with recommending a version upstream considers
> >>> unstable.
> >> Or 3, discuss with upstream to see if they can release an updated
> >> version as stable branch.  
> > 4. Mask the vulnerable webkit-gtk.  This way: A. User is informed.
> > B. Manual action is required to continue using such package.
> >
> > I see this as the most obvious choice considering that I am still
> > unable to find any possible attack vector against GnuCash.  If it
> > is me and only me who enters data.  Webkit reports are generated
> > from those data.  How can anyone hack me through GnuCash?
> >
> > In general, many times users use applications in a way that
> > vulnerabilities does not apply to their use cases.  I would prefer
> > to be informed and allowed to continue using such application as a
> > part of the distro.
> >
> > Robert
> >
> >  
> Forgive my potential misunderstanding here .. but who's actively
> preventing you from using GnuCash 2.6? You can take a copy locally to
> /usr/local/portage so that When/If finally it gets removed from the
> central package 'tree' it will run for you provided its requirements
> are still met on your system ...

That's correct, nobody is preventing me and I already have copies of
several packages.  But with each additional package Gentoo becomes less
and less valuable.  You can say the same thing about every package.  But
what would be the point of linux distribution then?

I worked with assumption that there is a motivation in Gentoo to provide
a value in a form of stable GnuCash and I merely presented a way which I
see as most pragmatic.  It allows to continue to provide that value and
raises awarenes about webkit-gtk security vulnerabilities.

Of course there is also a possibility that maintainters may have lost
interest/motivation to maintain old webkit-gtk.  Which would be normal
and prefectly fine but completelly different matter than security.

Robert


-- 
Róbert Čerňanský
E-mail: ope...@tightmail.com
Jabber: h...@jabber.sk



Re: [gentoo-dev] News Item: GnuCash 2.7+ Breaking Change

2018-01-16 Thread Róbert Čerňanský
On Tue, 16 Jan 2018 15:58:11 +0100
Kristian Fiskerstrand <k...@gentoo.org> wrote:

> On 01/16/2018 03:45 PM, Aaron W. Swenson wrote:
> > Given the situation, we have a choice: Remove GnuCash altogether, or
> > press ahead with recommending a version upstream considers
> > unstable.  
> 
> Or 3, discuss with upstream to see if they can release an updated
> version as stable branch.

4. Mask the vulnerable webkit-gtk.  This way: A. User is informed.
B. Manual action is required to continue using such package.

I see this as the most obvious choice considering that I am still
unable to find any possible attack vector against GnuCash.  If it is me
and only me who enters data.  Webkit reports are generated from those
data.  How can anyone hack me through GnuCash?

In general, many times users use applications in a way that
vulnerabilities does not apply to their use cases.  I would prefer to
be informed and allowed to continue using such application as a part of
the distro.

Robert


-- 
Róbert Čerňanský
E-mail: ope...@tightmail.com
Jabber: h...@jabber.sk



Re: [gentoo-dev] News Item: GnuCash 2.7+ Breaking Change

2018-01-16 Thread Róbert Čerňanský
On Wed, 10 Jan 2018 22:46:04 +0200
Mart Raudsepp <l...@gentoo.org> wrote:

> On Wed, 2018-01-10 at 22:38 +0300, Peter Volkov wrote:
> > On Wed, Jan 10, 2018 at 9:31 PM, Aaron W. Swenson
> > <titanofold@gentoo.  
> > org> wrote:
> > > Title: GnuCash 2.7+ Breaking Change  
> > 
> > Aaron, but why do we need this news item? 2.7 version is a
> > development version that is not supposed to be used by end users. As
> > far as I understand this backup is a temporary measure until stable
> > release will be out. It's much better to have this version package
> > masked. Then in package mask comment we could note the need for
> > backup.  
> 
> 2.6 is insecure by 400+ ancient webkit-gtk security vulnerabilities,
> we can't responsibly wait anymore. 2.7.3 was tested by Aaron (who
> uses it daily) to work quite nicely.
> I want to last rite gnucash-2.6 used webkit-gtk before the month is
> over, as the maintainer of webkit-gtk, and if 2.7 isn't there, 2.6
> will simply be fully masked as well along it.

I assume that the motivation to get 2.7 stabilized early it to protect
users from potentional damages caused via webkit-gtk security
vulnerabilities.  However, provided that I use GnuCash to display only
local web data (generated reports) I feel much more comfortable
to entrust my data to the stable 2.6 version rather than unstable 2.7
about which the upstream says:

"Unstable (development) releases are for testing purposes only. They
contain the newest features and improvements, but may also contain
serious bugs still. Don't install these releases for everyday use." [1]

"Due to the possibility of data corruption, unstable releases should
only be used on a copy of live GnuCash data." [2]

I think generated reports are typical use of webkit in GnuCash.  Are
attack vectors so severe also in this case?

Thank you.

1. http://gnucash.org/download.phtml
2. https://wiki.gnucash.org/wiki/Development_Process

Robert


-- 
Róbert Čerňanský
E-mail: ope...@tightmail.com
Jabber: h...@jabber.sk



Re: [gentoo-dev] [RFC] Splitting developer-oriented and expert user mailing lists

2017-12-04 Thread Róbert Čerňanský
On Mon, 4 Dec 2017 13:34:49 -0500
kuzetsa <kuze...@gmail.com> wrote:

> On 12/04/2017 01:11 PM, Christopher Head wrote:
> > On December 3, 2017 1:35:23 PM PST, "Michał Górny"
> > <mgo...@gentoo.org> wrote:  
> >> The best way to reach specific Gentoo developers is through
> >> Bugzilla. This gives the best chance for focused discussion on the
> >> specific issue without unnecessary distraction for other
> >> developers who are not interested in the specific topic.  
> > While this is true for bugs, is it true for everything else
> > as well? Bugzilla seems to me to be a more reactive, rather
> > than proactive, tool when dealing with changes of behaviour
> > in particular packages, eclasses, etc.  
> Reading the gentoo-dev list will still be an option. If there's
> a bug already open for a planned change (as often happens when
> blockers are expected, etc.), filing a bug and marking as a
> blocker will be an option. If the behavior is known in
> advance that it will break your configuration or workflow,
> etc. I think it's still fine to file a bug about the oversight
> before implemented occurs. If not appropriate to file as a bug,
> there are project aliases you can mail concerns to.

There are also matters like this one where Bugzilla is not very
appropriate medium, IMO.  For example instead of replaying to list I
would file a new bug with title "Users maybe will not be allowed to post
to gentoo-dev" and state my opinion there?

Regards,
Robert


-- 
Róbert Čerňanský
E-mail: ope...@tightmail.com
Jabber: h...@jabber.sk



Re: [gentoo-dev] [RFC] Splitting developer-oriented and expert user mailing lists

2017-12-03 Thread Róbert Čerňanský
On Sun, 03 Dec 2017 00:18:04 +0100
Michał Górny <mgo...@gentoo.org> wrote:

> 1. Posting to gentoo-dev@ and gentoo-project@ mailing lists will be
> initially restricted to active Gentoo developers.
> 
> 1a. Subscription (reading) and archives will still be open.
> 
> 1b. Active Gentoo contributors will be able to obtain posting access
> upon being vouched for by an active Gentoo developer.
> 
> 2. A new mailing list 'gentoo-expert' will be formed to provide
> a discussion medium for expert Gentoo users and developers.
> 
> 2a. gentoo-expert will have open posting access like gentoo-dev has
> now.

Hi Michał,

I fully understand and support the need of pure dev to dev
mailing list.  On the other side I also see the need for an official
(mailing list) channel through which users can reach developers.  And
with the proposed change we (users) loose that channel.  I am not sure
if gentoo-expert was meant to be such channel; if not could you please
consider it?  If yes then I think gentoo-dev-user or gentoo-user-dev
would be more appropriate name.

Best regards,
Robert


-- 
Róbert Čerňanský
E-mail: ope...@tightmail.com
Jabber: h...@jabber.sk



Re: [gentoo-dev] NEWS item for games destabling

2017-11-21 Thread Róbert Čerňanský
On Mon, 20 Nov 2017 21:53:52 -0800
Daniel Campbell <z...@gentoo.org> wrote:

> On Mon, Nov 20, 2017 at 11:36:33AM +0100, Róbert Čerňanský wrote:
> > On Mon, 20 Nov 2017 10:26:29 +0100
> > David Seifert <s...@gentoo.org> wrote:
> >   
> > > Round 2 (with correct whitespace this time):
> > > 
> > > Title: No stable KEYWORDS for Gentoo Games
> > > Author: David Seifert <s...@gentoo.org>
> > > Content-Type: text/plain
> > > Posted: 2017-11-20
> > > Revision: 1
> > > News-Item-Format: 1.0
> > > Display-If-Keyword: amd64 x86
> > > 
> > > As the Games team does not have enough manpower to keep tabs on
> > > all games packages, we have dropped all ebuilds maintained by the
> > > games project to unstable KEYWORDS (without those required by
> > > other stable packages). If you have any of these stable games
> > > packages installed, you will have to add them
> > > to /etc/portage/package.accept_keywords/ manually. Failures
> > > related to missing stable KEYWORDS will show up as
> > > 
> > >   The following keyword changes are necessary to proceed:
> > >(see "package.accept_keywords" in the portage(5) man page for
> > > more details)
> > >   # required by @selected
> > >   # required by @world (argument)
> > >   =games-action/0verkill-0.16-r4 ~amd64
> > > 
> > > While we accept that this will cause some irritation for the
> > > community, pretending we have a well supported games collection by
> > > having a wealth of stable games packages is misleading at best. We
> > > welcome contributions from outsiders willing to polish up the
> > > games landscape in Gentoo via the Proxy Maintainers.  
> > 
> > What does it mean for the future?  Should not users bother to test &
> > write stabilization request bugs for games anymore?  Or stabi
> > requests will still be accepted?
> 
> If I may take a stab at this (correct me if I'm wrong, soap):
> 
> It only means games are being dropped to ~arch (testing) until other
> maintainers (proxy or otherwise) step up to make sure the games really
> are stable. Packages that rarely get attention but are still marked
> "stable" dilutes the meaning of "stable", especially if you get
> installation or runtime problems that a proper testing of the package
> would have caught.
> 
> This results in bugs that should've been caught in the testing phase,
> confuses users (and developers), and redundant or obvious bugs being
> reported.
> 
> This reads like a "fresh slate" for games, allowing them to start from
> ~arch and ensure that stabilization procedures are correctly followed
> by those who step up. While this will create more stabilization bugs,
> it should, in theory, result in better ebuilds (which makes Gentoo
> maintenance better/easier) and games that have *actually* been tested.
> 
> I hope this explanation is both accurate and helpful.

It make sense to me.  Although the original news reads more like
"games will not go to stable unless they are proxy maintained" but --
in light of your explanation -- that's probably me reading it wrong.
It is certainly better if package keywords reflect the reality.  I
only hope this will not be happening very often, more like - never
again. ;-)

...and thanks games team and everyone who provides & maintains games
in Gentoo or did so in the past.  Availability of top-class games was
one of the things which attracted me to Gentoo (lots of years ago ;-) ).
Portage being able chew original commercial CD-s blown my mind back
then.  I think this is unique to Gentoo and no other distro had ever
possibility to install those games via package manager.

Robert


-- 
Róbert Čerňanský
E-mail: ope...@tightmail.com
Jabber: h...@jabber.sk



Re: [gentoo-dev] NEWS item for games destabling

2017-11-20 Thread Róbert Čerňanský
On Mon, 20 Nov 2017 10:26:29 +0100
David Seifert <s...@gentoo.org> wrote:

> Round 2 (with correct whitespace this time):
> 
> Title: No stable KEYWORDS for Gentoo Games
> Author: David Seifert <s...@gentoo.org>
> Content-Type: text/plain
> Posted: 2017-11-20
> Revision: 1
> News-Item-Format: 1.0
> Display-If-Keyword: amd64 x86
> 
> As the Games team does not have enough manpower to keep tabs on all
> games packages, we have dropped all ebuilds maintained by the games
> project to unstable KEYWORDS (without those required by other stable
> packages). If you have any of these stable games packages installed,
> you will have to add them to /etc/portage/package.accept_keywords/
> manually. Failures related to missing stable KEYWORDS will show up as
> 
>   The following keyword changes are necessary to proceed:
>(see "package.accept_keywords" in the portage(5) man page for more
> details)
>   # required by @selected
>   # required by @world (argument)
>   =games-action/0verkill-0.16-r4 ~amd64
> 
> While we accept that this will cause some irritation for the
> community, pretending we have a well supported games collection by
> having a wealth of stable games packages is misleading at best. We
> welcome contributions from outsiders willing to polish up the games
> landscape in Gentoo via the Proxy Maintainers.

What does it mean for the future?  Should not users bother to test &
write stabilization request bugs for games anymore?  Or stabi
requests will still be accepted?

Robert


-- 
Róbert Čerňanský
E-mail: ope...@tightmail.com
Jabber: h...@jabber.sk



Re: [gentoo-dev] REQUIRED_USE, global USE flags, user-friendliness...

2017-01-29 Thread Róbert Čerňanský
would _remove_ it.  So if there would be multiple
choices the user would not be prompted, but some default option would be
selected by PM.  To the user, such behaviour would be similar to
current handling of virtuals - if a package depends on a virtual the
user is not prompted to make a choice but the default is selected
instead.

Some of the USE settings levels would have to be overridable by PM in
order to achieve this - most likely it would be global and default
ones and perhaps also the ones in make.conf.  The override of a
particular USE flag would be valid only while there is a need.

Technically, PM would not update any configuration files (in /etc/) in
this process.  The required information would be stored in PM's
internal structures (/var/db/pkg?).

In general, I consider user friendly behaviour if emerge does not ask me
anything during the update/install process.  It however should clearly
show me what it is going to do (with --verbose enabled).

Best regards,
Robert


-- 
Róbert Čerňanský
E-mail: ope...@tightmail.com
Jabber: h...@jabber.sk



Re: [gentoo-dev] "Lazy" use flags?

2016-02-11 Thread Róbert Čerňanský
On Thu, 11 Feb 2016 07:55:52 -0500
Rich Freeman <ri...@gentoo.org> wrote:

> On Wed, Feb 10, 2016 at 11:57 PM, Kent Fredric
> <kentfred...@gmail.com> wrote:
> > On 11 February 2016 at 15:51, Rich Freeman <ri...@gentoo.org> wrote:
> >> In this case you just wouldn't enable python 2.7 support, but you
> >> wouldn't disable it either.  Portage would just pull it in where
> >> it is needed.
[...] 
> Perhaps it might make sense to introduce a new ~foo setting which
> undoes a +/-foo in make.conf but doesn't set it either + or - in
> package.use, allowing the setting to revert to the default behavior.
> That would actually be useful independent of lazy use flags, but would
> be more useful with lazy use flags.

Having also ~foo syntax (together with omiting use flags) seems to me
as best option now actually.  It would support also Kent's use case I
think.

Taking that use case as an example - if I would want to get rid of
python-2.7 as soon as possible I'd set -python_targets_python2_7 in
make.conf.  For those packages which portage screams that needs
python_targets_python2_7 I'd set ~python_targets_python2_7 in
package.use.

In time when last of those packages stops hard-requiring
python_targets_python2_7 the python-2.7 package itself would be
depcleaned and I could remove '~' entries from package.use.

Nice and clean :-) .


-- 
Róbert Čerňanský
E-mail: ope...@tightmail.com
Jabber: h...@jabber.sk



Re: [gentoo-dev] "Lazy" use flags?

2016-02-10 Thread Róbert Čerňanský
On Wed, 10 Feb 2016 15:23:27 +1300
Kent Fredric <kentfred...@gmail.com> wrote:

> >> I'd personally rather the list of "automatically turn this on if
> >> required" be something I had the power to restrict than have a
> >> blanket "autodostuff", because in the event some USE can't be

Although I prefer non-explicit auto/lazy use flags, the explicit
approach is also perfectly fine (especially when compared to current
situation).  In the end I would most certainly be able to specify all
use flags as lazy and thus have effectively the same behaviour as with
non-explicit approach.

> So in comparison:
> 
> /etc/portage/package.use  is essentially "the world file but for
> useflags"
> 
> And we have no analogue of
> 
> /etc/porage/package.unmask  or /etc/portage/package.keywords that
> applies to useflags.

I find /etc/portage/package.use (or make.conf) analogous to world AND
mask files.  For packages world + mask files give you possibility to
specify which packages you:

- want (listed in world file)
- don't want (listed in a mask file)
- not care (not listed in any of them)

(Assuming non-explicit approach) similarly for use flags, package.use
or make.conf gives you possibility to specify which use flags you:

- want (listed in package.use or make.conf)
- don't want (listed with '-' in package.use or make.conf)
- not care (not listed in any of them)

The advantage of explicit approach could be that even if a use flag is
enabled or disabled globally, it would still be possible to make it
lazy/automatic for specific packages.

> I can see how some people might want an analogue of "just install
> dependencies if they're needed regardless if I said I need them" that
> applies to useflags, but you'd probably want a "don't install this
> even if it appeared to be needed" companion tool that behaves akin to
> /etc/portage/package.mask

This would be package.use or make.conf.


-- 
Róbert Čerňanský
E-mail: ope...@tightmail.com
Jabber: h...@jabber.sk



Re: [gentoo-dev] "Lazy" use flags?

2016-02-09 Thread Róbert Čerňanský
On Wed, 10 Feb 2016 02:19:54 +1300
Kent Fredric <kentfred...@gmail.com> wrote:

> On 10 February 2016 at 02:14, Daniel Campbell <z...@gentoo.org> wrote:
> > Another concern, though, is it'd result in something similar.
> > Instead of "cat/foo bar baz" and later removing 'baz', you'd have
> > "cat/foo bar ~baz" (with '~baz' as 'enable this if you need to').
> > You'd still have cruft left in your p.use file, and it would
> > achieve the same result as a well-commented file.
> 
> 
> Granted you'd still have the cruft in your config files, but it would
> become mostly-harmless cruft, not cruft that caused needless
> dependencies to get pulled into the dependency tree as a side-effect.
> 
> And because it would be "only as needed", you could afford to use some
> of those "only if needed" useflags in a more global manner.

The question is whether you really need to specify the lazy use flag
explicitly.  I would say that any flag which user did not set
explicitly to -baz or baz could be considered as lazy use flag.

So if I'd have 'baz' set in /etc/portage/make.conf,
/etc/portage/package.use, USE environment variable or other user
configuration then I'd clearly want to turn on baz (globally or for
specific packages).  Portage would not change the use flag in this
case (again globally or for particular packages only).

On the other side, if I would not specify 'baz' in any of those user
configurations (so it would be specified only in profile, ebuild or
nowhere at all) then I most likely would not care about it therefore
portage can enable or disable it as needed.

BTW, what you are describing is essentially the same as in this bug:
https://bugs.gentoo.org/show_bug.cgi?id=258371.  It was also discussed
on this list couple of times.  I too would very much like to see it in
portage.

Robert


-- 
Róbert Čerňanský
E-mail: ope...@tightmail.com
Jabber: h...@jabber.sk



Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2015-08-30 23:59 UTC

2015-09-03 Thread Róbert Čerňanský
On Mon, 31 Aug 2015 15:06:05 +0100
malc <mlash...@gmail.com> wrote:

> dev-java/burlap Mon Aug 24 17:21:42 2015 +0200
>  Patrice Clement <monsie...@gentoo.org>
> dev-java/caucho-servicesMon Aug 24 17:21:42 2015 +0200
>  Patrice Clement <monsie...@gentoo.org>

Can it be *please* modified so that one removal/addition fits on a
single line?  It is very hard to eye-parse when lines are split in
two.  Or maybe leave the length as is and do not break the lines?

(I hope it's not settings of my MUA, but I have checked the raw message
and it's the same also there.)

Robert 


-- 
Róbert Čerňanský
E-mail: ope...@tightmail.com
Jabber: h...@jabber.sk



Re: [gentoo-dev] Re: Things one could be upset about

2015-01-26 Thread Róbert Čerňanský
On Mon, 26 Jan 2015 09:20:30 -0500
Rich Freeman ri...@gentoo.org wrote:

 On Mon, Jan 26, 2015 at 8:21 AM, Duncan 1i5t5.dun...@cox.net wrote:
  The result of the current policy is that if you're waiting for the
  GLSA, unless it's _extreme_ priority (heartbleed level), on at
  least amd64, you're very often sitting there exposed for well over
  a week, and too often a month, after the fix is out there, actually
  installed on /my/ systems.  And to me that's a game of Russian
  Roulette odds that I'm simply not willing to play.
 
 From a PR standpoint we'll be communicating to some users that they
 are vulnerable, and we haven't completely fixed the issue yet.  I
 think we just need to reset expectations here.  The fact is that today
 they're just as vulnerable, but we don't broadcast that.  Sending out
 notice sooner will help out users who want to update based on GLSAs,
 and if there isn't a stable version yet the user can decide whether to
 just wait for testing or move ahead on their own.

I do check also other sources of security related info and take
measures if it affects me (update affected package, change
configuration, ...).  I should say earlier security updates instead
of GLSAs which would be actually closer to reality.

I agree that (unfixed) security issues should be communicated so we do
not put false hopes to GLSA.

Robert


-- 
Róbert Čerňanský
E-mail: ope...@tightmail.com
Jabber: h...@jabber.sk



Re: [gentoo-dev] Re: Things one could be upset about

2015-01-25 Thread Róbert Čerňanský
On Sun, 25 Jan 2015 04:29:43 + (UTC)
Duncan 1i5t5.dun...@cox.net wrote:

 Alexey Mishustin posted on Sat, 24 Jan 2015 21:54:06 +0400 as
 excerpted:
 
  2015-01-20 14:42 GMT+04:00 Róbert Čerňanský ope...@tightmail.com:
 
  I somehow thought that edit the overgrowing package.use
  file upon each emerge world annoys anyone the same as me.
  
  But for me this is one of the most useful and convenient options in
  Gentoo. Yes, I do edit package.use almost every emerge world. And I
  like to do it. And I don't want to delegate this right to any
  program - portage, or any other.
 
 Agreed that I don't want to (and won't) delegate that decision, but 
 almost every emerge world?  Not here.  So ???
 
 I do edit package.use (or my global USE flags) occasionally, but not
 as often as the above implies.  What might I be doing different?
 Well, here's what I do:
 
 1) I try to sync and update deep newuse @world once a week, tho
 sometimes it's every two weeks (but sometimes it's daily).  I suppose
 if people only get to it every couple months, they'll have more
[...]
 So maybe it's simply that I update frequently enough, tho I /do/ run 
 ~arch as well, which changes much faster than stable, and I even run

More frequent updates is most likely the reason that you do not have
to edit use flags every time.  Running testing perhaps does not
increase the editing frequency because dependency changes are the same
regardles of how many bumps a package has.  For example in testing
you'll get following updates of package foo: foo-1.1, ~foo-1.2,
~foo-1.3, foo-1.4.  In stable, I would get: foo-1.1, foo-1.4.  If
dependency changes in 1.3, both of us could have to edit USE flags
once.

I update every 2-4 months (only GLSAs in between) therefore my
experience is that I have to edit it every time (not for GLSAs of
course).

 2) My global USE= starts with -*.  I got tired of worrying about what
[...]
 3) I don't normally distinguish between local and global USE flags.
 I normally treat them all as global and set them globally in my
 make.conf use file[1].  When I encounter a new USE flag, because of
 the -* in USE, it's off by default.  If I decide I want it off, no
 problem, it's off. If I decide I want it on, I run an equery hasuse
 flag to see if any other package uses it.  If nothing else uses it,
[...]
 Similarly, if I encounter a new USE flag that's on already, obviously 
 some other package I use is already using it and the entry is in my
 use file or it wouldn't be on already, due to the -* in that use
 file. That's a strong hint what I'm likely to want the default to
 be.  If I decide I want it off anyway, I run an equery hasuse flag
[...]
 So for all flags, if I want the default off, due to the -* in my use 
 file, it's off.  If I want the default on, it's in my use file,
 turning it on.
 
 4) The result is that my package.use files contain ONLY non-default 
 entries.

More or less same here, except -* as the default.  I trust developers
that they are choosing wisely in profile and ebuilds. ;-)  If not, I
see it in emerge -av output anyway and can disable/enable particular
flag.  But generally I have vast majority of flags in make.conf and
exceptions in package.use.

 When I set such an entry, I prefix a comment line with the date and
 an explanation of WHY the entry needs to be there, different from my
 normal default settings.  Sometimes, it's due to a bug, and a couple
 versions later I can go thru and test with that entry commented, to
 see if the bug is fixed, yet.  Other times it's due to a use-dep from
 some other package I have installed.  Both qt and kde tend to have

This where we get to the point.  If you set USE flag because of a bug
or because of dependency it is not because you *want to* but because
you *have to* (or portage *needs to*).  Therefore you need to add a
comment WHY you did it.

For example I have -doc in make.conf because I do *not want* docs
globally.  But I have 'dev-lang/python doc' in package.use because I
develop in Python and *want* the documentation for it.  Such entry
does not need a comment, because I simply know what I want.

Another example.  I have -python globally and have been using
app-mobilephone/gammu.  Now I want to emerge app-mobilephone/wammu.
But it needs +python for gammu, so I *have to* set
'app-mobilephone/gammu python' in package.use.  In this case I also
add a comment which explains the reason because it is not what *I
want* it is what *portage needs*.  Once this dependency is gone
(either because wammu stops requiring it or I unmerge it) it is on me
to detect it and remove the entry.  So effectively I manage portage's
stuff in my configuration file.

 Regardless of why it's there, however, because only non-default
 entries are in package.use, they're the obvious exception.

You somehow do not distinguish between those two types of exceptions
explained in examples above.

 And as exceptions, they don't tend to change that often. =:^)
 Generally,

They might change

Re: [gentoo-dev] Things one could be upset about

2015-01-24 Thread Róbert Čerňanský
On Sat, 24 Jan 2015 21:54:06 +0400
Alexey Mishustin shum...@shumkar.ru wrote:

 2015-01-20 14:42 GMT+04:00 Róbert Čerňanský ope...@tightmail.com:
  On Tue, 20 Jan 2015 11:08:19 +0300
  Andrew Savchenko birc...@gentoo.org wrote:
 
  On Tue, 20 Jan 2015 07:46:32 +0100 Róbert Čerňanský wrote:
   On Tue, 20 Jan 2015 00:14:29 +0300
   Andrew Savchenko birc...@gentoo.org wrote:
On Mon, 19 Jan 2015 21:44:25 +0100 Róbert Čerňanský wrote:
   For example, lets have following packages:
  
   - libbar
   - libfoo with IUSE=bar, which depends on: bar? ( libbar )
   - foo, which depends on: libfoo[bar]
  [...]
   New behaviour with automatic USE dependencies resolution:
  
   emerge -av foo
   [ebuild  N ] libbar
   [ebuild  N ] libfoo +bar
   [ebuild  N ] foo
  
   Now, you can hit Y if you agree what portage wants to do or N and
   not to install foo at all.
 
  And if I don't agree? What if for some reason I don't want to
  have libfoo[bar] on my system. What If preferred solution will
  be not to use libbar at all and to use libclue instread?
 
  In this example, if you do not agree, you have no other option how
  to install foo (with or without automatic USE deps).  Because foo
  depends on libfoo[bar] unconditionally.
 
 Perfect! May be I will prefer to refuse to install that package, after
 seeing its dependencies.
 
  Yet again, Gentoo is all about choise. If someone wants that
 
  I agree, but I must say I am quite stunned that there are strong
  voices against it.  I somehow thought that edit the overgrowing
  package.use file upon each emerge world annoys anyone the same as
  me.
 
 But for me this is one of the most useful and convenient options in
 Gentoo. Yes, I do edit package.use almost every emerge world. And I
 like to do it. And I don't want to delegate this right to any program
 - portage, or any other.

You would not loose that.  First of all, portage would do its changes
elsewhere (in /var).  Secondly, your settings in package.use would
still be respected.  But instead of portage telling you to edit
package.use it would show you required changes in emerge -av output.
If you do not like them then hit N and edit package.use, masks or
whatever.

In case of conflict, i.e. if portage would want to set a USE flag for a
package which you have disabled in package.use then it would fail
(similarly as it fails when some package has testing keyword or is
masked).  So if I have 'net-print/cups -usb' in package.use the
automatic USE depencencies would _never_ enable usb for cups.  But if I
have -python in _make.conf_ and want to emerge app-mobilephone/wammu
which depends on app-mobilephone/gammu[python] then portage would be
able to enable python for gammu.

The intention behind this automatic USE dependencies is to edit
package.use only when user wants, not when portage needs it.

Robert


-- 
Róbert Čerňanský
E-mail: ope...@tightmail.com
Jabber: h...@jabber.sk



Re: [gentoo-dev] Re: Things one could be upset about

2015-01-21 Thread Róbert Čerňanský
On Wed, 21 Jan 2015 01:57:27 + (UTC)
Duncan 1i5t5.dun...@cox.net wrote:

 Róbert Čerňanský posted on Tue, 20 Jan 2015 06:51:01 +0100 as
 excerpted:
 
  On Mon, 19 Jan 2015 20:51:31 + Ciaran McCreesh
  ciaran.mccre...@googlemail.com wrote:
  
  On Mon, 19 Jan 2015 21:44:25 +0100 Róbert Čerňanský
  ope...@tightmail.com wrote:
   From my point of view it would do much help if portage resolves
   USE dependencies automatically instead of telling the user to
   change USE flags manually (I am talking about bug #258371).
  
  This is only possible in carefully selected circumstances, and to
  get it to work more generally would require a lot of hinting from
  package maintainers.
  
  But portage already knows that.  It tells the user which USE flags
  needs to be changed in order to emerge a package.  It should just
  go one step further - to make the proposed change happen by itself.
 
 Actually, current portage (2.2.15 is what I have installed here ATM)
 does exactly that, making changes to the appropriate package.* files
 as necessary, mediated only by the usual CONFIG_PROTECT variables.

No, no, no that is not the right solution.  Portage should _not_ touch
my precious config files crafted for many years.  It should store the
USE related dependencies info in its _internal_ structures (somewhere
in /var/db/pkg I presume).  Sorry I was not clear previously.  Moreover
it should be able to depclean them - revert the USE changes once the
dependency is no longer needed (for example with new emerge option
--use-depclean).  Just like with standard package dependencies.

 Since /etc/portage is CONFIG_PROTECTed by default, these changes
 normally first appear in that feature's .* files, to be merged by the
[...]
 tolerable. As others in-thread have stated, we don't believe that's
 something portage should be messing with.

Totally agree, it should mess only with /var/db/pkg or so, not /etc.

[... sniped great explanation of current testing portage behaviour in
this regard; thanks for that, even though it is not what I crave for]

Robert


-- 
Róbert Čerňanský
E-mail: ope...@tightmail.com
Jabber: h...@jabber.sk



Re: [gentoo-dev] Things one could be upset about

2015-01-20 Thread Róbert Čerňanský
On Tue, 20 Jan 2015 11:08:19 +0300
Andrew Savchenko birc...@gentoo.org wrote:

 On Tue, 20 Jan 2015 07:46:32 +0100 Róbert Čerňanský wrote:
  On Tue, 20 Jan 2015 00:14:29 +0300
  Andrew Savchenko birc...@gentoo.org wrote:
   On Mon, 19 Jan 2015 21:44:25 +0100 Róbert Čerňanský wrote:
From my point of view it would do much help if portage resolves
USE dependencies automatically
[...]
   As the user the last thing I want is to have some USE flags
   changed without my permission
[...]
  Is is of course perfectly fine to have that option disabled by
  default.  But I am afraid that I do not quite understand yours and
  Daniel's concerns.  If I paraphrase your statement with regards to
  current dependency handling, it is as if you were saying: I do not
  want portage to install any package automatically by its own, I want
  to install all the dependencies explicitly.
 
 The paraphrasing above is wrong. What I want to say is I don't want
 portage to automagically change _functionality_ of my packages on
 its own, even in order to solve dependencies.
  
  Why we allow portage to install dependencies and still have things
  under control?  Well we have --pretend and --ask options and we can
  see what would/will be done.  This would be the same with USE flags.
  You would see in the --pretend output which flags would be changed.
 
 No this wouldn't be the same. USE flags are _not_ equal to package
 dependencies, sometimes they will not trigger dependency change at
 all. USE flags are about _functionality_, dependencies are about
 the _means_ to implement that functionality (as well as base
 functionality of a package).

I see your point about functionality.  There are USE flags that
_changes_ functionality (like threads) and there are others which _adds_
functionality (like for example speex adds possibility to play files in
that particular format in mplayer).  The former I consider similar to
package dependencies because they too can add functionality to the
system (for example if ruby is installed as dependency it adds
possibility to execute ruby scripts) same as those USE flags adds
functionality to an application.

However, even if portage wants me to change USE flag that will change
functionality, in 99% of time I end up adding to my package.use what it
wants, since my goal is to install some application or update my
applications.  So just reviewing the changes that portage wants to do
and hit Y.  And in those rare cases when I really do not want some flag
enabled or some package installed I hit N and tweak things.

  To match the package dependency handling, there should be also an
  option equivalent to --depclean.  It would revert the USE changes
  which were done because of dependencies requirements if no longer
  needed.
 
 This will dramatically increase complexity of dependencies metadata
 as well as of algorithms to handle it (and they are already slow),
 with no clear benefits therefore. No, thanks.

Are you talking about proposed new USE specific depclean option or
emerge in general?  If it is the new depclean command that would run
slow then I am quite sure it will still be faster than me or anyone else
going manually through package.use and for each and every USE flag there
trying to remove it, run emerge, see if it passes, if not, add it back.

If it is emerge in general that would be slower that it is still better
than run it, see it fail and telling you what USE to change, you making
the change, and run it again.

  For example, lets have following packages:
  
  - libbar
  - libfoo with IUSE=bar, which depends on: bar? ( libbar )
  - foo, which depends on: libfoo[bar]
[...]
  New behaviour with automatic USE dependencies resolution:
  
  emerge -av foo
  [ebuild  N ] libbar
  [ebuild  N ] libfoo +bar
  [ebuild  N ] foo
  
  Now, you can hit Y if you agree what portage wants to do or N and
  not to install foo at all.
 
 And if I don't agree? What if for some reason I don't want to
 have libfoo[bar] on my system. What If preferred solution will
 be not to use libbar at all and to use libclue instread? 

In this example, if you do not agree, you have no other option how to
install foo (with or without automatic USE deps).  Because foo depends
on libfoo[bar] unconditionally.

If however foo would depend either on libfoo[bar] or libclue then the
portage would do the same thing as today (I guess it would take the
first dependency as mandatory or the one which is already installed if
any.) In this case, yes, your preference might be libclue instead what
portage chooses.  But I see no difference in the way how user choose it
comparing to todays '|| ( libfoo libclue )' -like dependencies.

 World update on my systems usually involves about 2000 of packages.
 It's already hard to read emerge -DNuav output in order to check
 for new packages, dependencies, downgraded and removed packages.
 Automagick dependency change will make this even harder, much
 harder because it will involve

Re: [gentoo-dev] Things one could be upset about

2015-01-19 Thread Róbert Čerňanský
On Tue, 20 Jan 2015 00:14:29 +0300
Andrew Savchenko birc...@gentoo.org wrote:

 On Mon, 19 Jan 2015 21:44:25 +0100 Róbert Čerňanský wrote:
  From my point of view it would do much help if portage resolves USE
  dependencies automatically instead of telling the user to change USE
  flags manually (I am talking about bug #258371).
 
 As the user the last thing I want is to have some USE flags changed
 without my permission ending up stuff I need to be omitted or stuff
 I don't want to see on my system to be installed. Of course if
 someone prefers USE flags to be randomly changed I don't mind if
 such option will exist (as proposed in bug #258371) as long as it
 is disabled by default.

Is is of course perfectly fine to have that option disabled by
default.  But I am afraid that I do not quite understand yours and
Daniel's concerns.  If I paraphrase your statement with regards to
current dependency handling, it is as if you were saying: I do not
want portage to install any package automatically by its own, I want
to install all the dependencies explicitly.

Why we allow portage to install dependencies and still have things
under control?  Well we have --pretend and --ask options and we can
see what would/will be done.  This would be the same with USE flags.
You would see in the --pretend output which flags would be changed.

To match the package dependency handling, there should be also an
option equivalent to --depclean.  It would revert the USE changes
which were done because of dependencies requirements if no longer
needed.

For example, lets have following packages:

- libbar
- libfoo with IUSE=bar, which depends on: bar? ( libbar )
- foo, which depends on: libfoo[bar]

USE flag bar is not enabled.  You want to install application foo.

Current behaviour:

# emerge -av foo
...
Required USE changes:
libfoo +bar
... (sorry for not exact emerge output but you get the idea)

Now, you either fire up your favorite editor and add libfoo +bar to
/etc/portage/package.use, re-run emerge and have libbar installed even
you do not want it.  The other option is not to install application
foo at all.

If you choose to emerge it and after year or so you decide to unmerge
it because you do not need it anymore you still will have a leftover
in package.use file - the line libfoo +foo even if you run emerge
--depclean.

New behaviour with automatic USE dependencies resolution:

emerge -av foo
[ebuild  N ] libbar
[ebuild  N ] libfoo +bar
[ebuild  N ] foo

Now, you can hit Y if you agree what portage wants to do or N and not
to install foo at all.

After unmerging it you run emerge --depclean which removes libfoo with
its changed USE flag and libbar, no leftovers. (In this case new
--use-depclean command is not required since libfoo was removed.)

If libfoo would not be removed because some other package needs it,
then emerge --use-depclean would revert the +bar USE flag to its
default state and re-emerge libfoo.

Robert


-- 
Róbert Čerňanský
E-mail: ope...@tightmail.com
Jabber: h...@jabber.sk



Re: [gentoo-dev] Things one could be upset about

2015-01-19 Thread Róbert Čerňanský
On Mon, 19 Jan 2015 20:51:31 +
Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:

 On Mon, 19 Jan 2015 21:44:25 +0100
 Róbert Čerňanský ope...@tightmail.com wrote:
  From my point of view it would do much help if portage resolves USE
  dependencies automatically instead of telling the user to change USE
  flags manually (I am talking about bug #258371).
 
 This is only possible in carefully selected circumstances, and to get
 it to work more generally would require a lot of hinting from package
 maintainers.

But portage already knows that.  It tells the user which USE flags
needs to be changed in order to emerge a package.  It should just go
one step further - to make the proposed change happen by itself.

Robert


-- 
Róbert Čerňanský
E-mail: ope...@tightmail.com
Jabber: h...@jabber.sk



Re: [gentoo-dev] Things one could be upset about

2015-01-19 Thread Róbert Čerňanský
On Sat, 17 Jan 2015 18:33:45 +0300
Andrew Savchenko birc...@gentoo.org wrote:

 On Sat, 17 Jan 2015 14:45:51 + Ciaran McCreesh wrote:
  The problem isn't the constants, though. The problem is the
  resolution algorithm. There's not much point tweaking performance
  until the resolver is fixed to produce a correct answer...
 
 Oh, this was discussed so many times already... There is NO single
 correct solution to such problems. And some mathematically correct
 solutions are impractical (e.g. half of the tree rebuild), so other
 ones which are good enough are preferred. As long as imperfect
 solution works fine, I'm ok with it.

From my point of view it would do much help if portage resolves USE
dependencies automatically instead of telling the user to change USE
flags manually (I am talking about bug #258371).

Robert


-- 
Róbert Čerňanský
E-mail: ope...@tightmail.com
Jabber: h...@jabber.sk



Re: [gentoo-dev] Things one could be upset about

2015-01-18 Thread Róbert Čerňanský
On Sat, 17 Jan 2015 13:44:21 +0100
Dirkjan Ochtman d...@gentoo.org wrote:

 On Sat, Jan 17, 2015 at 12:35 PM, Patrick Lauer patr...@gentoo.org
 wrote:
 
  * Some stable bugs are left alone for months
 See e.g. https://bugs.gentoo.org/show_bug.cgi?id=485632
 Fix: Have more people work on stable bugs
 Fix: Motivate people to file more stable bugs (continuous
  updates)
 
 This is a thorny problem as well. I worry that we lose momentum here
 due to size and perfectionism (e.g. we can only stable new gcc once we
 fix all the blockers, and we don't have enough active maintainers on
 some of those blockers). I think we should maybe stabilize more
 optimistically
[...]
 I also wonder if we could sort of crowd-source archtesting, maybe by
 having people contribute their package.keywords through gentoo-stats
 or some such to see how well an unstable package is being tested on
 stable systems already.

This could help in a sense that developers would have more confidence
when stabilizing packages.  But even without such statistics there is
for example the number of open bugs that gives a clue about the
quality of a package.  It should be used to drive stabilizations in
the spirit of good old rule 1 month without bugs = stabilize. At
least for less critical packages, mainly end-user applications.  I
recall that some time ago there were some activities regarding this
rule but I am not sure if it is in place.  So I would add one more fix
for this issue:
Fix: Apply 1 month without bugs = stabilize rule more often.

Also I think that end-user applications could be stabilized little
more aggresivelly while libraries could keep current conservative
approach.

For example, having installed ~1700 packages of which ~500 are in
world file, recent update world after two months gave me: 292 packages
(183 upgrades, 60 new, 4 in new slots, 45 reinstalls).  However
counting number of end-user applications that were updated I end up
with 9 of them of which only 6 was a somewhat major update that could
bring new features.  (I do not consider system utilites -- like for
example lsof -- as end-user applications even that number of them are
in my world file.)

So if you look to it from this perspective such update does not look
very efficient since out of ~300 builded packages only 6 brings
potential to increase productivity/bring new features.  Such
experiences brings me to conclusion that end-user applications may be
stabilized more often.

Regards,
Robert


-- 
Róbert Čerňanský
E-mail: ope...@tightmail.com
Jabber: h...@jabber.sk



Re: [gentoo-dev] Last rites: app-text/cuneiform

2013-03-25 Thread Róbert Čerňanský
On Sun, 24 Mar 2013 19:40:07 -0400
Rich Freeman ri...@gentoo.org wrote:

 On Sun, Mar 24, 2013 at 3:24 PM, Ian Stakenvicius a...@gentoo.org
 wrote:
  The number of open bugs doesn't really matter, it's what those bugs
  are that matters -- security bugs, sure, are of a higher priority
  and can be fairly easily detected in bugzilla.
 
 Well, our current treecleaner policy seems to be that if a package
 isn't maintained and has any bugs open at all it is fair game.  The
 caveat to that is that trivial bugs are grounds for fixing instead of
 removals (bad DEPEND atoms, simple-to-fix, etc).  Google the full
 policy for details.
 
 I think that a better policy would be rather than having any open
 non-trivial bugs we list the sorts of bugs that should be grounds for
 removal, such as:
 
 1.  Package does not build in the majority of cases on all archs.
 (Unkeywording is the solution for individual archs that are broken, if
 not easily fixable.  Not building some of the time isn't grounds for
 removal.)
 
 2.  Package has an open security bug.  (Cuneiform is a borderline case
 of this - no exploit/CVE but I wouldn't use it on a server being fed
 images submitted by strangers.)
 
 3.  Package is blocking another package.  Maintained packages always
 take priority over unmaintained ones.
 
 Perhaps there are other cases which should be included, but I think
 this covers most of them.  If a package isn't blocking anything else,
 doesn't have security problems, and works most of the time, then I
 think it should generally be kept.

This souds very promising.  Could we leave out point 2 though?  Gentoo
puts lot of decision power to users.  Can it be so also in this case?
Users will have to be informed that the package has security issues of
course, for example, by mentioning it in the mask note.

Robert


-- 
Róbert Čerňanský
E-mail: ope...@tightmail.com
Jabber: h...@jabber.sk



Re: [gentoo-dev] Last rites: app-text/cuneiform

2013-03-25 Thread Róbert Čerňanský
On Mon, 25 Mar 2013 08:23:31 +0800
Patrick Lauer patr...@gentoo.org wrote:

 On 03/24/2013 09:40 PM, Peter Stuge wrote:
  Markos Chandras wrote:
  The masks are sort of announcements as you have 30 days to revert
  that decision.
  
  You don't seem to recognize the quite significant psychological
  impact of you having already made the decision, compared to, say,
  having an actually inclusive package removal process.
 
 If the package has been rotting away with open bugs in bugzilla for
 weeks or months and no one cares ... what are we supposed to do? Wait
 a bit longer?

In short, mask it, wait until it rots completely and _then_ apply 30 day
removal policy.  Unmask it, if it finds a maintainer and bugs are fixed.

Robert


-- 
Róbert Čerňanský
E-mail: ope...@tightmail.com
Jabber: h...@jabber.sk



Re: [gentoo-dev] Last rites: app-text/cuneiform

2013-03-24 Thread Róbert Čerňanský
On Sat, 23 Mar 2013 16:13:07 -0400
James Cloos cl...@jhcloos.com wrote:

  MC == Markos Chandras hwoar...@gentoo.org writes:
 
 MC The package is going away unless someone fixes the bugs and
 MC properly maintains the package
 
 Again, that is an irresponsible mistake.  It is better to just leave
 it as is than to kick it.  Dropping important packages can only harm
 the community and is never welcome.

And that is why I now appeal to users:

  _Do not report bugs to Gentoo unless a package is completely broken._

Because what you will get in return?  Package removed.

A package with bugs has a greater user value than no package at all.
Until Gentoo does not understands that and does not change its removal
policy accordingly, and provides technical means to reflect it*, it is
the only user-viable** way how to keep a package in the tree as long as
possible.

* Which could be e. g. masking a package until it is completely
  broken.

** No, I do not want to become a developer.  No, I do not want to
   maintain a package.  I am the user, I want using it.  (It does not
   mean that I do not contribute to the community, I just have other
   ways/projects to do so.)

Robert


-- 
Róbert Čerňanský
E-mail: ope...@tightmail.com
Jabber: h...@jabber.sk



Re: [gentoo-dev] Last rites: app-text/cuneiform

2013-03-24 Thread Róbert Čerňanský
On Sun, 24 Mar 2013 08:40:17 -0400
Rich Freeman ri...@gentoo.org wrote:

 On Sun, Mar 24, 2013 at 8:31 AM, Markos Chandras
 hwoar...@gentoo.org wrote:
  I don't mind adding that link to every package mask. Do note thought
  that this is not the only way for a package to be rescued (assuming
  it can be rescued). Providing fixes without becoming the maintainer
  is also a viable solution, which is probably something we need to
  add to that page as well.
 
 I started something at:
 http://dev.gentoo.org/~rich0/treeclean.txt

It is relief to see that someone is trying to listen and do something
constructive about this long standing problem.  However, with all due
respect, I do not think that the document will help very much.  I
think most users are aware of the possibilities they have to save a
package.  They just do not have will, time or priority to do so for a
particular package they are using (this fact is essential to accept in
order to understand the problem here).

What I have expressed in rather theatrical way in my previous mail, is
the fact that unresolved bugs contributes to the package removal.
This may lead to _not_ reporting a bugs on purpose in order to lower
the possibility that the package will be removed.  I may say that I am
afraid to submit a bug for some packages and for some cases I
willingly do not report any for the very same reason.  Sad but true.

How it can be mitigated?  In my opinion by applying 30 days removal
policy only to packages that are completely broken.  So packages that
-- according to current policy -- would have been 30d masked for
removal, would be _just masked_ (no 30d removal).  This has following
advantages:

1. Users can submit as many bugs as they want without being afraid
   that it will contribute to removal of the package.  Documented bugs
   are better than hidden bugs.

2. Users can still use the package while being aware that it is
   partially broken.  They can find known bugs in bugzilla.

3. Users can still submit new bugs or workarounds to existing bugs.

4. Users can submit patches, effectively maintain the package even no
   official proxy maintainer was established.  (If from time to time
   some dev would bring provided patches to the tree, even better.)

5. Since the mask period will be likely longer than 30d there is a
   bigger chance that someone will take proxy/maintainership, or that
   someone will submit provided patches to the upstream.  Even users
   or devs that usually do not have will, time or priority to take
   care of the particular package could find some -- e. g. during
   summer or so -- and provide a patch.

During the mask period Gentoo will basically be providing just the
infrastructure.

Sorry that I am addressing the policy here even you explicitly said in
the document not to do so.  I will not make this post longer than it
is in trying to explain why I am doing it.  I just hope you (and other
devs) will try to listen.

Robert


-- 
Róbert Čerňanský
E-mail: ope...@tightmail.com
Jabber: h...@jabber.sk



Re: [gentoo-dev] RFC Bugzilla interaction guide for devs editbugs users

2010-09-07 Thread Róbert Čerňanský
On Mon, 6 Sep 2010 08:32:16 +
Robin H. Johnson robb...@gentoo.org wrote:

[...]
 2. Special cases

As a user I'd like to see following:

2.3. Upstream issues
   Do not close a bug (as RESOLVED/UPSTREAM) until it is fixed by
   upstream.

Robert


-- 
Robert Cernansky
E-mail: hslis...@zoznam.sk
Jabber: h...@jabber.sk


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: News item announcing as-needed (glep 42 stuff)

2010-07-27 Thread Róbert Čerňanský
On Mon, 26 Jul 2010 21:38:05 -0600
Ryan Hill dirtye...@gentoo.org wrote:

 it is recommended to use LDFLAGS=${LDFLAGS} your flags instead to

Is it not a comma required between ${LDFLAGS} and your flags?

LDFLAGS=${LDFLAGS},your flags

Robert


-- 
Robert Cernansky
E-mail: hslis...@zoznam.sk
Jabber: h...@jabber.sk


signature.asc
Description: PGP signature


Re: [gentoo-dev] Last rites: www-plugins/noscript

2010-04-18 Thread Róbert Čerňanský
On Sun, 18 Apr 2010 21:16:25 +0200
volk...@gentoo.org wrote:

 # Mounir Lamouri volk...@gentoo.org (18 Apr 2010)
 # The add-on/extension manager should now be used instead of the
 package # from the tree, bug 315999. Masked for removal in 30 days.
 www-plugins/noscript

How unfortunate. Does the add-on/extension manager provides system-wide
install option? Or what is the recomended way to manage system-wide
installation of noscript insead of using emerge?

Robert


-- 
Robert Cernansky
E-mail: hslis...@zoznam.sk
Jabber: h...@jabber.sk



Re: [gentoo-dev] Re: [gentoo-council] pkg_pretend USE validation and VALID_USE alternative

2010-04-01 Thread Róbert Čerňanský
On Wed, 31 Mar 2010 03:46:47 -0700
Brian Harring ferri...@gmail.com wrote:

 
 On Wed, Mar 31, 2010 at 11:48:37AM +0200, Ulrich Mueller wrote:
   On Wed, 31 Mar 2010, Brian Harring wrote:
  
  | Occasionally, ebuilds will have conflicting USE flags for
  | functionality. Checking for them and returning an error is not a
  | viable solution. Instead, you must pick one of the USE flags in
  | conflict to favour.
  
  [1] http://devmanual.gentoo.org/general-concepts/use-flags/
 
 I honestly consider the ebuild silently making decisions on the user's
 behalf *worse*.  Consider if openoffice silently made decisions like 
 that- 4 hours later it'll wind up choosing the option you didn't 
 really want and you'll be in a foul mood.

If I'm getting this right the proposed behavior is such that in case of
conflicting use flags emerge fails and user gets a message that he
has to set use flags as required. If so then I think it is not the right
way to handle it. A package manager should be able do deal with (use
flag) dependencies automatically. Similarly as it deals with normal
package dependenicies.

It should not do this silenly though. emerge -pv should display real
state of use flags; so if some use flag has to be turned on
automatically due to dependency/conflict then it has to be shown so.

This apply also for package[use_flag] deps. It is not very convenient
to fiddle use flags for individual packages that I basically do not care
about because they are just dependencies; so natural expectation is
that package manager pulls required deps. automatically (whether it
means install a package or install a package _with_ switched use flag).

I hope this does not sound that I'm dictating you what is the right way
to do things. I just wanted to express my opinion. And I admit that
perhaps I do not see possible negative consequences of such behaviour.

Regards,
Robert


-- 
Robert Cernansky
E-mail: hslis...@zoznam.sk
Jabber: h...@jabber.sk


signature.asc
Description: PGP signature


Re: [gentoo-dev] Low hanging bug fruit patterns

2010-03-09 Thread Róbert Čerňanský
On Tue, 9 Mar 2010 00:17:18 +0100
Jeroen Roovers j...@gentoo.org wrote:

 On Mon, 08 Mar 2010 14:13:30 +0100
 Róbert Čerňanský hslis...@zoznam.sk wrote:
 
  - Minor version bumps (After examination what upstream changed and
after confirmation with mantainer, if any.)
 
 The stuff you put in brackets is exactly the sort of stuff that
 tends to make version bumps hard to fix.
 
 You would first have to determine what major/minor means, on a per
 package-version basis, so these aren't really as trivial to fix as
 (non) package maintainer as a minor version change might suggest.

Yes, one needs to be carefull when doing even minor version bump. And
after examination of changes one can decide to do the bump or leave it
because it looks too risky. I'm sure there are upstream releases that
contains only bug fixes and it can be relatively easy determined by
looking into NEWS, Changelog or similar files.

After all, the examination should not exceed 1 day of effort (Sebastian
wrote that it should not take days to fix). So if we say that 1 day
is still less than days then I think it is plenty of time to examine
upstream changes. But maybe 1 day is too much for low hanging fruits
so let's say 2 hours is acceptable. In that time it should be possible
to fully examine changes. Which means read the changelogs, do some
internet search (upstream and other distros bugzillas) and even take a
peek to the source code.

 Also, any version bump is a splendid occasion on which to revise the
 ebuild (introduce missing features, check for novel QA issues, move up
 an EAPI to cut out a few build phases, review COPYING to make sure
 the LICENSE variable is still OK, figure out that one slight syntax
 change might serve to fix a compilation error with a
 newer-toolchain-than-you-use).

It still can be done at another time after bump; which is maybe even
better because it could be easily distinguished whether potencial new
bugs were caused by the bump or by ebuild enhancement changes.

Also I think that the overall quality of a package is increased if it
is just bumped to the new minor/bugfix upstream release and ebuild
stays at the same quality level as before. Compared to staying at the
older upstream version and also with the same ebuild because nobody has
time to do bump with ebuild enhacement.

 So I generally don't regard a version bump as a low hanging fruit,
 as you might end up painfully ignoring the wasps' nest hanging
 directly beside it.

Cenrtailny not in general. So let's say it is low hanging fruit at
which you have to stare for a while and look at it from all sides
before you pick it up. ;-)

Robert


-- 
Robert Cernansky
E-mail: hslis...@zoznam.sk
Jabber: h...@jabber.sk



Re: [gentoo-dev] Low hanging bug fruit patterns

2010-03-08 Thread Róbert Čerňanský
On Mon, 08 Mar 2010 11:06:40 +0100
Sebastian Pipping sp...@gentoo.org wrote:

 There are a few patterns for potentially low hanging fruits among
 Gentoo bugs:
 
   SRC_URI errors
   Missing depencies

(Sorry for answering a developer targeted question while I'm not one.)

- Minor version bumps (After examination what upstream changed and
  after confirmation with mantainer, if any.)

And perhaps also:
- Stable requests
- New ebuilds


Robert

-- 
Robert Cernansky
E-mail: hslis...@zoznam.sk
Jabber: h...@jabber.sk