Re: [gentoo-dev] CVS headers in ebuilds

[Ulrich Mueller]

> On Mon, 4 Apr 2016, Robin H Johnson wrote:

> On Mon, Apr 04, 2016 at 09:03:59AM +1200, Kent Fredric wrote:
>> Last time this came up, a sole example case was mentioned, but it
>> might have been buried.
>> https://bugs.gentoo.org/show_bug.cgi?id=557386

> Infra left the $Id$ stubs in place for this use case, but did not
> turn on global expansion due to the related issue mentioned in the
> bug: CVS allows easy individual file control of disabling keyword
> expansion (and setting a file as binary which also implicitly
> disables keyword expansion).
> We'd have to find all of those files and explicitly create
> .gitattribute files, per directory, for them.

I wonder if the small benefit gained from expanding keywords would be
worth this effort. Seems that the feature wasn't missed much in the
8 months since the conversion to git.

Ulrich


pgpFCCbfJcbDk.pgp
Description: PGP signature

Re: [gentoo-dev] CVS headers in ebuilds

[Lars Wendler]

On Sun, 3 Apr 2016 22:57:42 +0200 Ulrich Mueller wrote:

>Does anyone still use the CVS $Id$ keywords that are in all ebuilds'
>headers, or are they being expanded anywhere? Or is there any other
>reason why they should be kept?
>
>In fact, the council had already voted to drop them in its 20141014
>meeting:
>
>   Can we drop CVS headers post-migration?
>   Aye: blueness, creffett (proxy for ulm), dberkholz, dilfridge,
>   radhermit, rich0, williamh 
>
>Ulrich

Yes, I still use these lines to check for ebuild changes between
portage and my personal overlay. So please keep this line.

Thanks.

Lars

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39

Attention! New gpg key! See (self signed server cert for now)
http://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html


pgpclkVFNS3fO.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] [PATCH 00/21] gen_usr_ldscript: migrate away from a sep-/usr by default

[Alexis Ballier]

On Saturday, April 2, 2016 8:01:39 PM CEST, William Hubbs wrote:

On Sat, Apr 02, 2016 at 12:35:58PM -0500, William Hubbs wrote:

On Fri, Apr 01, 2016 at 09:36:56PM +0200, Alexis Ballier wrote:

On Friday, April 1, 2016 8:33:02 PM CEST, Mike Frysinger wrote: ...


No, it wouldn't. We made a decision in 2013 (I'll have to find it) that
separate /usr should only be supported via initramfs; there is also a
news item warning that if you are not using initramfs and you have
separate /usr your system will be unbootable in the future.


Here are the latest council decision on the matter [1] and news item [2].
At this point, if anyone who has split /usr isn't using initramfs,
they are operating on borrowed time.



Good then, thanks. I didn't remember this one and failed to see it when 
looking at council decisions. I assume there's nothing preventing disabling 
gen_usr_ldscript by default then. Apologies to Mike for being annoying on 
this one :)


I also assumed making eudev default was a step in having sep-usr work by 
default as the initial issue was brought up by udev, but that's flawed 
reversed logic.



I would agree, since it has been so long, that we should do another news
item, but once the news item is done and we give a firm date, I think
we should just kill off gen_usr_ldscript.


Killing it is too violent IMHO: It doesn't provide much gain and makes it 
very annoying to get sep-usr working afterwards. I think current proposal 
to make it optional is the best option.



The /usr merge is a separate issue, which I agree with as well, but that
was never brought to council, and it is controversial in the Gentoo camp
because some folks claim fhs doesn't allow it.


Getting a bit OT, but can you explain in what ways it violates fhs ?
What worries me more about /usr merge is that I've never seen a plan for 
it. I think it'd be necessary to have portage gain some intra-package 
collision check (e.g. a package installing /bin/foo and /usr/bin/foo should 
be reported), which would then allow building /usr-merged stages, but the 
main issue for me is how to migrate installed systems properly.


Alexis.

Re: [gentoo-dev] Re: can someone help me or give me access to planet.gentoo.org

[Mart Raudsepp]

