Re: [gentoo-dev] amd64 17.1 profiles ready for testing

[Kent Fredric]

On Fri, 15 Dec 2017 21:09:15 +0100
Michał Górny  wrote:

> Sounds like you've put some awful self-symlink into this directory.
> The script incorrectly follows top-level symlinks when removing, I'll
> fix that.

If it helps, this is on a no-multilib install, and the tree if I roll back to 
its state in may ( the last snapshot ) shows:

/usr # ls -la
total 24
drwxr-xr-x 1 root root   142 Dec  3  2016 .
drwxr-xr-x 1 root root   126 Dec 15 21:10 ..
drwxr-xr-x 1 root root 14018 Dec 16 01:07 bin
drwxr-xr-x 1 root root  4596 Dec 16 01:02 include
lrwxrwxrwx 1 root root 5 Nov 24  2016 lib -> lib64
drwxr-xr-x 1 root root  9980 Dec 16 01:02 lib64

 / # ls -la
total 36
drwxr-xr-x   1 root root   126 Dec 15 21:10 .
drwxr-xr-x   1 root root   126 Dec 15 21:10 ..
drwxr-xr-x   1 root root  1010 Dec 16 01:02 bin
drwxr-xr-x   1 root root10 Nov 24  2016 boot
drwxr-xr-x  17 root root  3820 Dec 15 10:55 dev
drwxr-xr-x   1 root root  1646 Dec 16 01:07 etc
drwxr-xr-x   1 root root22 Jan 23  2017 home
lrwxrwxrwx   1 root root 5 Dec 15 21:10 lib -> lib64
drwxr-xr-x   1 root root  3534 Dec 16 00:56 lib64
drwxr-xr-x   1 root root10 Nov 24  2016 media
drwxr-xr-x   1 root root10 Nov 24  2016 mnt
drwxr-xr-x   1 root root10 Jan 24  2017 opt
dr-xr-xr-x 219 root root 0 Dec 15 10:54 proc
drwxr-x---   1 root wheel  488 Dec 15 11:04 root
drwxr-xr-x   1 root root22 Dec 15 21:36 run
drwxr-xr-x   1 root root  1958 Dec 16 01:02 sbin
dr-xr-xr-x  13 root root 0 Dec 15 10:55 sys
drwxrwxrwt   1 root root   408 Dec 16 03:38 tmp
drwxr-xr-x   1 root root   142 Dec  3  2016 usr
drwxr-xr-x   1 root root92 Jan 24  2017 var

But as for "self-symlinks" I can't seem to find anything.

