Re: [gentoo-portage-dev] Speeding up Tree Verification

2020-06-30 Thread Pacho Ramos
El mar, 30-06-2020 a las 08:20 +0200, Fabian Groffen escribió:
> Hi,
> 
> On 29-06-2020 21:13:43 -0500, Sid Spry wrote:
> > Hello,
> > 
> > I have some runnable pseudocode outlining a faster tree verification
> > algorithm.
> > Before I create patches I'd like to see if there is any guidance on making
> > the
> > changes as unobtrusive as possible. If the radical change in algorithm is
> > acceptable I can work on adding the changes.
> > 
> > Instead of composing any kind of structured data out of the portage tree my
> > algorithm just lists all files and then optionally batches them out to
> > threads.
> > There is a noticeable speedup by eliding the tree traversal operations which
> > can be seen when running the algorithm with a single thread and comparing it
> > to
> > the current algorithm in gemato (which should still be discussed here?).
> 
> I remember something that gemato used to use multiple threads, but
> because it totally saturated disk-IO, it was brought back to a single
> thread.  People were complaining about unusable systems.
> 
> In any case, can you share your performance results?  What speedup did
> you see, on warm and hot FS caches?  Which type of disk do you use?
> 
> You could compare against qmanifest, which uses OpenMP-based
> paralllelism while verifying the tree.  On SSDs this does help.
> 
> Thanks,
> Fabian

I am talking only based on my own experience but, at least on my case, there are
noticeable differences between I/O schedulers. That is something that maybe
could affect that tests... with latest kernels we only have noop, deadline
(default) and bfq... in my case bfq works far better for keeping the system
responsible (on both, rotational and SSDs). But you can test different
combinations to see the one that fits better for you.



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


Re: [gentoo-portage-dev] [PATCH] repoman: add --include-profiles=PROFILES

2019-11-19 Thread Pacho Ramos
El mar, 19-11-2019 a las 00:21 +, Sergei Trofimovich escribió:
> repoman slows down ~linearly with amount of profiles being scanned.
> In case of amd64 we have 28 stable profiles.
> 
> To speed up processing and fit into time budged of various CIs we can
> split the work across different processes that handle different profiles.
> 
> Example benchmark on ::haskell overlay:
> $ ./repoman full --include-arches=amd64
> ~65 minutes
> $ ./repoman full --include-profiles=default/linux/amd64/17.0
> ~4 minutes
> This allows for a crude sharding of work across processes and allows for
> cheap tree-wide scans for early failures.
> 

Just for knowing (as I guess there is a technical issue preventing that), why
repoman is not trying to check one profile per core in parallel by default by
itself?

Thanks a lot for the info :)


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


Re: [gentoo-portage-dev] [PATCH 1/3] emerge: Deprecate --autounmask

2014-01-19 Thread Pacho Ramos
El dom, 19-01-2014 a las 01:21 +0100, Alexander Berntsen escribió:
 Remove the --autounmask option from emerge. Please note that removing
 the option does not mean that the variable used for keeping track of
 autounmasking is not removed from depgraph.py.