Ühel kenal päeval, P, 03.04.2016 kell 01:55, kirjutas Duncan:
> Anthony G. Basile posted on Sat, 02 Apr 2016 05:31:44 -0400 as
> excerpted:
> 
> > I wrote a long blog post and I'd like to see it on planet
> > gentoo.  I
> > plan on blogging a lot more too and need to see this problem fixed.
> 
> In the mean time, what about a direct link to your blog?
> 
> While I follow planet gentoo, I subscribe directly to a few gentooer 
> blogs as well, in part because I'm interested in some stuff that
> doesn't 
> get tagged gentoo and thus that planet gentoo won't carry.

That stuff should get to universe then, but I'm not sure if all
developer blogs are syndicated as such.

https://planet.gentoo.org/universe/


Mart

Re: [gentoo-portage-dev] [PATCH] emerge: add --search-fuzzy and --search-fuzzy-cutoff options (bug 65566)

[Alexander Berntsen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

This is a great idea!


On 04/04/16 07:03, Zac Medico wrote:
> +.BR "\-\-search\-fuzzy [ y | n ]"
> +Enable or disable fuzzy search for search actions.
This is likely a good place to briefly explain what a "fuzzy search"
is.

Also, I'm not sold on "seach-fuzzy" as opposed to "fuzzy-search". Is
there a particular reasoning for it? Since we don't seem to have a
standardised "verbs mean this, nouns mean this" anyway, I would use
the latter phrase.

You also need to document your note on regexes.

Lastly, you also need to document that a fuzzy search is slower than a
regular search.

> +.TP
> +.BR "\-\-search\-fuzzy\-cutoff CUTOFF"
> +Set similarity ratio cutoff (a floating-point number between 0 and 1).
> +Results with similarity ratios lower than the cutoff are discarded.
> +This option has no effect unless the \fB\-\-search\-fuzzy\fR option
> +is enabled.
This explanation is a bit heavy to read. And I think that using 0 to 1
isn't very nice. And calling the number "floating point" instead of
decimal isn't very useful nor nice. How about making it a percentage,
and describing it simply as a similarity percentage -- "package names
must be at least N% similar to the search term to appear in search
results". The option could then be called --seach-fuzzy-similarity,
or (in keeping with the previous suggestion)
- --fuzzy-search-similarity, or -- wait for it -- something similar. ;)
Of course if you agree with this, you'll have to reverse the code to
represent which results to show, rather than which ones to not show.

You should also document here what happens if there's a mistake in the
input.

> + "--search-fuzzy-cutoff": {
> + "help": "Set similarity ratio cutoff (a floating-point 
> number between 0 and 1)",
> + "action": "store"
> + },
See comments above regarding how to explain what this actually does.

> + if myoptions.search_fuzzy_cutoff:
> + try:
> + fuzzy_cutoff = float(myoptions.search_fuzzy_cutoff)
> + except ValueError:
> + fuzzy_cutoff = 0.0
Is this a reasonable fallback? I guess so... but you need to mention
it in the manpage, as mentioned.