I should also point out that I had a bunch of bind-mounted directories in 
/usr/src/* from the host OS  , and these were also recursively nuked. :/

But I couldn't see anything obvious in the source that explained that ( and 
analysis didn't really have any indication of things that could get broken )


pgpS8vVtm2jwN.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Moderator ruleset for gentoo-dev@lists.gentoo.org

[R0b0t1]

Hello,

On Tue, Dec 5, 2017 at 4:18 PM, Nils Freydank  wrote:
> Hello everyone,
>
> with regards to the current mailing list (ML) split discussion, and one
> specific message deep down there by mgorny asked for someone providing
> moderator rules, I would like to propose the following ruleset for gentoo-dev
>
> Right now the situation escalated in a way that forces to actually do
> something and I hope we can recreate an atmosphere where technical
> improvements can happen.
>

To me, at least, this isn't self-evident. What specific actions make
you think an immediate response is necessary?

self-evident
  adj. Evident to one’s self and to nobody else.

Cheers,
 R0b0t1

Re: [gentoo-dev] amd64 17.1 profiles ready for testing

[Michał Górny]

W dniu pią, 15.12.2017 o godzinie 22∶24 +1300, użytkownik Kent Fredric
napisał:
> On Sat, 09 Dec 2017 11:26:36 +0100
> Michał Górny  wrote:
> 
> I ran this on a chroot.
> 
> > 5. Run 'unsymlink-lib --migrate'.
> > 
> > 6. Reboot your system and see if it still boots, possibly test if
> > important programs work. Also check if emerge starts but don't install
> > anything. If your system is now broken, you can do
> > 'unsymlink-lib --rollback' to return to step 3.
> 
> I started a new chroot because there's no "boot" and it seemed to work fine.
> 
> > 
> > 7. Run 'unsymlink-lib --finish'.
> 
> I ran this, and it broke the chroot :/
> 
> Weird problems like: 
> 
> Removing /usr/lib64/lib64/sys/block/ram0 failed: [Errno 20] Not a directory: 
> '/usr/lib64/lib64/sys/block/ram0'

Sounds like you've put some awful self-symlink into this directory.
The script incorrectly follows top-level symlinks when removing, I'll
fix that.

> Removing /usr/lib64/lib64/sys/block/sdb failed: [Errno 20] Not a directory: 
> '/usr/lib64/lib64/sys/block/sdb'
> Removing /usr/lib64/lib64/sys/block/ram9 failed: [Errno 20] Not a directory: 
> '/usr/lib64/lib64/sys/block/ram9'
> Removing /usr/lib64/lib64/sys/block/ram7 failed: [Errno 20] Not a directory: 
> '/usr/lib64/lib64/sys/block/ram7'
> Removing /usr/lib64/lib64/sys/block/loop6 failed: [Errno 20] Not a directory: 
> '/usr/lib64/lib64/sys/block/loop6'
> Removing /usr/lib64/lib64/sys/block/ram14 failed: [Errno 20] Not a directory: 
> '/usr/lib64/lib64/sys/block/ram14'
> Removing /usr/lib64/lib64/sys/block/ram5 failed: [Errno 20] Not a directory: 
> '/usr/lib64/lib64/sys/block/ram5'
> Removing /usr/lib64/lib64/sys/block/loop4 failed: [Errno 20] Not a directory: 
> '/usr/lib64/lib64/sys/block/loop4'
> Removing /usr/lib64/lib64/sys/block/ram12 failed: [Errno 20] Not a directory: 
> '/usr/lib64/lib64/sys/block/ram12'
> 
> and 
> 
> Removing /usr/lib64/lib64/usr/lib64/libpkgconf.a failed: [Errno 2] No such 
> file or directory: '/usr/lib64/lib64/usr/lib64/libpkgconf.a'
> Removing /usr/lib64/lib64/usr/lib64/libpkgconf.so failed: [Errno 2] No such 
> file or directory: '/usr/lib64/lib64/usr/lib64/libpkgconf.so'
> Removing /usr/lib64/lib64/usr/lib64/libpkgconf.so.2 failed: [Errno 2] No such 
> file or directory: '/usr/lib64/lib64/usr/lib64/libpkgconf.so.2'
> 
> Now in my chroot:
> 
>  # ls /lib/
> bash: ls: command not found
> 
> RIP.
> 

-- 
Best regards,
Michał Górny

[gentoo-dev] [PATCH 1/1] profiles: unset default USE=justify in hardened profiles.

[Michael Orlitzky]

The "justify" USE flag is local to only app-editors/nano, but it was
enabled by default in two hardened profiles,

  * hardened/linux/amd64/make.defaults
  * features/hardened/amd64/make.defaults

The reasoning for that is lost to time, but probably dates back to
when nano was part of the @system set, and we wanted the stages to be
built with USE=justify set for nano (before per-package USE defaults).

Closes: https://bugs.gentoo.org/635066
---
 profiles/features/hardened/amd64/make.defaults | 2 +-
 profiles/hardened/linux/amd64/make.defaults| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/profiles/features/hardened/amd64/make.defaults 
b/profiles/features/hardened/amd64/make.defaults
index 10d89c63ebf..1d58d93d315 100644
--- a/profiles/features/hardened/amd64/make.defaults
+++ b/profiles/features/hardened/amd64/make.defaults
@@ -1,5 +1,5 @@
 # Copyright 1999-2012 Gentoo Foundation.
 # Distributed under the terms of the GNU General Public License v2
 
-USE="justify -pic"
+USE="-pic"
 
diff --git a/profiles/hardened/linux/amd64/make.defaults 
b/profiles/hardened/linux/amd64/make.defaults
index acb6734fd7e..73067930812 100644
--- a/profiles/hardened/linux/amd64/make.defaults
+++ b/profiles/hardened/linux/amd64/make.defaults
@@ -1,7 +1,7 @@
 # Copyright 1999-2012 Gentoo Foundation.
 # Distributed under the terms of the GNU General Public License v2
 
-USE="justify -pic"
+USE="-pic"
 
 CFLAGS="-O2 -pipe"
 CXXFLAGS="${CFLAGS}"
-- 
2.13.6

Re: [gentoo-dev] [RFC] Moderator ruleset for gentoo-dev@lists.gentoo.org

[Anton Molyboha]

On Tue, Dec 5, 2017 at 5:18 PM, Nils Freydank  wrote:

> [snip]
>


> 3. Moderation
> -
> The moderation team has to consist of at least two developers. The
> moderators
> have to do join the moderation team voluntarily.
>
> "have to do join" should probably be "have to join"


> [snip]
>

[gentoo-dev] [PATCH] meson.eclass: add meson_use function

[Mike Gilbert]

---
 eclass/meson.eclass | 13 +
 1 file changed, 13 insertions(+)

diff --git a/eclass/meson.eclass b/eclass/meson.eclass
index 2c943dd6ae27..71735fbfc67d 100644
--- a/eclass/meson.eclass
+++ b/eclass/meson.eclass
@@ -137,6 +137,19 @@ _meson_create_cross_file() {
EOF
 }
 
+# @FUNCTION: meson_use
+# @USAGE:  [option name]
+# @DESCRIPTION:
+# Given a USE flag and meson project option, outputs a string like:
+#
+#   -Doption=true
+#   -Doption=false
+#
+# If the project option is unspecified, it defaults to the USE flag.
+meson_use() {
+   usex "$1" "-D${2-$1}=true" "-D${2-$1}=false"
+}
+
 # @FUNCTION: meson_src_configure
 # @DESCRIPTION:
 # This is the meson_src_configure function.
-- 
2.15.1

[gentoo-dev] packages up for grab

[grozin]

Packages I'm no longer interested in:

media-gfx/fotoxx
sci-libs/arprec
sci-libs/mathgl
sci-libs/qd
sci-mathematics/genius
sci-mathematics/gsl-shell
sci-mathematics/mathmod
sci-mathematics/reduce

fotoxx is now maintainer-needed. If anybody is interested, welcome. The 
upstream releases very often, a bump is needed.


All the other packages are now maintained by sci or sci-mathematics 
projects. If anybody is interested, please add yoursels as a maintainer. 
Maybe, gsl-shell and mathmod can be last-rited if nowbody takes them - I 
experimented with them a little but did not find them useful.


reduce is a very old version, hard-masked, non-working. reduce is a 
powerful and efficient CAS comparable with maxima. I use it quite often, 
but I compile new versions by hand, outside portage. The build system is 
terrible. If somebody could bump it to a modern version (an essential 
rewrite of the ebuild is needed), it would be excellent. Otherwise, we'll 
have to remove it :-(


One more appeal to the community. wxmaxima is used by many maxima users. I 
was not its formal maintainer, but in the past I did much work bumping it. 
The version in the tree is old (though working). The bump is urgently 
needed. The upstream has switched to cmake, and a nearly complete rewrite 
of the ebuild is needed.


Andrey Grozin

[gentoo-dev] Last rites: dev-python/{dreampie,pydb,pygui}

[grozin]

# Andrey Grozin  (15 Dec 2017)
# Dead upstream. Removal in 30 days. Use bpython or ptpython instead.
dev-python/dreampie

# Andrey Grozin  (15 Dec 2017)
# Dead upstream. Removal in 30 days.
dev-python/pydb

# Andrey Grozin  (15 Dec 2017)
# Dead upstream, unclear license. Removal in 30 days.
dev-python/pygui

Re: [gentoo-dev] amd64 17.1 profiles ready for testing

[Kent Fredric]

On Sat, 09 Dec 2017 11:26:36 +0100
Michał Górny  wrote:

I ran this on a chroot.

> 5. Run 'unsymlink-lib --migrate'.
> 
> 6. Reboot your system and see if it still boots, possibly test if
> important programs work. Also check if emerge starts but don't install
> anything. If your system is now broken, you can do
> 'unsymlink-lib --rollback' to return to step 3.

I started a new chroot because there's no "boot" and it seemed to work fine.

> 
> 7. Run 'unsymlink-lib --finish'.

I ran this, and it broke the chroot :/

Weird problems like: 

Removing /usr/lib64/lib64/sys/block/ram0 failed: [Errno 20] Not a directory: 
'/usr/lib64/lib64/sys/block/ram0'
Removing /usr/lib64/lib64/sys/block/sdb failed: [Errno 20] Not a directory: 
'/usr/lib64/lib64/sys/block/sdb'
Removing /usr/lib64/lib64/sys/block/ram9 failed: [Errno 20] Not a directory: 
'/usr/lib64/lib64/sys/block/ram9'
Removing /usr/lib64/lib64/sys/block/ram7 failed: [Errno 20] Not a directory: 
'/usr/lib64/lib64/sys/block/ram7'
Removing /usr/lib64/lib64/sys/block/loop6 failed: [Errno 20] Not a directory: 
'/usr/lib64/lib64/sys/block/loop6'
Removing /usr/lib64/lib64/sys/block/ram14 failed: [Errno 20] Not a directory: 
'/usr/lib64/lib64/sys/block/ram14'
Removing /usr/lib64/lib64/sys/block/ram5 failed: [Errno 20] Not a directory: 
'/usr/lib64/lib64/sys/block/ram5'
Removing /usr/lib64/lib64/sys/block/loop4 failed: [Errno 20] Not a directory: 
'/usr/lib64/lib64/sys/block/loop4'
Removing /usr/lib64/lib64/sys/block/ram12 failed: [Errno 20] Not a directory: 
'/usr/lib64/lib64/sys/block/ram12'

and 

Removing /usr/lib64/lib64/usr/lib64/libpkgconf.a failed: [Errno 2] No such file 
or directory: '/usr/lib64/lib64/usr/lib64/libpkgconf.a'
Removing /usr/lib64/lib64/usr/lib64/libpkgconf.so failed: [Errno 2] No such 
file or directory: '/usr/lib64/lib64/usr/lib64/libpkgconf.so'
Removing /usr/lib64/lib64/usr/lib64/libpkgconf.so.2 failed: [Errno 2] No such 
file or directory: '/usr/lib64/lib64/usr/lib64/libpkgconf.so.2'

Now in my chroot:

 # ls /lib/
bash: ls: command not found

RIP.



pgpCmuzp7Hpyy.pgp
Description: OpenPGP digital signature