If I understand the change correctly (I don't know much about python
but, but per the diff, looks like you are dropping the option and making
the code behave like it's always 'True'), seems that you are forcing
autounmask to be on always.

Even if I use this in all my systems (passing it in by default emerge
opts), I think we still need a way to disable it sometimes. For example,
I need that when portage shows me really strange error messages. I
remember this was an old bug related with backtracking, but can't find
it just now (it should contains quite a few duplicates) :S

I am referring to that kind of errors that reports the wrong package as
being the culprit of some conflict 




Re: [gentoo-portage-dev] [PATCH 1/3] emerge: Deprecate --autounmask

2014-01-19 Thread Pacho Ramos
El dom, 19-01-2014 a las 11:23 +0100, Alexander Berntsen escribió:
 On 19/01/14 09:01, Pacho Ramos wrote:
  If I understand the change correctly (I don't know much about
  python but, but per the diff, looks like you are dropping the
  option and making the code behave like it's always 'True'), seems
  that you are forcing autounmask to be on always.
 You do not understand it correctly. It makes --ask imply
 --autounmask-write.

Ah, nice :)

 
  Even if I use this in all my systems (passing it in by default 
  emerge opts), I think we still need a way to disable it sometimes.
 There is. Regardless of whether you mean (current) --autounmask or
 (current) --autounmask-write behaviour.
 
 emerge --ask foo # This won't -write
 emerge --autounmask --pretend foo # Same as the above
 emerge --ask --pretend foo # This won't even offer the suggestions
 
 Please see [0] for more information.
 
 [0]  https://bugs.gentoo.org/show_bug.cgi?id=481578#c10

Then, I guess -ap would be the equivalent of --autounmask=n and should
behave in the same way, right? In that case, no problem (even if I think
we should document this since using --ask --pretend at the same time
doesn't look so intuitive to me :( )




Zac's status (Was: Re: [gentoo-portage-dev] [PATCHES] Remove --autounmask, rename --autounmask-write to --autounmask)

2013-11-21 Thread Pacho Ramos
El jue, 21-11-2013 a las 10:21 +0100, Alexander Berntsen escribió:
 I sent this to zmedico almost two months ago, but it doesn't look like
 he's coming back any time soon, so I'm sending it here and ask someone
 to review and commit it (a role zmedico has typically played for me,
 as well as being my mentor and guide and so on and so forth for
 Portage hacking).
 
 [0]  https://bugs.gentoo.org/show_bug.cgi?id=481578
 [1]  https://bugs.gentoo.org/show_bug.cgi?id=481578#c10

Does anyone know what did occur to Zac? I expect it's not a major
problem or similar :'(




[gentoo-portage-dev] A way for trying to prevent useless rebuilds

2013-07-25 Thread Pacho Ramos
This question comes to my mind every time a developer decides to
drop/add a USE flag to ebuilds like gcc/webkit-gtk/libreoffice... 

I think that we should have a file (like used for category movements) to
let PM know how to handle this situation. 

For example, 
category/foo-1.0 has a gnome USE flag but, later, that one is dropped:
- If it is now *enabling* that support always, our file could have
something like:
category/foo gnome + - that would mean that, when gnome USE flag is
NOT found, portage assumes it as being enabled, that will mean that
people having previously gnome enabled wouldn't need to rebuild the
package

... and the opposite

What do you think?

Thanks




Re: [gentoo-portage-dev] A way for trying to prevent useless rebuilds

2013-07-25 Thread Pacho Ramos
El jue, 25-07-2013 a las 12:00 -0700, Zac Medico escribió:
 On 07/25/2013 11:54 AM, Pacho Ramos wrote:
  This question comes to my mind every time a developer decides to
  drop/add a USE flag to ebuilds like gcc/webkit-gtk/libreoffice... 
  
  I think that we should have a file (like used for category movements) to
  let PM know how to handle this situation. 
  
  For example, 
  category/foo-1.0 has a gnome USE flag but, later, that one is dropped:
  - If it is now *enabling* that support always, our file could have
  something like:
  category/foo gnome + - that would mean that, when gnome USE flag is
  NOT found, portage assumes it as being enabled, that will mean that
  people having previously gnome enabled wouldn't need to rebuild the
  package
  
  ... and the opposite
  
  What do you think?
 
 We could do something like that. You should propose it in the gentoo-pms
 list.

OK, wanted to be sure a similar idea wasn't rejected before :)




Re: [gentoo-portage-dev] A way for trying to prevent useless rebuilds

2013-07-25 Thread Pacho Ramos
El vie, 26-07-2013 a las 02:47 +0300, Alex Alexander escribió:
 I once half-implemented something like this but never got to finish
 it, I'll try to dig up my code and check out its state.
 
 
 I recall using updates/ to tell portage what happened, which then
 updated the VDB to reflect the new state.
 

I have opened this same thread in pms-list, if you are able to forward
that code there, would be highly appreciated :)





Re: [gentoo-portage-dev] emerge @preserved-rebuild not rebuilding all broken packages after udev update

2013-02-20 Thread Pacho Ramos
El mar, 19-02-2013 a las 14:27 -0800, Zac Medico escribió:
 On 02/19/2013 12:12 PM, Pacho Ramos wrote:
  Hello
  
  For some time I am running portage-2.1.x with preserve-libs enabled to
  test it and try to prevent revdep-rebuild usage. Until now, I haven't
  had any problems with it, but I started to test it after being running
  udev-19x for a long time. Yesterday, my father mailed me because he got
  udev update from 17x to 19x and emerge @preserved-rebuild only rebuilt
  gcc, keeping other broken packages untouched (while revdep-rebuild
  rebuilt them)
  
  Do you know what kind of information could I demand him to help diagnose
  the problem?
 
 It only works if the broken packages have references to the libudev.so.0
 (or maybe libgudev-1.0.so.0) soname in their
 /var/db/pkg/*/*/NEEDED.ELF.2 files.

Will need to recheck in next breakage then :/

Any suggestion about how to proceed when I hit this kind of problem? (I
mean, what can I provide you to try to fix this cases)

Thanks


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


[gentoo-portage-dev] emerge @preserved-rebuild not rebuilding all broken packages after udev update

2013-02-19 Thread Pacho Ramos
Hello

For some time I am running portage-2.1.x with preserve-libs enabled to
test it and try to prevent revdep-rebuild usage. Until now, I haven't
had any problems with it, but I started to test it after being running
udev-19x for a long time. Yesterday, my father mailed me because he got
udev update from 17x to 19x and emerge @preserved-rebuild only rebuilt
gcc, keeping other broken packages untouched (while revdep-rebuild
rebuilt them)

Do you know what kind of information could I demand him to help diagnose
the problem?

Thanks a lot


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


[gentoo-portage-dev] A way to prevent useless rebuild?

2013-01-20 Thread Pacho Ramos
I noticed go USE flag was masked on gcc:4.6, the problem is that I
just compiled it a week ago with USE=-go... then, I would like to know
if there is a way to prevent it from being rebuild again :| (It will
take some time in my currently running system but on other machines I
maintain it will take hours)

For the future, wouldn't be possible (probably on a new eapi) to
indicate in some way to the package manager that:
(masked USE flag) is equivalent to (-USE flag) or (+USE flag)?

Maybe some indication in profiles masking file like:
$(category)/$(package) go (-go) - it would indicate that, if version to
be rebuild was compiled with -go, no rebuilding is really needed

What do you think?

Thanks a lot


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


[gentoo-portage-dev] About adding a repoman check to test for missing files in FILESDIR

2012-10-08 Thread Pacho Ramos
Hello

Sometime ago this was already discussed but, if I don't misremember, it
was hard to implement a check for repoman to prevent us from forgetting
to commit new patches. Maybe the check could simply check if all
${FILESDIR} files are present? The idea is that it could simply check
of that files existence, if they are not present, show a warn (not a
hard warn as it could be a false positive I guess). Regarding that
file not being added to cvs tree, it doesn't show so much problems as
that error is already shown at commit time (file present but not added
to cvs)

Thanks


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


Re: [gentoo-portage-dev] About adding a repoman check to test for missing files in FILESDIR

2012-10-08 Thread Pacho Ramos
El lun, 08-10-2012 a las 11:32 -0700, Zac Medico escribió:
 On 10/08/2012 11:26 AM, Pacho Ramos wrote:
  Hello
  
  Sometime ago this was already discussed but, if I don't misremember, it
  was hard to implement a check for repoman to prevent us from forgetting
  to commit new patches. Maybe the check could simply check if all
  ${FILESDIR} files are present? The idea is that it could simply check
  of that files existence, if they are not present, show a warn (not a
  hard warn as it could be a false positive I guess). Regarding that
  file not being added to cvs tree, it doesn't show so much problems as
  that error is already shown at commit time (file present but not added
  to cvs)
 
 Given the expressiveness of the bash language, it's really a non-trivial
 thing to check without actually executing bash. See discussion here:
 
   https://bugs.gentoo.org/show_bug.cgi?id=431196

Then, maybe I could have a custom repoman script that would check for
them in my files/ directory (either using bash to check for them or
simply running ls)  :/


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


Re: [gentoo-portage-dev] Try to specify how to get that a USE flag is present in current ebuild

2012-10-05 Thread Pacho Ramos
El dom, 23-09-2012 a las 09:36 +0200, Pacho Ramos escribió:
 El dom, 23-09-2012 a las 05:52 +, Alec Warner escribió:
  On Sat, Sep 22, 2012 at 7:22 PM, Pacho Ramos pa...@gentoo.org wrote:
   El sáb, 22-09-2012 a las 13:54 -0400, Mike Frysinger escribió:
   On Friday 21 September 2012 15:08:20 Pacho Ramos wrote:
In that one, we try to use the following:
has vala ${IUSE//+/}  ! use vala  return 0
  
   inherit eutils
   use_if_iuse vala
   -mike
  
   I am aware of that one also, but Ciaran also wants to forbid it for the
   same reason :S
  
  Well I assume Ciaran wants to forbid it because he is attempting to
  write a PMS compliant PM; but in order to use these ebuilds properly
  he has to emulate the unspecified behavior that the ebuilds rely on
  upon. His claim is that the council is supposed to forbid this
  behavior (presumably to make his job less horrible) but I don't see
  them beating down your door to change it (and the behavior is not
  new.)
  
  -A
  
  
 
 My point of view is that, as this is already supported in portage (and
 probably in other PMs as, otherwise, they would have had a lot of
 problems with, for example, a lot of packages inheritting important
 eclasses like gnome2, cmake-utils or xorg-2) and also used in the tree
 for years, the easiest solution is to simply specify current behavior
 for existing eapis, needing to wait for a new one to change that
 behavior.
 
 As I pointed in http://www.gossamer-threads.com/lists/gentoo/dev/260662
 other options would be:
 - wait for next eapi to specify that, the problem is that, if that eapi
 take a long time to be approved, we would need to move all
 eclasses/ebuilds to the other non-automatic way to later revert 
 them back.
 - include this specification in eapi5 as it's still not allowed in the
 tree (maybe for this a council meeting should be soon enough I guess)
 

As looks like this topic got stalled :(, not sure how hard would be to
implement (and document for PMS) the IUSE_FLATTENED idea over current
portage implementation:
http://www.gossamer-threads.com/lists/gentoo/dev/260812#260812


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


Re: [gentoo-portage-dev] How to prevent dispatch-conf from reverting valid changes

2012-09-27 Thread Pacho Ramos
El dom, 23-09-2012 a las 11:06 -0700, Zac Medico escribió:
 On 09/23/2012 03:59 AM, Pacho Ramos wrote:
  This looks like could be done with:
  # Automerge files comprising only whitespace and/or comments
  # (yes or no)
  replace-wscomments=no
  
  , setting it to yes in dispatch-conf.conf
 
 It seems like that option is only likely to benefit people who have
 disabled the default config-protect-if-modified FEATURES setting, and
 I'm not sure that it's a good idea to hide trivial differences from
 these people by default.

Would be a way to detect changes like 0 to 1 or false - true,
yes - no... ? I think they usually shouldn't be changed :|


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


Re: [gentoo-portage-dev] How to prevent dispatch-conf from reverting valid changes

2012-09-27 Thread Pacho Ramos
El jue, 27-09-2012 a las 13:21 -0700, Zac Medico escribió:
 On 09/27/2012 01:16 PM, Pacho Ramos wrote:
  El dom, 23-09-2012 a las 11:06 -0700, Zac Medico escribió:
  On 09/23/2012 03:59 AM, Pacho Ramos wrote:
  This looks like could be done with:
  # Automerge files comprising only whitespace and/or comments
  # (yes or no)
  replace-wscomments=no
 
  , setting it to yes in dispatch-conf.conf
 
  It seems like that option is only likely to benefit people who have
  disabled the default config-protect-if-modified FEATURES setting, and
  I'm not sure that it's a good idea to hide trivial differences from
  these people by default.
  
  Would be a way to detect changes like 0 to 1 or false - true,
  yes - no... ? I think they usually shouldn't be changed :|
 
 I'm not sure what problem you're trying to solve. Since enabling
 FEATURES=config-protect-if-modified, I've found the volume of config
 updates to be much more manageable, and the configs that I do have to
 merge manually don't really bother me.

Well, I hit the problem when updating from stable openrc to 0.10.5 and
needing to reedit some config files as, as normal, I had uncommented
some options, modified some defaults... (like keymap, clock settings...)


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


Re: [gentoo-portage-dev] Try to specify how to get that a USE flag is present in current ebuild

2012-09-23 Thread Pacho Ramos
El dom, 23-09-2012 a las 05:52 +, Alec Warner escribió:
 On Sat, Sep 22, 2012 at 7:22 PM, Pacho Ramos pa...@gentoo.org wrote:
  El sáb, 22-09-2012 a las 13:54 -0400, Mike Frysinger escribió:
  On Friday 21 September 2012 15:08:20 Pacho Ramos wrote:
   In that one, we try to use the following:
   has vala ${IUSE//+/}  ! use vala  return 0
 
  inherit eutils
  use_if_iuse vala
  -mike
 
  I am aware of that one also, but Ciaran also wants to forbid it for the
  same reason :S
 
 Well I assume Ciaran wants to forbid it because he is attempting to
 write a PMS compliant PM; but in order to use these ebuilds properly
 he has to emulate the unspecified behavior that the ebuilds rely on
 upon. His claim is that the council is supposed to forbid this
 behavior (presumably to make his job less horrible) but I don't see
 them beating down your door to change it (and the behavior is not
 new.)
 
 -A
 
 

My point of view is that, as this is already supported in portage (and
probably in other PMs as, otherwise, they would have had a lot of
problems with, for example, a lot of packages inheritting important
eclasses like gnome2, cmake-utils or xorg-2) and also used in the tree
for years, the easiest solution is to simply specify current behavior
for existing eapis, needing to wait for a new one to change that
behavior.

As I pointed in http://www.gossamer-threads.com/lists/gentoo/dev/260662
other options would be:
- wait for next eapi to specify that, the problem is that, if that eapi
take a long time to be approved, we would need to move all
eclasses/ebuilds to the other non-automatic way to later revert 
them back.
- include this specification in eapi5 as it's still not allowed in the
tree (maybe for this a council meeting should be soon enough I guess)



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


Re: [gentoo-portage-dev] How to prevent dispatch-conf from reverting valid changes

2012-09-23 Thread Pacho Ramos
El mié, 12-09-2012 a las 22:05 +0200, Pacho Ramos escribió:
 El jue, 02-08-2012 a las 15:56 -0700, Zac Medico escribió:
  On 08/01/2012 03:19 AM, Pacho Ramos wrote:
   On every openrc update I get dispatch-conf wanting to revert all my
   changes in /etc/conf.d files, like KEYMAP, clock...
   
   Is there any way to prevent it from doing that?
   
   Thanks a lot for the info
   
  
  Maybe you want to add those config files to frozen-files in
  /etc/dispatch-conf.conf.
  
 
 The problem is that I don't really want to have that files frozen (as
 they could need important changes in future versions). What I expect if
 dispatch-conf to skip changes like changing an uncommented line with a
 commented line, 

This looks like could be done with:
# Automerge files comprising only whitespace and/or comments
# (yes or no)
replace-wscomments=no

, setting it to yes in dispatch-conf.conf

 or changing YES to NO... but it's probably difficult
 to detect :|




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


Re: [gentoo-portage-dev] Try to specify how to get that a USE flag is present in current ebuild

2012-09-21 Thread Pacho Ramos
El vie, 21-09-2012 a las 12:45 -0700, Zac Medico escribió:
 On 09/21/2012 12:08 PM, Pacho Ramos wrote:
  Hello
  
  This comes from this gentoo-dev thread:
  http://www.gossamer-threads.com/lists/gentoo/dev/260536
  
  In that one, we try to use the following:
  has vala ${IUSE//+/}  ! use vala  return 0 
  
  as already done in many eclasses/ebuilds. The problem is that Ciaran
  wants to forbid it because he says it's not specified in PMS. My
  suggestion was to simply specify it as it's currently implemented in
  portage because that functionality is (apart of needed) being used for a
  long time in the tree by numerous eclasses/ebuilds, then, from my point
  of view, wouldn't be any sense on lose time for moving them to current
  functionality to a worse one, wait for the next eapi and, finally,
  revert them back to current behavior.
  
  The problem is that I cannot find any doc about how this is currently
  handled in portage. Could you help me on it please?
 
 That `has vala ${IUSE//+/}` thing should work for all versions of
 portage that have existed since PMS came around. The way that it works
 is that that ebuild.sh sources the ebuild, and the inherit function
 makes temporary backups of IUSE so that the IUSE settings from all of
 the eclasses and the ebuild can be stacked together after the sourcing
 is complete. The stacked IUSE value that's generated then remains in the
 ebuild's environment for all phases.

Thanks a lot, do you let me send your reply to gentoo-dev ML?


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


Re: [gentoo-portage-dev] How to prevent dispatch-conf from reverting valid changes

2012-09-12 Thread Pacho Ramos
El jue, 02-08-2012 a las 12:34 -0700, Zac Medico escribió:
 On 08/01/2012 11:36 PM, Pacho Ramos wrote:
  El mié, 01-08-2012 a las 16:14 -0700, Zac Medico escribió:
  On 08/01/2012 03:19 AM, Pacho Ramos wrote:
  On every openrc update I get dispatch-conf wanting to revert all my
  changes in /etc/conf.d files, like KEYMAP, clock...
 
  Is there any way to prevent it from doing that?
 
  Thanks a lot for the info
 
 
  Maybe we can trace the behavior back to the diff3 command that it's
  using. Inside /usr/lib/portage/pym/portage/dispatch_conf.py we have this
  command:
 
DIFF3_MERGE = diff3 -mE '%s' '%s' '%s'  '%s'
 
  Are you able to reproduce the problem by running this command manually?
 
  Something like this:
 
 diff3 -mR /etc/conf.d/hostname \
 /etc/config-archive/etc/conf.d/hostname.dist  \
 /etc/conf.d/._cfg_hostname  /tmp/mrgconf
  
  I will probably need to reemerge it as I already merged changes and
  re-edited config files. Anyway, diff3 looks to not admit -R option:
  $ diff3
  -mR /etc/conf.d/hostname /etc/config-archive/etc/conf.d/hostname.dist 
  /etc/conf.d/._cfg_hostname
  diff3: opción inválida -- R
  diff3: Pruebe `diff3 --help' para más información.
 
 Sorry, that -mR a typo. As you can see in the DIFF3_MERGE value above,
 it's diff -mE.

Will try on next openrc update :)


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


[gentoo-portage-dev] How to prevent dispatch-conf from reverting valid changes

2012-08-01 Thread Pacho Ramos
On every openrc update I get dispatch-conf wanting to revert all my
changes in /etc/conf.d files, like KEYMAP, clock...

Is there any way to prevent it from doing that?

Thanks a lot for the info


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


Re: [gentoo-portage-dev] About forcing rebuilds of other packages issue

2012-06-04 Thread Pacho Ramos
El lun, 04-06-2012 a las 13:44 -0700, Zac Medico escribió:
 On 06/04/2012 04:57 AM, Pacho Ramos wrote:
  - Looks like there is no consensus about what to do and, then, this
  could probably be implemented on eapi... 7? While former could probably
  be implemented much sooner (probably even in eapi5) 
 
 Ciaran has been advocating SLOT operator dependencies for this, but
 those are not designed to work with unslotted packages, which leads to
 the issues discussed in bug 414955:
 
   https://bugs.gentoo.org/show_bug.cgi?id=414955#c10
 
 The gentoo-dev mailing list would be a better place to discuss this,
 since this issue affects the whole developer community.

Just sent to gentoo-dev ;)


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


[gentoo-portage-dev] Is there any short syntax for REQUIRED_USE when a lot of USE flags need another one enabled?

2011-12-17 Thread Pacho Ramos
I am referring in this case to abiword, it has a plugins USE flag that
enables some minimal set of plugins and, then, a lot of USE flags for
building extra plugins (with extra dependencies). All of this extra
plugins need plugins USE flag to be enabled. Is there any way to write
a REQUIRED_USE flag variable without needing to list all USE flags
depending on plugins to be set?

Thanks a lot for the info :)


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


[gentoo-portage-dev] How to make portage create /var/log/portage/ with portage:portage owners?

2011-11-01 Thread Pacho Ramos
I have user pacho under portage group to be able to make some tasks
without becoming root, but, sadly, I am unable to make portage
create /var/log/portage files/dirs with portage:portage owners instead
of portage:root, preventing me from removing old files without becoming
root.
Is there anyway to configure this?

Thanks a lot


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


Re: [gentoo-portage-dev] About how to make compilation think some files are missing

2011-02-13 Thread Pacho Ramos
El sáb, 12-02-2011 a las 15:43 -0800, Zac Medico escribió:
 On 02/12/2011 07:50 AM, Pacho Ramos wrote:
  This comes from glitz removal (bug #330397), as soon as cairo-1.10 gets
  stabilized, depclean will try to remove glitz, but removing glitz will
  break a lot of apps, needing to rebuild them and, until then, having a
  partially broken system.
  
  I then thought on running revdep-rebuild --library libglitz-glx.so.1
  BEFORE removing glitz (to prevent breakage), but later I remembered it
  wouldn't work as rebuilt packages would link again against
  libglitz-glx.so.1.
  
  Then, my idea would the following:
  
  Would be nice if I could tell portage to make compilation think
  libglitz-glx.so.1 is not present in real system (maybe sandbox could
  prevent its readability inside build environment), and then, I could run
  revdep-rebuild --library libglitz-glx.so.1 before removing glitz and
  affected apps would not link to it, allowing me to safely remove glitz
  later without having had  a broken system at any time.
  
  What do you think? Thanks
 
 Ideally, the build system(s) involved would have options to explicitly
 disable linking against the deprecated library.
 
 Barring that possibility, something like your sandbox idea seems like
 the second-best solution.
 
 On par with the the sandbox idea would be to migrate the deprecated
 library to a directory which is not included in the default library
 search path, and to use a global LD_LIBRARY_PATH setting so that your
 apps can find it until they are rebuilt. Then you could execute your
 rebuilds in an environment with a modified LD_LIBRARY_PATH value that
 excludes the path of the deprecated library.

Didn't think about that last LD_LIBRARY_PATH option, looks easier for
now. Thanks


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


[gentoo-portage-dev] About how to make compilation think some files are missing

2011-02-12 Thread Pacho Ramos
This comes from glitz removal (bug #330397), as soon as cairo-1.10 gets
stabilized, depclean will try to remove glitz, but removing glitz will
break a lot of apps, needing to rebuild them and, until then, having a
partially broken system.

I then thought on running revdep-rebuild --library libglitz-glx.so.1
BEFORE removing glitz (to prevent breakage), but later I remembered it
wouldn't work as rebuilt packages would link again against
libglitz-glx.so.1.

Then, my idea would the following:

Would be nice if I could tell portage to make compilation think
libglitz-glx.so.1 is not present in real system (maybe sandbox could
prevent its readability inside build environment), and then, I could run
revdep-rebuild --library libglitz-glx.so.1 before removing glitz and
affected apps would not link to it, allowing me to safely remove glitz
later without having had  a broken system at any time.

What do you think? Thanks


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


Re: [gentoo-portage-dev] About how to make compilation think some files are missing

2011-02-12 Thread Pacho Ramos
El sáb, 12-02-2011 a las 18:22 +0100, Martin Doucha escribió:
 Dne 12.2.2011 16:50, Pacho Ramos napsal(a):
  Then, my idea would the following:
 
  Would be nice if I could tell portage to make compilation think
  libglitz-glx.so.1 is not present in real system (maybe sandbox could
  prevent its readability inside build environment), and then, I could run
  revdep-rebuild --library libglitz-glx.so.1 before removing glitz and
  affected apps would not link to it, allowing me to safely remove glitz
  later without having had  a broken system at any time.
 
  What do you think? Thanks
 
 I think you want to update to portage-2.2 (you need to unmask it
 manually). It does exactly what you want in this case.
 
 Regards,
 Martin Doucha
 
 

I am not sure if portage-2.2 would also cover this case: in this
example, the problem appears because of people uninstalling
*intentionally*  media-libs/glitz (as it's no longer needed)


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


[gentoo-portage-dev] Is there a way to skip tests even having FEATURES=test in make.conf?

2010-08-31 Thread Pacho Ramos
Hello

Let me explain my problem:

I have just returned to my home and, then, I have a lot of packages to
update when running emerge -avuDN world. The problem is that I have
FEATURES=test enabled in my make.conf and, since some of them take years
to run, I would like to temporally make portage skip them.

I have tried to simply disable that FEATURE temporally, but it causes
packages to change their USEs to -test having me to recompile them
later again.

Thanks a lot for your help :-)



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


Re: [gentoo-portage-dev] Is there a way to skip tests even having FEATURES=test in make.conf?

2010-08-31 Thread Pacho Ramos
El mar, 31-08-2010 a las 08:03 -0700, Zac Medico escribió:
 On 08/31/2010 05:14 AM, Pacho Ramos wrote:
  Hello
  
  Let me explain my problem:
  
  I have just returned to my home and, then, I have a lot of packages to
  update when running emerge -avuDN world. The problem is that I have
  FEATURES=test enabled in my make.conf and, since some of them take years
  to run, I would like to temporally make portage skip them.
  
  I have tried to simply disable that FEATURE temporally, but it causes
  packages to change their USEs to -test having me to recompile them
  later again.
 
 In order to avoid that, a usually suggest to enable USE=test in
 make.conf so that it's enabled regardless of the FEATURES=test state.
 

Silly me! It was so simple... :-O, thanks a lot!

 BTW, in the latest 2.2_rc releases there's support for
 /etc/portage/package.env which can be used to enable or disable
 FEATURES=test for specific packages. The package.env support will
 also be included in portage-2.1.9 which I plan to release sometime
 this week.

Nice! Thanks a lot for your work (and for the work of other portage team
members of course)


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


[gentoo-portage-dev] Is there any way to stop compilation and resume it later (after a reboot)?

2010-02-19 Thread Pacho Ramos
Hello

This is a problem I get every time openoffice needs to be
recompiled :-S, it takes really a long time to do it (~10 hours) then,
sometimes I need to stop compilation for halting system and, then, I
need to start it again some different day.

Is there any way for stopping compilation and resume it later using
already compiled files?

Thanks a lot :-)


signature.asc
Description: Esta parte del mensaje está firmada digitalmente


Re: [gentoo-portage-dev] Is there any way to stop compilation and resume it later (after a reboot)?

2010-02-19 Thread Pacho Ramos
El vie, 19-02-2010 a las 11:09 -0500, Ghislain Bourgeois escribió:
 Hi,
 
 
 Best way I know is to use ccache and emerge --resume. But that is not
 exactly what you are asking for. 
 

I already use ccache and, even speeding it up, I still have to wait some
hours :-(

Another option could be to hibernate the system but, in some machines
hibernation doesn't even work

Best regards


signature.asc
Description: Esta parte del mensaje está firmada digitalmente


Re: [gentoo-portage-dev] Is there any way to stop compilation and resume it later (after a reboot)?

2010-02-19 Thread Pacho Ramos
El vie, 19-02-2010 a las 10:58 -0800, Zac Medico escribió:
 On 02/19/2010 08:44 AM, Pacho Ramos wrote:
  Another option could be to hibernate the system but, in some machines
  hibernation doesn't even work
 
 That might work but it's a little extreme. You might want to
 consider switching to openoffice-bin unless you can find a faster
 computer to build on. I have a 1.6 GHz core 2 duo and my last
 openoffice build took less than 2 hours.

I use openoffice over openoffice-bin because it's a bit different and
opens more exotic doc files :-/

If I don't misremember, when compiling manually I was able to press Ctrl
+C and, later, run again make and it continued, is not possible to do
that through emerge then? I mean, run src_compile phase from uncleaned
sources dir

Best regards


signature.asc
Description: Esta parte del mensaje está firmada digitalmente


[gentoo-portage-dev] Question about PDEPEND

2009-12-08 Thread Pacho Ramos
Hello

During today's review session with Petteri (due bug #284528) PDEPEND
question appeared about what really does it. I replied that it contains
dependencies that need to be installed after the package (as is shown in
http://devmanual.gentoo.org/general-concepts/dependencies/index.html )
but he told me that PDEPEND is really the same as RDEPEND with cycle
breaking. He also suggested me to ask portage devs about what it really
doing PDEPEND.

Now, after the session, I rechecked devmanual page and noticed that
after is in cursive (sorry for didn't noticing it before), also
googled a bit and found posts like:
http://blog.flameeyes.eu/2008/10/18/blurring-the-separation-between-rdepend-and-pdepend
http://help.lockergnome.com/linux/gentoo-dev-PDEPEND-behaviour--ftopict483842.html

that clearly show PDEPEND is not simply merge depends after the
package.

Then, if possible, I would highly appreciate a summary about what really
does PDEPEND. Of course, as I know portage devs are overloaded, if you
don't have time to reply, no problem at all :-)

Thanks a lot




Re: [gentoo-portage-dev] Question about PDEPEND

2009-12-08 Thread Pacho Ramos
El mar, 08-12-2009 a las 11:31 -0800, Zac Medico escribió:
 Pacho Ramos wrote:
  but he told me that PDEPEND is really the same as RDEPEND with cycle
  breaking.
 
 This is good description. It's handled the same as RDEPEND except
 when it can't due to circular dependencies. That means that it's
 installed before, just like RDEPEND, except when resolution of
 circular dependencies requires it to be installed after.

Fine, thanks a lot =)




[gentoo-portage-dev] official way for setting per package CFLAGS and FEATURES?

2009-07-18 Thread Pacho Ramos
Hello, I would want to always merge xorg-server, libdrm, and  intel
driver (that likes to crash a lot) to be always compiled with debugging
symbols and FEATURES=${FEATURES} splitdebug

Searching in google seems that there are some available hacks done by
some forums users, but they seem to be a bit old and, before trying
them, I would want to know if there is an official way of doing it.

Thanks a lot :-)





Re: [gentoo-portage-dev] Re: Recommendation about faster (not smaller) filesystem and blocksize combination for portage tree

2009-04-16 Thread Pacho Ramos
El lun, 30-03-2009 a las 16:30 +, Duncan escribió:
 Pacho Ramos pa...@condmat1.ciencias.uniovi.es posted
 1238412618.18113.15.ca...@localhost, excerpted below, on  Mon, 30 Mar 2009
 13:30:18 +0200:
 
  I am trying to know what filesystem+blocksize combination could be
  better for the kind of files stored in portage tree.
  
  In the past, I have been using reiserfs for my / partition and I had
  /usr/portage under it. Later, I moved /usr/portage to a different
  partition (distfiles go to a different directory) and switched it to
  ext2 (as, in theory, ext2 should be faster as has no journaling) and
  2048 as blocksize (that, of course, shrinks portage tree sizes but I am
  unsure about its effects from a performance point of view)
 
 You are aware of the various reiserfs mount options, including notail and 
 nolog, right?  See the mount manpage.  reiserfs was tuned for small 
 files, but these may speed it up even further.
 
 Other than that, much as I could suggest all sorts of stuff (like 
 PORTAGE_TMPDIR as tmpfs, will probably make more of a difference if you 
 have a decent amount of memory), I'll point you to the user forums and 
 list as more appropriate.  This list is really for discussion of portage 
 and portage related development, not so much user portage speed tips, but 
 ask in the user list and forums and you'll surely get all sorts of info! 
 =:^)
 

Thanks, finally seems that, in my case, reiserfs with nolog,noatime
works really fast and with a smaller size (thanks to tail) :-D

Best regards!




[gentoo-portage-dev] Recommendation about faster (not smaller) filesystem and blocksize combination for portage tree

2009-03-30 Thread Pacho Ramos
Hello

I am trying to know what filesystem+blocksize combination could be
better for the kind of files stored in portage tree.

In the past, I have been using reiserfs for my / partition and I
had /usr/portage under it. Later, I moved /usr/portage to a different
partition (distfiles go to a different directory) and switched it to
ext2 (as, in theory, ext2 should be faster as has no journaling) and
2048 as blocksize (that, of course, shrinks portage tree sizes but I am
unsure about its effects from a performance point of view)

Of course, I am not asking you for benchmarks or something else, I am
simply asking for your opinions about what would be better combination
from a performance point of view of filesystem+blocksize (or, at least,
what blocksize would be better for speed, I can test filesystems later
based on it)

Thanks a lot for your recommendations :-)





Re: [gentoo-portage-dev] emerge prefers to install x11-libs/qt:4 instead of ( x11-libs/qt-gui:4 x11-libs/qt-webkit:4 ) even when x11-libs/qt-gui:4 is already installed

2009-03-03 Thread Pacho Ramos
El mar, 03-03-2009 a las 11:25 -0800, Zac Medico escribió:
 
 You're right. It's easy to says it in words but if you tried to
 actually implementing you'd find that the PROPERTIES=virtual concept
 simplifies the problem a lot and makes it possible to optimally
 solve some cases of bug 141118 that couldn't otherwise be solved
 optimally without the information that PROPERTIES=virtual provides.
 
 What we're talking about is a cost calculation and in order for the
 cost calculation to be as accurate as possible, we need to know
 which ebuilds have zero-cost to install (the virtual ones do not
 install anything directly so they are considered to have zero-cost
 in themselves). If you consider all ebuilds to have equal cost then
 your calculation won't be as accurate as it could be. Knowing which
 ebuilds are virtual gives a hint to the resolver that it should
 perform a lookahead in the cost calculation.
 
 We could implement a similar lookahead mechanism for non-virtual
 ebuilds, but it's more useful for the virtual ones. Backtracking
 (which isn't implemented yet but is planned for bug 1343) would also
 be useful for implementing additional cost optimizations (like the
 one for bug 260225).
 - --
 Thanks,
 Zac

No problem. Thanks for the explanation :-)




[gentoo-portage-dev] emerge prefers to install x11-libs/qt:4 instead of ( x11-libs/qt-gui:4 x11-libs/qt-webkit:4 ) even when x11-libs/qt-gui:4 is already installed

2009-03-02 Thread Pacho Ramos
Hello

I have encountered this behavior with acetoneiso ebuild:
http://bugs.gentoo.org/show_bug.cgi?id=197961

the current ebuild in sunrise will fix this dropping dep on
x11-libs/qt:4 but, anyway, I would want to confirm if the behavior noted
in:
http://bugs.gentoo.org/show_bug.cgi?id=197961#c19

is normal. I already know bug 161953 but, in my case, I have qt-gui
installed (emerge should now install also qt-webkit) and I don't have any
qt:4 version installed (only qt:3)

I would expect emerge to simply install qt-webkit as a half of ( 
x11-libs/qt-gui:4 x11-libs/qt-webkit:4 )
DEPEND is already satisfied and none of x11-libs/qt:4 is

Thanks a lot :-)




Re: [gentoo-portage-dev] emerge prefers to install x11-libs/qt:4 instead of ( x11-libs/qt-gui:4 x11-libs/qt-webkit:4 ) even when x11-libs/qt-gui:4 is already installed

2009-03-02 Thread Pacho Ramos
El lun, 02-03-2009 a las 13:01 -0800, Zac Medico escribió:
 || ( ( x11-libs/qt-gui:4 x11-libs/qt-webkit:4 ) x11-libs/qt:4 )
 
 It's a variation of bug 161953 [1]. For this particular variation,
 at the moment I don't think there's a good way to distinguish that
 the choice on the left is the better choice. 

From my point of view, I think that portage should do something like
calculating how much a dep is already in the system, for example, in
this case, I have 50% of ( x11-libs/qt-gui:4 x11-libs/qt-webkit:4 )
already installed on my system while 0% of x11-libs/qt:4. Then,
( x11-libs/qt-gui:4 x11-libs/qt-webkit:4 ) would be a better option
because, hopefully, a user that has already installed a portion of this
dep, will prefer to maintain it installed

But, this is only theoretical as I am not a programmer and I don't know
if this could be implemented

 However, if we
 implement PROPERTIES=virtual [2] then we can use that to tag the
 qt-4 ebuild as a virtual and then we should get better behavior due
 to virtual lookahead mechanism that has been implemented for bug
 141118 [3]. In the absence of PROPERTIES=virtual support, we'd have
 to use a more complex approach such as the avoid redundant
 upgrades algorithm suggested for bug 260225 [4].
 
 [1] http://bugs.gentoo.org/show_bug.cgi?id=161953
 [2]
 http://archives.gentoo.org/gentoo-dev/msg_9d449a18a96a25a547fcfd40544085cf.xml
 [3] http://bugs.gentoo.org/show_bug.cgi?id=141118
 [4] http://bugs.gentoo.org/show_bug.cgi?id=260225
 - --
 Thanks,
 Zac

This seems another option but, implementing previous one, would allow to
cover more possible cases 

Best regards :-)






Re: [gentoo-portage-dev] How to hardmask all ebuilds from an overlay?

2009-02-12 Thread Pacho Ramos
El jue, 12-02-2009 a las 10:22 -0800, Zac Medico escribió:
 Currently, the simplest solution might be to use an rsync command to
 sync the specific packages that you want (or exclude the unwanted
 packages) to a separate directory, and put the separate directory in
 PORTDIR_OVERLAY instead of the original one.
 
 Otherwise, the only alternative is to use package.mask and I'm
 afraid that will not be very manageable give the current
 capabilities. In the future we might add support to specify repo
 names in dependency atoms, which will allow you to mask packages
 from a specific repository.
 - --
 Thanks,
 Zac

OK, thanks for the recommendation :-)




Re: [gentoo-portage-dev] search functionality in emerge

2008-11-23 Thread Pacho Ramos
El dom, 23-11-2008 a las 16:01 +0200, tvali escribió:
 Try esearch.
 
 emerge esearch
 esearch ...
 
 2008/11/23 Emma Strubell [EMAIL PROTECTED]
 Hi everyone. My name is Emma, and I am completely new to this
 list. I've been using Gentoo since 2004, including Portage of
 course, and before I say anything else I'd like to say thanks
 to everyone for such a kickass package management system!!
 
 Anyway, for my final project in my Data Structures 
 Algorithms class this semester, I would like to modify the
 search functionality in emerge. Something I've always noticed
 about 'emerge -s' or '-S' is that, in general, it takes a very
 long time to perform the searches. (Although, lately it does
 seem to be running faster, specifically on my laptop as
 opposed to my desktop. Strangely, though, it seems that when I
 do a simple 'emerge -av whatever' on my laptop it takes a very
 long time for emerge to find the package and/or determine the
 dependecies -  whatever it's doing behind that spinner. I can
 definitely go into more detail about this if anyone's
 interested. It's really been puzzling me!) So, as my final
 project I've proposed to improve the time it takes to perform
 a search using emerge. My professor suggested that I look into
 implementing indexing.
 
 However, I've started looking at the code, and I must admit
 I'm pretty overwhelmed! I don't know where to start. I was
 wondering if anyone on here could give me a quick overview of
 how the search function currently works, an idea as to what
 could be modified or implemented in order to improve the
 running time of this code, or any tip really as to where I
 should start or what I should start looking at. I'd really
 appreciate any help or advice!!
 
 Thanks a lot, and keep on making my Debian-using professor
 jealous :]
 Emma
 
 
 
 -- 
 tvali
 
 Kuskilt foorumist: http://www.cooltests.com - kui inglise keelt oskad.
 Muide, üle 120 oled väga tark, üle 140 oled geenius, mingi 170 oled ju
 mingi täica pea nagu prügikast...

I use eix:
emerge eix

;-)