> +
> + if fuzzy_cutoff <= 0.0:
> + fuzzy_cutoff = None
> + if not silent:
> + parser.error("Invalid --search-fuzzy-cutoff 
> parameter: '%s'\n" % \
> + (myoptions.search_fuzzy_cutoff,))
> +
> + myoptions.search_fuzzy_cutoff = fuzzy_cutoff
> +
I also don't understand why the first one is just 0.0, but this one
is an error. Why aren't both either errors and revert to 0.8 cut-off
(or 80% similarity) or 0.0/100?

And this needs to go in the manpage too.

> + self.fuzzy_cutoff = 0.8 if fuzzy_cutoff is None else 
> fuzzy_cutoff
See above.

> + fuzzy = False
Here's an interesting discussion: maybe this should be True? After
all, it's True in any modern search engine. What do you think?

> + # Fuzzy search does not support regular expressions, 
> therefore
> + # it is disabled for regular expression searches.
Manpage.
- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXAig0AAoJENQqWdRUGk8BOOEQAIEYXkn86ibMiYhN5BBDlsL1
2a6zBOCzygTkpxiBg+8vPsWJcHmzyTO7M6H1x3bUCY/JEfWq0354WdvNMtDM5qZk
zpwIg0uPs/Q4Fo40hozHsc66f+jqZxgmy5rML2mO8cAFZANZdNtuvTkVQYF5zQXz
4CI06tVDwXmYAmg7wIBEpWJ8O+is2F1abzPJcr42tLz5ELYm1IRn4Em8WO5m5klm
mrYWWeesvNS1l2y8kbKCmtpQbSuzLYfFyVfFkSL/p6t16Tiu7edqGJ0HOrq5B5dx
+cwuT+vwbTtA8d/Qo/cifbyuxnNtO8JthhEvemAdCYkDC4DQHDStsKFjA+Za1Sos
r/eSQexXNOQ/oMgksm72aX9rIkfurtn73AhIthKEnzrzou3pVW+H5eHR25vF58EO
qHUJO9/Z8ZkHec3HopxFtYng16i26VlW2pDehdkWGVoZSXomaOyH7x7XQXZoE7B+
4e4vDOMbeIvxyA/j1+H35WBZCu6f9FstOrEptD5FIE6/QM4oAW+CBllUQf5iQVEB
4Rpodu2AvKWgqTTOMLcn9+HK8JgnbMlm6cYLT+YXP7j6OnJFB6yq5/L3dfS5rrEX
sxwrvVTTx2dCbX/RImQoMpEIQFaTfimZgKQDw3rmtv+JfP3OnpdOrN+QJJfHbCgb
4c9suzs/UTBLbtiFQhdO
=XsDv
-END PGP SIGNATURE-

[gentoo-dev] Re: CVS headers in ebuilds

[Jonathan Callen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 04/04/2016 02:58 AM, Lars Wendler wrote:
> On Sun, 3 Apr 2016 22:57:42 +0200 Ulrich Mueller wrote:
> 
>> Does anyone still use the CVS $Id$ keywords that are in all
>> ebuilds' headers, or are they being expanded anywhere? Or is
>> there any other reason why they should be kept?
>> 
>> In fact, the council had already voted to drop them in its
>> 20141014 meeting:
>> 
>> Can we drop CVS headers post-migration? Aye: blueness, creffett
>> (proxy for ulm), dberkholz, dilfridge, radhermit, rich0, williamh
>> 
>> 
>> Ulrich
> 
> Yes, I still use these lines to check for ebuild changes between 
> portage and my personal overlay. So please keep this line.
> 
> Thanks.
> 
> Lars
> 

I do the same (after enabling expansion in .git/info/attributes on
just "*.ebuild", I can even get a quick diff of what changed in
gentoo.git to update my overlay).

- -- 
Jonathan Callen
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXAz9VAAoJEEIQbvYRB3mg5wMP/1sjOs1yDT9qI96Cy/s3K+el
+VfRKu1GmxCZgNzWJRMWkKRkYh6eY90aZ9naIijadlShsA4HtaP6psRIPuWxbxBZ
UPDOqb+xxhm178Rj7BGeU/TtHGLyEE+09KqQSNOi6EwwVXWBSBcAJQln/IGMI831
4daghpp2UlUUhgkFlCyk9M2MsXbA5CtJo8tKp+mUt/0p6dxP458yxzK7gUC9eY3b
TnjxP60T6oFWSnZQYJ0Qdj4DemBIe3B0uRWY87uST2KLA8dtCbsEKlRa9fE83JfS
GT6G2RBetphsR5GJsEEgCOpu5MWXMwxjLFM7YMHo9mTDk4PhFuq82g88ZAaCQNta
sG6wWPWnAiIh54nqT6axvM1FQ3OoPQI7hGG99zuUQAaZXp29lsxcFiRT2FWdecLk
0fyrAa3/0rBm6Bixr+YxsD27n0pjTQUzgOlfwfVT8mf+hKJ1X8DqXrkB5axpp/pc
eArYrt/nYzmfMFM021xST8K5tDqTxd+MI6ZcMoeVAsJEdCyS/KvySYrinbe4PfRa
v0ricr8hXDsAbVT91BwC/T+AWpSGn0K5T/VGqCeTDHdH3Dn+x2JGpVRE159/f/2e
gD5ByNhIet+gSDMS+9Q/HO62mbs7Qu9Bwqi2cYKKeyIgHMi1s6JTh+tzOUxrC6Ny
sJkCQLlAIKZ5LDlJ/DZu
=Y/Tk
-END PGP SIGNATURE-

[gentoo-dev] usr merge

[William Hubbs]

All,

I thought that since the usr merge is coming up again, and since I lost
track of the message where it was brought up, I would open a
new thread to discuss it.

When it came up before, some were saying that the /usr merge violates
the fhs. I don't remember the specifics of what the claim was at the
time, (I'm sure someone will point it out if it is still a concern).

I don't think creating usr merged stages would be that difficult. I
think it would just be a matter of creating a new version of baselayout
that puts these symlinks in place:

/bin->usr/bin
/lib->usr/lib
/lib32->usr/lib32
/lib64->usr/lib64
/sbin->usr/bin
/usr/sbin->bin

Once that is in place in a new baselayout, I think portage's colission
detection would be able to catch files that had the same names and were
originally in different paths when building the new stages.

I put some thought also in how to nigrate live systems, and I'm not sure
what the best way to do that is. I wrote a script, which would do it in
theory, but I haven't tested because I only have one system and if
it breaks it the only way back would be to reinstall.

The script is attached.


Thoughts on any of this?

William

#!/bin/bb

is_internal()
{
[ -z "$1" ] && return 1
case $(command -v $1) in
*/*) rc=1 ;;
*) rc=0 ;;
esac
return $rc
}

run_command()
{
local dryrun=
[ $DRYRUN -eq 1 ] && dryrun=echo
$dryrun "$@"
}

for cmd in cp ln; do
if ! is_internal $cmd; then
echo "Please rebuild busybox and include the $cmd command."
exit 1
fi
done

if [ -L /bin -a -L /sbin ]; then
echo "It appears that the /usr merge has already been done on this 
system."
exit 0
fi

DRYRUN=1
HELP=0
while [ $# -gt 0 ]; do
case $1 in
--dryrun|--dry-run) DRYRUN=1 ;;
-h|--help) HELP=1 ;;
esac
shift
done

if [ $HELP -eq 1 ]; then
echo "$(basename $0) -h \| --help - displays this message"
echo "$(basename $0) --dryrun \| --dry-run  - show what would be done"
exit 0
fi

# copy binaries
for dir in /bin /sbin /usr/sbin; do
run_command cp -a $dir/* /usr/bin
done

# copy libraries
for dir in /lib*; do
[ -L $dir ] && continue
run_command cp -a $dir/* /usr$dir
done

# Create the /usr merge compatibility symlinks
for dir in /bin /sbin; do
run_command rm -rf $dir
run_command ln -s usr/bin $dir
done
run_command rm -rf /usr/sbin
run_command ln -s bin /usr/sbin
for dir in /lib*; do
run_command rm -rf $dir
run_command ln -s usr$dir $dir
done


signature.asc
Description: Digital signature

Re: [gentoo-dev] Re: News item: upgrading to Plasma 5

[Mike Gilbert]

On Mon, Apr 4, 2016 at 1:55 AM, Duncan <1i5t5.dun...@cox.net> wrote:
> Michael Palimaka posted on Mon, 04 Apr 2016 05:23:03 +1000 as excerpted:
>
>> The default in KDE 4 was KDM, with lightdm and sddm also supported.
>>
>> We included information about migrating away from KDM because it's no
>> longer developed or supported and in some cases fails to work with
>> Plasma 5 at all.
>>
>> lightdm continues to work fine with Plasma 5 so there's no special need
>> to replace it.
>
> For clarity, then, why not add a single sentence similar to this (reword
> if appropriate):
>
> KDE 4 also supported lightdm and sddm, and users configured to use those
> display managers can continue to use them without reconfiguration.

You could also use XDM or GDM to launch KDE, but I don't think there's
any need to state that in this news item. We only need to make a
suggestion for people using the obsolete KDM.

Re: [gentoo-dev] CVS headers in ebuilds

[Robin H. Johnson]

On Mon, Apr 04, 2016 at 03:42:37PM +1200, Kent Fredric wrote:
> On 4 April 2016 at 14:43, Robin H. Johnson  wrote:
> > We'd have to find all of those files and explicitly create .gitattribute
> > files, per directory, for them.
> I was under the impression that a .gitattribute file in the root
> directory sufficed?
> 
> ( I maybe have misinterpreted what you said, but the writing implied
> ">1 .gitattribute files proliferated into the tree" )
> 
> I'd personally think */*/*.ebuild would be a satisfactory start, and
> the rest could be turned on in an as-deemed-necessary basis.
This discussion is for files to _exclude_ from expansion.
If they were in CVS with the -ko or -kb flags, then they'd need to be
excluded. This applies mostly to patches in the files subdir.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Infrastructure Lead, Foundation Trustee
E-Mail : robb...@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-portage-dev] [PATCH v2] Colorize packages in user sets (bug 577720)

[Alexander Berntsen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I'm not too sure about the isUserSets, but unless anyone else has any
feedback, I'll test and merge this during the week.

- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXAhS6AAoJENQqWdRUGk8BsIsP/1AlLSqb224V5xqXB+qLMEDq
o3OezDV+JQ20jtx80PxKhCZ7wIsBphiU+kMLQ6hj7o/IMtyStXPnOnERVaH5NUpS
CszfsKXlEvilLS+E8ecaViYokvMM9q1nvChG+mBsDRJSvbmRMYdgZckUvc2vABQ1
/pl0bwc38Ic9H3abnkyz50DnAZDoKmUWBiRhk9oiIT8QrrKvWEImB387TE20WGwD
lkchIOx26wlVQeRx/b5Qqus86iyFKC4lqxTYm/xq5RxKXHn/llXSnHRJ4qGfg51G
njPfGiYc+7XL4RYQuE0xXzFOOz11F0iFrRLX9HcDeYQxp1FeUfJVFBPG9ycFbqJ8
JF4Q52nNdh+oTczxRNZluNj4KH4artmGVpIJsei+4wic/FfsQHSC2ZRDfmjoE7P/
8ySmgd4r7WqZpLAgnihX6JhBW19FRnRPxnjzq9vqSqMe2b1Z6EWxs9tVmqznnZdI
ORGszRDqJzCFFEWiSQO4x4pN4oSE3x9ZK00evVdCrnbuSEXLGjsBG46RbQzEENzB
MTyTixQjetA0hF0p506Cf3mgkHxWaI2YfM//bgniUrOyJZLmUegDfxVlAFUa8+Q+
amdiwFCV1KXvOK5QUrXfIQ7Jyj8qv/XuCipsw14U3RSPX4D6vVmzECHcoOK52+c8
BV5MDuNaDih4mvuooCqa
=N3Et
-END PGP SIGNATURE-

[gentoo-dev] /usr merge Was: [PATCH 00/21] gen_usr_ldscript: migrate away from a sep-/usr by default

[Duncan]

Alexis Ballier posted on Mon, 04 Apr 2016 09:12:16 +0200 as excerpted:

>> The /usr merge is a separate issue, which I agree with as well, but
>> that was never brought to council, and it is controversial in the
>> Gentoo camp because some folks claim fhs doesn't allow it.
> 
> Getting a bit OT, but can you explain in what ways it violates fhs ?
> What worries me more about /usr merge is that I've never seen a plan for
> it. I think it'd be necessary to have portage gain some intra-package
> collision check (e.g. a package installing /bin/foo and /usr/bin/foo
> should be reported), which would then allow building /usr-merged stages,
> but the main issue for me is how to migrate installed systems properly.

FWIW, I actually run a (reverse) merged /usr here, along with the bin/sbin 
merge.

Obviously it's symlinks as the packages still install where they will 
install, but:

/usr -> .
/sbin -> bin

As a result I have the following "semi-flattened" directory structure 
directly on /, including everything that would normally be under /usr:

/bin
/boot
/dev
/etc
/games -> .
/home
/include
/lib -> /lib64
/lib64
/libexec
/local
/media
/proc
/root
/run
/sbin -> bin
/share
/src
/srv
/sys
/tmp
/usr -> .
/var
/x86_64-pc-linux-gnu

(That excludes some unrelated additional changes of my own, again mostly 
to shorten paths, such as /home actually being /home -> /h (/h being the 
actual mountpoint for what would normally be /home in fstab), /local, 
what would be /usr/local, actually being /local -> /l, and /var/log -> /
lg (with /lg being a mountpoint as well, isolating logs and keeping 
runaway logging from creating havoc on anything but /lg itself).)


You will be glad to note that portage has in fact been smart enough to 
avoid symlinks overwriting the files they would normally point at for 
quite some time -- in fact, I specifically asked about this on the 
portage list before I tried it myself.  So that's not a problem at all.

There are, however, occasional bugs when specific packages try to clean 
up old versions and end up deleting the new version instead, because they 
don't dereference symlinks to a canonical path before they do the rm.  
One current example of that is gcc-config:

[Bug 554334] sys-devel/gcc-config pkg-postinst rm -f /usr/sbin/gcc-config 
breaks when using /usr/sbin->bin symlinks

https://bugs.gentoo.org/show_bug.cgi?id=554334

The result of that bug is that gcc-config deletes its own executable.  
However, it's worth repeating that the bug is because the ebuild itself 
executes rm -f on an arbitrary path without resolving both it and the 
canonical path of its executable and comparing them -- it's not a bug in 
portage itself, portage itself behaves correctly in terms of resolving to 
canonical paths.

Fortunately for me, while that bug has been open for 8 months+, my sync 
script can automatically patch ebuilds using patches in /etc/portage/
patches.ebuild, much like the portage implementation of eapply_user 
patches sources with patches found in /etc/portage/patches.  So now I've 
worked around that bug by patching out the offending rm line in the 
ebuild.  Hey, when eight months and counting later a critical bug in a 
toolchain package remains open, a good gentooer tends to find 
workarounds.  What can I say?


Packages that use cmake can sometimes have issues too, depending on the 
version of cmake, as it apparently doesn't always properly resolve to 
canonical paths.  As I'm a kde5/plasma user and one such affected package 
has been baloo, a plasma dependency, that has been a headache for me.  
But being a USE=-semantic-desktop user in the kde4 era, I didn't really 
want baloo on my system anyway, so rather than spend the time researching 
how to fix the bad cmake/symlinks interaction, I was motivated to 
research killing the baloo deps instead, and ultimately source-patched 
(as opposed to ebuild-patched, as I did gcc-config) the two plasma 
packages requiring it to kill the baloo-based modules.  With the sources 
patched to no longer require baloo, I simply placed a baloo null-package 
in my overlay (the other alternatives would be package.provided, but 
that's deprecated, or to use the ebuild patching sync-script mentioned 
above to delete the baloo-deps in the ebuild) to fill the ebuild 
dependency, and that's what I'm running with today.

The merged /usr and bin/sbin cmake related bugs I've filed are:

cmake/baloo: https://bugs.gentoo.org/show_bug.cgi?id=561956

(Unrelated to /usr or bin/sbin merge but mentioned above as my resolution 
for the cmake/baloo bug, the no-baloo patches bug:
https://bugs.gentoo.org/show_bug.cgi?id=578664 )

Older cmake/libraw bug, resolved with newer versions of one or the other: 
https://bugs.gentoo.org/show_bug.cgi?id=532426

Older plasma5 plasma-desktop bug that kept the plasma5 desktop from 
coming up properly, as I was switching to it from kde/plasma4, so I'm not 
sure if it was a regression from earlier plasma5 or not.  Fixed in 
current plasma: