Re: [gentoo-dev] About suggesting to create a separate partition for portage tree in handbook

[viv...@gmail.com]

Il 27/03/2012 20:53, Ian Stakenvicius ha scritto:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 27/03/12 02:47 PM, Rich Freeman wrote:

On Tue, Mar 27, 2012 at 2:34 PM, Alexandre Rostovtsev


The partitioning scheme is something that the user needs to
decide on *before* getting Gentoo up and running. After the user
had finished installing the operating system, it's too late to
inform him about the advantages of a separate /usr/portage.

Yes and no (if you have free space, you could easily move
/usr/portage - some other changes are harder).

However, you could extend this line of argument to raid, lvm, and
even stuff like the use of systemd or an alternative package
manager.  All of those things are much easier to implement if you
just start out with them.

I'm all for creating a wiki to talk about some alternative
options. Perhaps even link to it at the start of the handbook in
the intro (if you're not in a rush and want to read about more
advanced configurations, check out ...).

However, I tend to agree that the handbook should be a
nearly-foolproof no-frills Gentoo installation.



You know, we have "Code Listing 2.1: Filesystem Example" in Section 4,
we could always adjust that to have a /usr/portage partition in it
(take a bit of space away from /home, or something)

It doesn't recommend/require anything, but when users see it they'll
think about it.


Boh ... IMHO /usr/portage should be a squashfs filesystem, rsynced from 
some kind server out there, auto(un)mounted, so it releases resources 
after use.
No needs for any additional partition (which sound kinda lame for a 
package manager)


However the devs are right here, handbook should be stripped down, not 
bloated with details that could be fulfilled later


Rgds,
Francesco

Re: [gentoo-dev] RFC: iotop needs to run as root after kernel change

[viv...@gmail.com]

Il 04/04/2012 08:43, "Paweł Hajdan, Jr." ha scritto:

On 4/4/12 8:32 AM, justin wrote:

1.
Leave it to root (Fedora and Suses way)

I think that's the best option, at least for now.


2.
suid it (bad in my view)

Agreed, that'd be very bad, any crashing bug in it could become a
privilege escalation problem.


3.
file capabilities (can this be done with portage)

Slightly better than the above, but I still prefer #1.


Or default to 1. but provide a use flag to achieve 3.
net-wireless/kismet uses 'suid', maybe other use 'caps' use flags?
Hopefully others can answer on how to apply capabilities to executables

Re: [gentoo-dev] x32 release candidate

[viv...@gmail.com]

Il 06/06/2012 21:40, Gregory M. Turner ha scritto:

- Original Message -

i'm pleased to announce the initial x32 release candidate:
http://dev.gentoo.org/~vapier/x32/stage3-amd64-x32-20120605.tar.xz

Also pleased to hear this!  Thanks!  Can't wait to find the time to play with 
it.  Did you do all that work yourself?  Is there a wiki or forum thread 
somewhere where folks can gloat and/or commiserate?

I'm cautiously hopeful/enthusiastic about x32's prospects and a prefix seems like a fantastic 
way to bootstrap a community which could blueprint "cheat sheets" for prospective binary package maintainers 
(potentially driving adoption -- at least in my fantasies -- in the Grandma Zone).

-gmt



seem LWN was pleased too:

http://lwn.net/Articles/500482/

Congratulations for the achievement, this has been  more than 7 month of 
work right? It would be very interesting to see were it goes.


- Francesco

[gentoo-dev] [RFC] gcc-native-flags() proposal addition to toolchain-funcs.eclass

[viv...@gmail.com]

Meeting with bug: #409471 suggested that some ebuilds could benefit from 
expanding -march=native to the actual flags the compiler use.
Cannot suggest where to use it at the moment, but implementation was 
simple enough and possibly someone on this list could have a use for it.


# @FUNCTION: gcc-native-flags
# @USAGE: [CC compiler]
# @RETURN: 1st march 2nd mtune >=3rd flags
gcc-native-flags()

gcc-native-flags can take an argument, the compiler to use, then return 
something in the form:

-march=corei7-avx -mtune=generic -mcx16 [...] --param=l2-cache-size=8192

issues so far:
1) "--param l2-cache-size=8192" become "--param=l2-cache-size=8192", 
notice the space become an "=", this work and indeed I've encountered 
broken packages that didn't compile with -param\ ... form

2) what to do if $CC is not gcc / how to check cc is gcc
3) there are redundant flags, they are kept for simplicity
4) array usage is not really needed, just being a port of a python 
version it was natural this way ;-)

5) better name?

#409471  "dev-python/pypy-1.8-r1 CFLAGS=-march=native fails to compile"
https://bugs.gentoo.org/show_bug.cgi?id=409471

the attached file could be launched as is, it fake inherit some eclass 
and calls the function with available gcc


thanks,
Francesco Riosa



hw-cflags.sh
Description: application/shellscript

Re: [gentoo-dev] bug XXXXXX sys-libs/tdb fail check for building library support

[viv...@gmail.com]

BTW this is bug 379837, so there was no hurry :-P

Il 25/06/2012 14:55, Samuli Suominen ha scritto:

Open a bug at http://bugs.gentoo.org/ instead of mailing here.

Yeah, I know bugzilla is down but it's only temporary.

- Samuli

On 06/25/2012 02:54 PM, Francesco Riosa wrote:

neither stable tdb-1.2.9 nor tdb-1.2.10 install any shared library
when build with distcc, because of a failing chech @ configure time

Checking for building library support: not found

setting MAKEOPTS=-j1 does not suffice FEATURES=-distcc is needed

FYI the check is inside
buildtools/wafsamba/samba_conftests.py
def CHECK_LIBRARY_SUPPORT(conf, rpath=False, version_script=False, 
msg=None):

bld.compile()
except with a file not found


Portage 2.2.0_alpha111 (default/linux/amd64/10.0, gcc-4.6.3,
glibc-2.15-r2, 3.4.1-vs2.3.3.4 x86_64)
=
System uname: 
Linux-3.4.1-vs2.3.3.4-x86_64-Intel-R-_Core-TM-_i7-2600_CPU_@_3.40GHz-with-gentoo-2.1

Timestamp of tree: Sun, 24 Jun 2012 19:30:01 +
distcc 3.1 x86_64-pc-linux-gnu [enabled]
ccache version 3.1.7 [disabled]
app-shells/bash:  4.2_p20
dev-java/java-config: 2.1.11-r3
dev-lang/python:  2.7.3-r2
dev-util/ccache:  3.1.7
dev-util/cmake:   2.8.7-r5
dev-util/pkgconfig:   0.26
sys-apps/baselayout:  2.1-r1
sys-apps/openrc:  0.10.3
sys-apps/sandbox: 2.5
sys-devel/autoconf:   2.13, 2.68
sys-devel/automake:   1.10.3, 1.11.1
sys-devel/binutils:   2.22-r1
sys-devel/gcc:4.5.3-r2, 4.6.3, 4.7.1
sys-devel/gcc-config: 1.7.3
sys-devel/libtool:2.4-r1
sys-devel/make:   3.82-r1
sys-kernel/linux-headers: 3.4 (virtual/os-headers)
sys-libs/glibc:   2.15-r2
Repositories: gentoo vivovl mysql
ACCEPT_KEYWORDS="amd64"
ACCEPT_LICENSE="*"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O2 -march=corei7-avx -pipe -frecord-gcc-switches -mno-movbe
-mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-tbm
--param l1-cache-size=32 --param l1-cache-line-size=64 --param
l2-cache-size=8192 -mtune=corei7-avx -fgcse-after-reload
-fpredictive-commoning -ftree-vectorize -funswitch-loops
-fgraphite-identity -floop-block -floop-interchange -floop-strip-mine
-ggdb -gdwarf-4 -fvar-tracking-assignments"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/config /usr/share/gnupg/qualified.txt
/usr/share/openvpn/easy-rsa /usr/share/themes/oxygen-gtk/gtk-2.0"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d
/etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release
/etc/php/apache2-php5.3/ext-active/ /etc/php/cgi-php5.3/ext-active/
/etc/php/cli-php5.3/ext-active/ /etc/revdep-rebuild /etc/sandbox.d
/etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d
/etc/texmf/updmap.d /etc/texmf/web2c"
CXXFLAGS="-O2 -march=corei7-avx -pipe -frecord-gcc-switches -mno-movbe
-mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-tbm
--param l1-cache-size=32 --param l1-cache-line-size=64 --param
l2-cache-size=8192 -mtune=corei7-avx -fgcse-after-reload
-fpredictive-commoning -ftree-vectorize -funswitch-loops
-fgraphite-identity -floop-block -floop-interchange -floop-strip-mine
-ggdb -gdwarf-4 -fvar-tracking-assignments
-fvisibility-inlines-hidden"
DISTDIR="/g/distfiles"
EMERGE_DEFAULT_OPTS="--ask-enter-invalid --quiet-build=y"
FCFLAGS="-O2 -pipe"
FEATURES="assume-digests binpkg-logs buildpkg compress-build-logs
compressdebug config-protect-if-modified distcc distlocks ebuild-locks
fail-clean fixlafiles installsources metadata-transfer news noinfo
notitles parallel-fetch parallel-install parse-eapi-ebuild-head
sandbox sfperms splitdebug strict test-fail-continue
unknown-features-warn unmerge-logs unmerge-orphans xattr"
FFLAGS="-O2 -pipe"
GENTOO_MIRRORS="http://mirror.netcologne.de/gentoo/
http://mirror.ovh.net/gentoo-distfiles/
http://mirror.switch.ch/ftp/mirror/gentoo/ http://gentoo.lagis.at/
http://mirror.qubenet.net/mirror/gentoo/";
INSTALL_MASK="/usr/lib64/libogrove.la /usr/lib64/libospgrove.la
/usr/lib64/libostyle.la
/usr/lib64/vlc/plugins/codec/libdirac_plugin.la
/usr/lib64/vlc/plugins/demux/libdirac_plugin.la /bin/systemd
/bin/systemctl /usr/lib64/elektra/libelektra-filesys.la
/usr/lib64/elektra/libelektra-hosts.la
/usr/lib64/elektra/libelektra-ini.la
/usr/lib64/elektra/libelektra-passwd.la /usr/lib64/libelektra-cpp.la
/usr/lib64/libelektra.la /usr/lib64/libelektratools.la "
LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,-O1 -Wl,--hash-style=gnu
-Wl,--as-needed -Wl,--sort-common -Wl,--no-copy-dt-needed-entries
-Wl,--build-id "
LINGUAS="it"
MAKEOPTS="-j36"
PKGDIR="/g/packages"
PORTAGE_COMPRESS="lzma"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times
--compress --force --whole-file --delete --stats --human-readable
--timeout=180 --exclude=/distfiles --exclude=/local
--exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/g/portage"
PORTDIR_OVERLAY="/g/ovl/tmp /g/ovl/mysql"
SYNC="rsync://rsync.gentoo.or

Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?

[viv...@gmail.com]

Il 02/07/2012 22:01, Zac Medico ha scritto:

On 07/02/2012 12:48 PM, Pacho Ramos wrote:

El lun, 28-05-2012 a las 14:34 -0700, Zac Medico escribió:

Hi,

In case you aren't familiar with FEATURES=userpriv, here's the
description from the make.conf(5) man page:

   Allow portage to drop root privileges and compile packages as
   portage:portage without a sandbox (unless usersandbox is also used).

The rationale for having the separate "usersandbox" setting, to enable
use of sys-apps/sandbox, is that people who enable userpriv sometimes
prefer to have sandbox disabled in order to slightly improve
performance. However, I would recommend to enable usersandbox by
default, for the purpose of logging sandbox violations.

Note that ebuilds can set RESTRICT="userpriv" if they require superuser
privileges during any of the src_* phases that userpriv affects.

I've been using FEATURES="userpriv usersandbox" for years, and I don't
remember experiencing any problems because of it, so I think that it
would be reasonable to have it enabled by default. Objections?

Looks like non important problems arised and, then, these could probably
be enabled by default, no? :)

I'm not sure about the best way to handle migration for directories
inside $DISTDIR that are used by live ebuilds, since src_unpack will run
with different privileges when userpriv is enabled.
tell the user to chown/remove the files/directories if and when needed, 
unless there is a very good reason (try) to automate it.

Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?

[viv...@gmail.com]

Il 02/07/2012 22:45, Zac Medico ha scritto:

On 07/02/2012 01:36 PM, viv...@gmail.com wrote:

Il 02/07/2012 22:01, Zac Medico ha scritto:

On 07/02/2012 12:48 PM, Pacho Ramos wrote:

El lun, 28-05-2012 a las 14:34 -0700, Zac Medico escribió:

Hi,

In case you aren't familiar with FEATURES=userpriv, here's the
description from the make.conf(5) man page:

Allow portage to drop root privileges and compile packages as
portage:portage without a sandbox (unless usersandbox is also used).

The rationale for having the separate "usersandbox" setting, to enable
use of sys-apps/sandbox, is that people who enable userpriv sometimes
prefer to have sandbox disabled in order to slightly improve
performance. However, I would recommend to enable usersandbox by
default, for the purpose of logging sandbox violations.

Note that ebuilds can set RESTRICT="userpriv" if they require superuser
privileges during any of the src_* phases that userpriv affects.

I've been using FEATURES="userpriv usersandbox" for years, and I don't
remember experiencing any problems because of it, so I think that it
would be reasonable to have it enabled by default. Objections?

Looks like non important problems arised and, then, these could probably
be enabled by default, no? :)

I'm not sure about the best way to handle migration for directories
inside $DISTDIR that are used by live ebuilds, since src_unpack will run
with different privileges when userpriv is enabled.

tell the user to chown/remove the files/directories if and when needed,

How should we tell them? Elog message, news item, or both?
both seem reasonable, additionally emerge will and should fail when it 
meet a incorrect owned directory, the most sensitive place where to 
output the message is exactly there if possible.
"Failed to update $DIR, check permission and/or correctness, as a last 
resort remove it" something like this, written by someone who speak english.

unless there is a very good reason (try) to automate it.

I guess something like this might work in pkg_postinst of the portage
ebuild:

   find "$DISTDIR" -maxdepth 1 -type d -uid 0 | xargs chown -R
portage:portage

I would only trigger something like this once, when upgrading from a
version that doesn't have userpriv enabled by default.
ba, I've totally inverted the logic, it was meant "do _not_  
automate it", even if the chown work flawlessy it become additional 
cruft that will be forever with us.


thanks,
Francesco

Re: [gentoo-dev] Kernel compiles and you

[viv...@gmail.com]

Il 05/07/2012 10:27, Tobias Klausmann ha scritto:
I vaguely remembered the rm-rf bug, but I was unable to find any 
reference to it (at least not easily), do you happen to have a 
pointer? Regards, Tobias 


neither I, but look at this bug for an example
http://lkml.indiana.edu/hypermail/linux/kernel/0601.2/0877.html

start search:
linus "build as root" kernel "2.6.16" "rm -f"

Re: [gentoo-dev] RFC: virtual/libudev

[viv...@gmail.com]

Il 11/07/2012 22:33, Mike Gilbert ha scritto:

On Wed, Jul 11, 2012 at 3:54 PM, William Hubbs  wrote:

On Wed, Jul 11, 2012 at 03:27:41PM -0400, Mike Gilbert wrote:

Just to put a number to this, there are currently 126 packages in the
tree with a dependency on sys-fs/udev.

Personally, I think a consolidated systemd/udev package is the best
way to go here. Short of that, the virtual + blockers seems like an
acceptable solution.

Thinking on this, I agree with Mike here, and to make it easier for
maintainers so they don't have to change their dependencies, it should
be a udev ebuild with a systemd use flag.


An alternative to the funky udev[systemd] solution would be to replace
the entire udev ebuild with RDEPEND="sys-apps/systemd", and implement
the requisite logic in the systemd ebuild. This would effectively make
udev a virtual package without the need to modify any other packages.
Long time ago portage managed virtual/* ebuilds differently from the 
others, it may be wise to ask to the portage developers if that's still 
the case and why/what is done.

Re: [gentoo-dev] Portage FEATURE suggestion - limited-visibility builds

[viv...@gmail.com]

Il 31/07/2012 21:27, Michał Górny ha scritto:

On Tue, 31 Jul 2012 15:16:34 -0400
Rich Freeman  wrote:


On Tue, Jul 31, 2012 at 10:56 AM, Ian Stakenvicius
wrote:

Although that is true, it would be -WAY- too slow to generate said
list via equery/q* helpers; I think that's where the
extended-attributes and/or cache idea comes into play.

I agree.  This needs to be high-performance when it comes to
individual file access.  If it takes 10 seconds per build to populate
some database or set up a bazillion bind mounts that isn't the end of
the world, but if it takes an extra 0.1 seconds every time a file is
read that could add up VERY fast on a large build.

I'd be more afraid about resources, and whether the kernel will be
actually able to handle bazillion bind mounts. And if, whether it won't
actually cause more overhead than copying the whole system to some kind
of tmpfs.
If testing show that bind mounts are too heavy we could resort to 
LD_PRELOAD a library that filter the acces to the disk,

or to rework sandbox to also hide w/o errors some files,
with an appropriate database (sys-apps/mlocate come to mind) every 
access will have negligible additional cost compared to that of 
rotational disks.

Ideally I'd like to see the same thing extended to run-time, and short
of writing some entirely new security model into the kernel or taking
namespaces to a whole new level, part of me thinks that
auto-generating SELinux policies might be the solution, so that the
existing mechanism can be extended.

The mad scientist in me keeps thinking up crazy schemes so that
package collisions can be handled by each package just seeing whatever
it wants to see - maybe the entire filesystem looks different
depending on what app you use.  Then I realize that bash is an
application, and how on earth would a human make sense of a system
where no file has any stable identifier other than maybe a
content-hashed key.  Then that makes me wonder why we link to
libraries by filename anyway, when we could just give each library a
GUID and version, and maybe a more general identifier for cases where
you have alternate implementations.

But, as long as we're still just running Gentoo on Unix-like OSes
maybe tweaking the jail is a good place to start...

Rich

Re: [gentoo-dev] Re: gentoo-x86 commit in dev-perl/XML-Parser: XML-Parser-2.410.0-r1.ebuild ChangeLog

[viv...@gmail.com]

Il 07/08/2012 18:26, Fabian Groffen ha scritto:

On 07-08-2012 18:03:14 +0200, Torsten Veller wrote:

* "Fabian Groffen (grobian)":

grobian 12/08/07 15:21:54

   Modified: ChangeLog
   Added:XML-Parser-2.410.0-r1.ebuild
   Log:
   Fix expat detection for FreeBSD that silently went unnoticed.

The following single quotes were dropped:

-myconf="EXPATLIBPATH='${EPREFIX}/usr/$(get_libdir)' 
EXPATINCPATH='${EPREFIX}/usr/include'"
+myconf="EXPATLIBPATH=${EPREFIX}/usr/$(get_libdir) 
EXPATINCPATH=${EPREFIX}/usr/include"

Sorry, I don't understand the problem. Is it a general problem with
the single quote or a special FreeBSD problem?

I've only observed it happening on FreeBSD indeed.

does this work?
myconf="\"EXPATLIBPATH=${EPREFIX}/usr/$(get_libdir)\" 
\"EXPATINCPATH=${EPREFIX}/usr/include\""


and does thos work with spaces in EPREFIX, are they allowed in there at all?
myconf="EXPATLIBPATH=${EPREFIX}/usr/$(get_libdir) 
EXPATINCPATH=${EPREFIX}/usr/include"





I think we should convert all myconf strings to arrays:
myconf=( EXPATLIBPATH="${EPREFIX}"/usr/$(get_libdir) 
EXPATINCPATH="${EPREFIX}"/usr/include )

I don't understand enough of the Makefile.PL thing to tell why the
quotes work on Darwin, Solaris, but not FreeBSD 9.1-BETA1.  I do know
that EPREFIX cannot contain spaces though, hence I applied the fix as
committed.  If the array approach works with the eclass, then that'll be
certainly cleaner.

yep

Re: [gentoo-dev] Questions about SystemD and OpenRC

[viv...@gmail.com]

Il 07/08/2012 14:47, Sylvain Alain ha scritto:
Hi everyone, for a couple of months now, I see on the list some of 
activities about OpenRC been ported to FreeBSD or OpenRC to Debian and 
other stuff related to SystemD.


I have some basic questions about all that :

1. The SystemD and Udev projetcs are merged now, so what is the impact 
on the Gentoo on a short term period ?

The answer is in the hand of others, I sincerely hope someone will fork


2. I saw on some lists that Gnome/Kde and Xfce plan to use some 
SystemD API, so does it means that we will need to install SystemD 
aside of OpenRC ?

It's not possible at the moment. systemd break non-systemd setups.



3. In a long term vision, can OpenRC still exist on a Gentoo 
box(OpenRC might be able to boot the box then give the control to 
SystemD/Udev for the rest of the boot process)  or we will need to 
migrate to SystemD to be able to use Gnome/Kde or Xfce ?
PID 1 has some own properties, but systemd can work at user privileges, 
maybe


4. Finally, is there any reason why Gnome/Kde/Xfce wants to add deps 
related to SystemD ? I don't understand why these desktops want to 
depend on a specific Sysint


Because starting daemons it's much more error prone than everyone 
thinks, at least everyone which didn't become involved in coding for it.


And now my personal rant with some considerations, from memory, may be 
not totally accurate.


Tried systemd (SD from now) the other day, as everyone knows it need to 
rebuild some part of the system with the "systemd" use flag.
These things broke when not started by SD, for example pulseaudio, had 
problems also with auto-mount possibly more not even noticed.


This box has 3 disk:
sda) ssd on sda for gentoo whole disk (not partitioned)
sd{b,c})  /home /srv /boot md raid 1

First problem udev/SD has is that it can't see all the file system 
labels, for some reason it only see sda and sdb so it's able to partly 
proceed in the boot sequence, mount / (root) but can't mount anything else.


After putting in fstab the real /dev paths (something really old siecle) 
manually mount them with systemctl --ignore-deps (the name of the option 
is different please bear with me) works but the dependancies are not 
satisfied, for two reasons:
a) SD does not re-calculate it's deptree/services when exiting from 
rescue shell, it still try to start the "virtual" services as fstab 
would have never modified, a reboot is needed
b) since it does not work even after reboot, there must be something 
else, but what? this bring us to the point


SD has mainly two things to debug boot `systemctl dump` and 
`systemd-journal` but the very much magnified advantages of the binary 
log^W journal are totally invisible in this case because it's 
difficult^W nearly impossible even to understand WHAT failed to start, 
not to mention WHY


the magnificient binary log^W^W journal is kept on tmpfs (in ram) so 
it's not even available at boot in different situation.


every try needed many minutes because SD wait for a long timeout before 
going to the rescue shell, gave up after few hours of try, upgrading 
Vista SP0 to current needed less reboot and time.


But this has been beneficial because I've now realized few important 
things that will be probably never disappear from SD and will be there 
forever, things that make me think this stuff is really dangerous.


List of problems that will _never_ be fixed

- SD does not see anything else than systemd for boot.
Interaction with SD from a livecd, is difficult, almost all tools don't 
work because SD is not running.
transported on remote server administration this is a *nightmare*, 
various provider offer livecd like system which don't offer SD.
so no easy migration, no easy first install, every failure is 
definitive, a no go


- the journal will never become simpler, can only grow, debugging things 
in the shell will be nearly impossible for excess of data (and lack of 
useful one if it continue this way)


- virtual/autogenerated services are and will be difficult to cope with, 
impossible to disable


- every change in the early boot procedure will require reboot

- which sum to: SD will work until it work, when something does not will 
be a royal pain to solve _and_ nothing else other than SD will be 
available to alleviate the pain


difficult to accept for the desktop, impossible for the server.

written by someone which like _some_ of the SD stuff.

Re: [gentoo-dev] Re: Questions about SystemD and OpenRC

[viv...@gmail.com]

Il 12/08/2012 11:43, Duncan ha scritto:

Peter Stuge posted on Sun, 12 Aug 2012 02:12:38 +0200 as excerpted:


viv...@gmail.com wrote:

First problem udev/SD has is that it can't see all the file system
labels, for some reason it only see sda and sdb so it's able to partly
proceed in the boot sequence, mount / (root) but can't mount anything
else.

What software parses the filesystem labels when you boot with openrc?

(I ask because I never use labels myself.)

Short answer, mount and udev, and the kernel directly when fed that
information for root= on the kernel commandline.  Openrc has basically
nothing to do with it.  As such, I don't know what systemd's doing, but
if it indeed is a systemd bug, it's obviously doing /something/ rather
different... probably interacting in some unpredicted way with udev now
that they're integrating it.


exactly my bet, since openrc with the _same_ (not recompiled) udev does work



Slightly more detail, quoting the mount (8) manpage:

It is possible to indicate a block special device using its volume LABEL
or UUID (see the -L and -U options below).

The recommended setup is to use LABEL=  or UUID=  tags rather
than /dev/disk/by-{label,uuid} udev symlinks in the /etc/fstab file.
The tags are more readable, robust and portable. The mount(8) command
internally uses udev symlinks, so use the symlinks in /etc/fstab has no
advantage over LABEL=/UUID=. For more details see libblkid(3).

Note that mount(8) uses UUIDs as strings. The UUIDs from command line or
fstab(5) are not converted to internal binary representation. The string
representation of the UUID should be based on lower case characters.

<<<<<

The implication of the "as strings, not converted to binary" in the last
paragraph is that mount's simply doing a dumb string match against the
appropriate /dev/disk/by-* symlink names and dereferencing the symlink
after which it can proceed as usual if there's a match.  It's udev (and
thus now systemd, since they're combining) that's actually doing the
work, exposing the /dev/disk/by-* symlinks with the correct references.

As such, mount basically supports anything found in that location,
including device hardware ID (combined with partition number where
appropriate, listed in /dev/disk/by-id), the already mentioned filesystem
LABEL (/dev/disk/by-label), PARTLABEL (GPT partitions have a partition
label that's similar in function to the filesystem label, but set at gdisk
time, not mkfs time, obviously this doesn't apply to legacy MBR
partitioning), PARTUID, PATH (bus path, tho like traditional /dev/[hs]dX,
this can be dynamic and the bus paths are longer and more obtuse for
humans so there's generally little practical use for this one), and (as
the manpage mentions, partition) UUID.

It is however worth noting that PARTLABEL at least is new enough that at
least as of a couple months ago when I looked at it for my md/raid setup,
while udev passed thru the PARTLABEL for physical devices, it was NOT
doing so for partitioned md/raid devices.  (That mobo died and I don't
have md/raid on the new system so I can't verify current kernel 3.6-rc1+
and udev-187-r3 PARTLABEL-on-md/raid behavior.)  So while people could
setup their md/raid gpt partitions with partition-labels using gptfdisk
(aka gdisk) or whatever, and I did so, only the ones on the physical
disks showed up in udev, and at the time I was looking at it, I was
running md/raid on virtually everything, so the feature was about useless
for me.

But that does mean that if mdev or whatever creates similar /dev/disk/by-
*, that mount and friends should use it just as they would with udev,
since all they're doing is a dumb string match and symlink deref.

It'a also worth noting that the kernel's root= line can take a number of
these (I'm not sure if it can take them all), including partlabel,
according to information someone posted on the btrfs list (which I was
following at the time, before I decided btrfs was too unstable still and
that I'd wait until next year to try again).  I was going to try it, but
lost interest when I found I couldn't use it with fstab for my mdraid-
based gpt partitions anyway.  So all I can say is that it was reported to
work on the btrfs list, and no one contradicted it, so...


a) SD does not re-calculate it's deptree/services when exiting from
rescue shell, it still try to start the "virtual" services as fstab
would have never modified, a reboot is needed

systemctl --system daemon-reload ?

I've not tried systemd yet nor have I yet researched it (I have the
research vaguely scheduled for next year, sometime), but thanks to both
of you for these details.  Based on past experience, I expect I'm
collecting the pieces even tho I don't have context to assemble them in,
but as a result, when I /do/ research it and get that context, th

Re: [gentoo-dev] Re: Questions about SystemD and OpenRC

[viv...@gmail.com]

Il 12/08/2012 14:25, Rich Freeman ha scritto:

On Sun, Aug 12, 2012 at 5:43 AM, Duncan<1i5t5.dun...@cox.net>  wrote:

Peter Stuge posted on Sun, 12 Aug 2012 02:12:38 +0200 as excerpted:

What software parses the filesystem labels when you boot with openrc?

(I ask because I never use labels myself.)

Short answer, mount and udev, and the kernel directly when fed that
information for root= on the kernel commandline.
...
It'a also worth noting that the kernel's root= line can take a number of
these (I'm not sure if it can take them all), including partlabel,
according to information someone posted on the btrfs list

I'm pretty sure that this particular part of your post is incorrect,
but I'd be happy to be corrected.

The kernel cannot interpret a root= parameter that doesn't reference a
device node that it can't internally generate (with a devtmpfs/etc).
I'm pretty sure that rules out just about anything but a physical
device (not even /dev/by-uuid/...).

I think that people get this confused because 99% of linux users have
an initramfs (and about 2% of Gentoo users it seems), and most
initramfs implementations DO interpret the root=parameter.  If you
specify an initramfs then the kernel actually ignores the
root=parameter entirely, mounting the initramfs as root, and passing
control to its init.  The initramfs is expected to mount root (or not
- you could just run the whole system off an initramfs I guess).  Most
initramfs implementations just parse the root= line on the kernel,
although it is worth noting that genkernel's initramfs does not and
uses real_root instead.

So, I could see how many linux users might think that interpreting a
complex root= parameter is a kernel function, when it is really just
the fact that they use an initramfs.

If somebody is running with root=LABEL=foo or something like that
without an initramfs I'll happily stand corrected.

Rich

Yes it's incorrect, a kernel w/out initrd is not able to mount by LABEL, 
even with automounted /dev

experienced few weeks ago.

Re: [gentoo-dev] Questions about SystemD and OpenRC

[viv...@gmail.com]

Il 12/08/2012 09:44, Michał Górny ha scritto:

On Sun, 12 Aug 2012 01:29:43 +0200
"viv...@gmail.com"  wrote:


2. I saw on some lists that Gnome/Kde and Xfce plan to use some
SystemD API, so does it means that we will need to install SystemD
aside of OpenRC ?

It's not possible at the moment. systemd break non-systemd setups.

Elaborate.

I do my best to make it possible to be able to do at least minimal
OpenRC boot when systemd is used (for fallback). Even during the time
of 'systemd providing udev' systemd depended on udev-init-scripts
to ensure that openrc was able to boot.


enable systemd USE flag, start with openrc.
Pulseaudio will break, I suspect automount will break too, worried the 
list will grow.

Re: [gentoo-dev] EJOBS variable for EAPI 5?

[viv...@gmail.com]

Il 04/09/2012 19:15, Zac Medico ha scritto:

On 09/04/2012 04:00 AM, Walter Dnes wrote:

On Sat, Sep 01, 2012 at 05:20:02PM -0700, Brian Harring wrote


This approach is fine imo, although I'd *potentially* look at adding a
magic $PROC_COUNT var that is the # of cpu threads on the system;
either that or defaulting jobs to it.

I rather dislike requiring users to go jam a 2/4/8 in there when it's
easy to compute.  That said, it's minor.

Either way, yes, I think EJOBS should be in EAPI5.

   One question about the suggested EJOBS variable; will it over-ride
MAKEOPTS?  Every so often on the Gentoo-user list, someone comes along
with a mysterious build failure.  The first suggestion is to reset
MAKEOPTS to -j1.  And on some occasions, that is indeed the solution to
the mysterious build failure.

That would be due to a missing dependency in the Makefiles, and using
-j1 is just a workaround. The ebuild can be hardcoded to use emake -j1
until the Makefile gets fixed.


   I set -j1 and leave it that way.  Yes, the builds take longer, but the
resulting binary is just as fast.  And the amount of time I "save" will
be blown away the first time I end up screwing around a couple of hours
trying to fix a mysterious build failure.  That's why I want the user to
have the option of over-riding EJOBS, should it ever be implemented.

You could use EXTRA_EMAKE for that. You can do per-package settings via
/etc/portage/package.env.


Dunno where to place this request, but if we go for something like EJOBS 
could we also make it phase specific?

So compile, install and test could have a different number of jobs running.
Possibly three different variables that override a predefined EJOBS.

TIA

Re: [gentoo-dev] EJOBS variable for EAPI 5?

[viv...@gmail.com]

Il 11/09/2012 18:43, Zac Medico ha scritto:

On 09/11/2012 09:36 AM, viv...@gmail.com wrote:

Dunno where to place this request, but if we go for something like EJOBS
could we also make it phase specific?
So compile, install and test could have a different number of jobs running.
Possibly three different variables that override a predefined EJOBS.

Per-phase sounds a little to fine-grained. Instead, I'd suggest to add
an ELOADAVG variable that's analogous to make's --load-average option.
That should be enough to compensate for any differences between phases.
ok, but in my experience load-average really is too limited so I 
relaunch with the ability to control the following:

- disk io
- network
- memory
- cpu
- jobs

just tough that being able to control just jobs in a phase specific 
manner could have been sufficed ;-)
Also this seem is a good job for containers, already implemented in the 
linux kernel, but will let someone with experience with them comment on 
the mattter.

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[viv...@gmail.com]

Il 18/09/2012 11:38, Ulrich Mueller ha scritto:

Which is longer than the original.;-)

Ulrich
RDEPEND=">=sys-libs/zlib-1.1.4 >=app-arch/bzip2-1.0.2 app-arch/xz-utils" 
DEPEND="${RDEPEND} virtual/pkgconfig"
DEPENDENCIES=">=sys-libs/zlib-1.1.4 >=app-arch/bzip2-1.0.2 
app-arch/xz-utils" dep:build?(virtual/pkgconfig)"


is DEPENDENCIES "the original"?

Re: [gentoo-dev] About DESCRIPTION in ebuilds needing to end with a dot "."

[viv...@gmail.com]

Il 19/10/2012 21:36, Thomas Sachau ha scritto:

Pacho Ramos schrieb:

Hello

At least in spanish, it's mandatory to end phrases with a dot ".", would
you agree with trying to enforce this trivial change with a repoman
warning?

Thanks for your opinions


I dont know any such requirement from english nor german and neither do
i see any benefit from adding a dot at the end of the DESCRIPTION
variable. So if you want to have a unified behaviour all over the tree,
i would request all descriptions to be without the final dot.


+1

Re: [gentoo-dev] Last rites: app-admin/profiler

[viv...@gmail.com]

Il 28/11/2012 00:04, Sebastian Pipping ha scritto:

# Sebastian Pipping  (27 Nov 2012)
# Masked for removal in 30 days.
# Licensing issues, turned out not distributable (bug #444332)
app-admin/profiler

uhm, maybe for licensing issues the grace period of 30 days could be 
shortened (not that I care)

Re: [gentoo-dev] Defaulting for debug information in profiles

[viv...@gmail.com]

Il 17/12/2012 11:42, Diego Elio Pettenò ha scritto:

On 17/12/2012 11:33, Sven Eden wrote:

on my system I have set up everything with splitdebug enabled. My CFLAGS use -
march=native, -O2 and -ggdb.

That's  -ggdb that increases the size.



In short FEATURES=compressdebug should be stable and default before you 
(gentoo) decide for something like this.
As mentioned somewhere else in this thread some packages are on the 
unbeareable side when compiled with debug information, those should 
default to filter out debug flags if not actually wanted by the user 
USE=gdb maybe?
When going with debug information the best available should be used so 
-ggdb not -g if possible.
Please try to understand the differences between the  various options 
(nodebug, -g, -ggdb) versus (time to build, memory needed, disk space) 
before attempting this.

Diego maybe it's worth some runs in the tinderbox.

Some numbers:

Packages installed:   1756
Packages in world:626
Packages in system:   42
Required packages:1756
Number to remove: 0


ECFLAGSbase='-O2 -march=corei7-avx -pipe -frecord-gcc-switches'
ECFLAGSnative='-mno-movbe -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop 
-mno-bmi -mno-tbm --param=l1-cache-size=32 --param=l1-cache-line-size=64 
--param=l2-cache-size=6144 -mtune=corei7-avx'
ECFLAGSnative="${ECFLAGSnative} -mno-bmi2 -mno-avx2 -mno-lzcnt -mrdrnd 
--param=l1-cache-size=32"
ECFLAGSo3='-fgcse-after-reload -fpredictive-commoning -ftree-vectorize 
-funswitch-loops' # O3 - -finline-functions -fipa-cp-clone
ECFLAGSgraphite='-fgraphite-identity -floop-block -floop-interchange 
-floop-strip-mine' # graphite & co (-fira-loop-pressure no good amd64)


ECFLAGSdbug='-ggdb -gdwarf-4 -fvar-tracking-assignments'

ECFLAGSlto=''
CFLAGS="${ECFLAGSbase} ${ECFLAGSnative} ${ECFLAGSo3} ${ECFLAGSgraphite} 
${ECFLAGSlto} ${ECFLAGSdbug}"

CXXFLAGS="${CFLAGS} -fvisibility-inlines-hidden"
ELDFLAGSoptimize='-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed 
-Wl,--sort-common -Wl,--no-copy-dt-needed-entries'


ELDFLAGSdebug='-Wl,--build-id'

ELDFLAGSlto=''
LDFLAGS="${LDFLAGS} ${ELDFLAGSoptimize} ${ELDFLAGSdebug}"


FEATURES="${FEATURES} splitdebug installsources compressdebug"

du -csh /usr/lib/debug/ /usr/src/debug/
5,5G/usr/lib/debug/
3,9G/usr/src/debug/
9,4Gtotale

find /usr/* -maxdepth 0 -type d -not -name src -not -name portage -exec 
echo  {} +
/usr/armv7a-hardfloat-linux-gnueabi /usr/bin /usr/brlcad /usr/data 
/usr/etc /usr/fakelib /usr/gnu-classpath-0.98 /usr/include /usr/lib32 
/usr/lib64 /usr/libexec /usr/local /usr/man /usr/Mod /usr/sbin 
/usr/share /usr/x86_64-pc-linux-gnueabi


find /usr/* -maxdepth 0 -type d -not -name src -not -name portage -exec 
du -csh {} +

38M /usr/armv7a-hardfloat-linux-gnueabi
825M/usr/bin
86M /usr/brlcad
1,3M/usr/data
16K /usr/etc
8,0K/usr/fakelib
12M /usr/gnu-classpath-0.98
425M/usr/include
392M/usr/lib32
11G /usr/lib64  <== 5,5G/usr/lib/debug/
415M/usr/libexec
28K /usr/local
304K/usr/man
18M /usr/Mod
81M /usr/sbin
3,3G/usr/share
27M /usr/x86_64-pc-linux-gnu
17G totale

Re: [gentoo-dev] Defaulting for debug information in profiles

[viv...@gmail.com]

Il 17/12/2012 11:11, Tomáš Chvátal ha scritto:

Hi lads,
lately I am having bit of problems from getting relevant debug info from users.

Since we already have splitdebug for quite time (and I suppose quite
few of us are using it) how about making it to default profiles
default enabled and add -g to default cflags. Currently it is only
enabled in the developer profile.

This results in 2 gb data in /usr/lib/debug for my system which is not
that bad with current disk sizes and it saves users quite some time
when i have to request them to recompile half of their system with
debug info just to get idea how to fix their issue.

I would go even for compressdebug feature but that one needs more time
as some packages like glibc fails to merge with it and you need newer
gdb to work with it.

Cheers

Tom



By the way gcc-4.8 will have support for -gsplit-dwarf, should be 
something similar to split-debug, just done pre linking and with 
different file names.
While I've no idea how this feature work, probably start planning would 
be beneficial.


   -gsplit-dwarf
   Separate as much dwarf debugging information as possible into a 
separate output file with the extension .dwo.
   This option allows the build system to avoid linking files with 
debug information.
   To be useful, this option requires a debugger capable of reading 
.dwo files.




Also thinking about this a bit more, seem a binpkg for debug stuff can 
be interesting, similarly to how binary distro do.

rogue example implementation:
with FEATURE="buildpkg split-debug-pkg"
all the /usr/lib/debug and /usr/src/debug files are put in a separate 
package debug/category/pn or similarly to sec-policy/selinux* debug/cat--pn
the user can then install debug packages at will, the dependancies 
should work (and clone those of the real package) but not be mandatory.


how difficult would be to implement this in portage (keep in mind that 
packages are coupled and should stay that way also for unmerge and 
whatever)?

Would be possible to have FEATURE=" -buildpkg  split-debug-pkg"?

A similar feature would be useful for linguas support but more difficult 
to implement.

Re: [gentoo-dev] Is /var/cache the right place for repositories?

[viv...@gmail.com]

Il 24/12/2012 10:11, Ciaran McCreesh ha scritto:

On Mon, 24 Dec 2012 03:17:06 +0100
Sebastian Pipping  wrote:

On 20.12.2012 19:14, Ciaran McCreesh wrote:

The tree is a database. It belongs in /var/db/.

yes and no,
yes it contain data and executable needed to update gentoo system, in a 
hierarchical and relational form

no, it's a cache of a remote database generally mantained from others.

Actually also the difference in importance between /var/db/pkg and 
//ebuild_tree is very high.
Loose the pkg db and your best plan is to re-emerge the entire world, 
provided you still have a copy of /var/lib/portage/world (or 
equivalent), loose the latter and have a laugh.

To put those in the same category seem risky

Not that I personally care since everything gentoo related is kept in /g 
on my systems, also this for various reason mainly because it's 
something used to mantain a system and if maintainaince is not needed 
it's very easy this way to remove.



I don't see /var/db in the latest release of the Filesystem Hierarchy
Standard:

   http://www.pathname.com/fhs/pub/fhs-2.3.html#THEVARHIERARCHY

I would prefer something that blends with FHS.

That's ok, Gentoo doesn't follow FHS.

And it's ok to "prefere" to stay near a standard and use it as a 
guideline, for various reason, less difference with others and because a 
bunch of people has already toughted on it, to name just two.

Raising to "MUST blend" would be indeed not beneficial.

Regards,
Francesco Riosa

Re: [gentoo-dev] GCC 4.6 stabilization

[viv...@gmail.com]

Il 07/01/2013 17:13, Richard Yao ha scritto:

On 01/06/2013 08:22 PM, Ryan Hill wrote:

This is way past due so I'd like to get 4.6 into stable.  There are hardly any
blockers on bug #418383 which makes me go "?!", so if anyone knows of any
issues please let us know.




We probably should not stabilize on ARM until the following is fixed:

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

Other architectures are probably okay.


What about jumping straight to 4.7.2 do you (arm-team) think it's possible?

Re: [gentoo-dev] call for testers: udev predictable network interface names

[viv...@gmail.com]

Il 16/01/2013 17:25, Mike Gilbert ha scritto:

On Wed, Jan 16, 2013 at 10:19 AM, Tobias Klausmann  wrote:

Hi!

On Tue, 15 Jan 2013, Greg KH wrote:

So anyone who relies on network names right now to be deterministic, and
you have more than one network device in your system, should seriously
reconsider how they are naming their devices, as it will not work if you
only rely on the kernel.

You might have gotten "lucky" for the past 5 years, but you never know
what could happen if you reboot today.  Seriously, I've seen it happen
all the time.

It has been rather nifty that if I walk up to a random machine
with exactly one NIC (that I've been asked to examine/fix), I
_know_ that there will be eth0 and only that.

OTOH, maybe it's a good idea to make admins do "ip link sh" and
"ip addr sh" every time they examine a new computer -- it goes a
long way to root out wrong assumptions in that field.

Regards,
Tobias

PS: Do not use ifconfig. Ever. Except if there's no iproute. And
then you should only use ifconfig to enable downloading of
iproute :)


I would actually like to see iproute2 added to the system set.

additionally (or indipendently) I would like to see it in bin instead of 
sbin

Re: [gentoo-dev] RFC: new "qt" category

[viv...@gmail.com]

Il 17/01/2013 14:57, Ben de Groot ha scritto:

Hi guys,

Presently we already have a good number of split qt-* library packages
in x11-libs. With the arrival of Qt5 upstream has gone a lot further
in modularization, so we expect the number of packages to grow much
more. We, the Gentoo Qt team, are of the opinion that the time has
come to split all these out into their own category. This category is
to be used for the various modules and applications that belong to the
upstream Qt Framework only (these include e.g. assistant and
linguist). Third-party applications should remain in the current
categories.

After some initial bikeshedding we came to the conclusion that naming
the category simply "qt" is the most elegant solution.

+1 but use a '-' in the category qt-dev or qt-libs


  We will then
also be dropping the qt- prefix in package names. This means
x11-libs/qt-core will be moved to qt/core, and so on.

-1
Because it would be nice to move there also qwt* and possibly other libs.
qt-libs/qt-core make it easyer to separate them


Please let us know your thought on this.

thanks for asking

Re: [gentoo-dev] call for testers: udev predictable network interface names

[viv...@gmail.com]

Il 09/01/2013 23:13, William Hubbs ha scritto:

All,

as you probably know by now, udev-197 has hit the tree.

This new version implements a new feature called predictable network
interface names [1], which I have currently turned off for live systems, 
because it
will require migration on the part of the user.

When you upgrade to this new version of udev, you will find a file
/etc/udev/rules.d/80-net-name-slot.rules on your system. It currently
has comments explaining what is happening.

As long as this file is in place, this feature is not activated. That is
why there is not a news item. If you do nothing, nothing changes.

What I would like to do is find some people who are willing to migrate
and report any issues they find.

I would like this to be the default for everyone at some point, so I
want to document the migration process and find out if there are any
bugs in tools because they expect the eth* names.

Thoughts?

William

[1]
http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames
Since for servers predictable names are useful and for desktop (which 
usually have only one ethernet that never change)
Is it possible to set desktop profiles to still use ethX, and base 
profile to use new naming scheme?


For wireless situation may be different, many of them are external, 
could wireless be managed differently?

Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

[viv...@gmail.com]

Il 22/01/2013 04:38, Robin H. Johnson ha scritto:

I'm raising this patch because of the recent spate of bugs with the
latest udev  that now fails to boot your system if CONFIG_DEVTMPFS is
not available in your kernel.

Bugs: 408947, 409393, 437320, 453074

CONFIG_CHECK has not been fatal for some years now, because there turned
out to be some cases where it cannot detect what the system really has
[1], or what is returned is wrong [2].

However, while this is has been superb in helping those corner-cases,
the fallout is that users frequently ignore the non-fatal warnings that
a configuration option is needed to run a binary later, and end up with
weird breakage.

This patch introduces a new option, CONFIG_CHECK_FATAL, defaulting to
enabled, that explicitly causes a die if:
- CONFIG_CHECK cannot be performed successfully.
- Any CONFIG_CHECK options fail.

For the aforementioned corner cases, those environments are used to
customizing their make.conf heavily, and they should add:
CONFIG_CHECK_FATAL=0

This patch does NOT change the handling of ~/tilde in CONFIG_CHECK
- options that are required at compile-time MUST NOT use ~/tilde.
- options that are only required at run-time MUST include the ~/tilde.

Footnotes:
1. If you are using a VM environment, where the kernel is provided
outside of your VM, and you don't have kernel sources, or
/proc/config.gz, you CANNOT detect what options the kernel is
configured with.
2. Building stages for example. You may have /proc bind-mounted from the
host system, but it does not reflect the environment you are building
for.

IMHO the number of cases where CONFIG_CHECK is reliable is so small that 
making it fatal will only bloat make.conf and env with a new var for 
most users.


However this move could make sense if (and only if) CONFIG_CHECK could 
reliabily know where it's used.

It could be made fatal for example if all the following conditions are met:
- buildpkg is disabled
- /proc/config.gz (decompressed) is the same as 
${KERNEL_BUILD_DIR}/.config  and both exists

- /boot is mounted and the bootloader will load the currently running kernel

AIMHO it's very difficult (would say impossible) to implement this in a 
cross package manager and reliable way.


So please don't

Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

[viv...@gmail.com]

Il 24/01/2013 20:21, Michael Orlitzky ha scritto:

On 01/24/13 13:58, Ian Stakenvicius wrote:


How about, you know what you're doing and are going to build a new
kernel as soon as the emerge finishes (since the emerge is also
bringing in a new gentoo-sources)??


If you're going to upgrade both anyway, you should be upgrading the
kernel first. That way if you lose power or the system crashes, the box
can reboot.

which can be the exact opposite order if instead you have to _disable_ a 
feature in the kernel which would make udev not bootable.
Don't remember exactly what, but it happened in the past when Greg was 
still maintainer and an obsolete feature was making udev confused.

Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

[viv...@gmail.com]

Il 24/01/2013 21:45, Michael Orlitzky ha scritto:

On 01/24/13 15:39, Michael Orlitzky wrote:

On 01/24/13 15:26, viv...@gmail.com wrote:

If you're going to upgrade both anyway, you should be upgrading the
kernel first. That way if you lose power or the system crashes, the box
can reboot.


which can be the exact opposite order if instead you have to _disable_ a
feature in the kernel which would make udev not bootable.
Don't remember exactly what, but it happened in the past when Greg was
still maintainer and an obsolete feature was making udev confused.


Suppose, you're on e.g. udev-1, and,

   * udev-2 requires CONFIG_FOO=n
   * udev-1 will not boot with CONFIG_FOO=y

Sorry, that should be an 'n' instead of a 'y'. I started out with 'y'
and tried to switch to 'n' to match your example.


actually it wasn't an issue that could made a system un-bootable but was 
like this:


* udev-129 could live with CONFIG_SYSFS_DEPRECATED=y
* udev-130 require CONFIG_SYSFS_DEPRECATED not set

The example was given just to underline the fact that a different emerge 
order may be required.


cheers

[gentoo-dev] FYI: libpng16 break showfoto (digikam) png save

[viv...@gmail.com]

Hi Samuli,
  while you're at it do you know what changed between 1.5 and 1.6 in
ICC/color profiles land?

In short digikam is now unable to save png files, I've yet do debug it
so if there is some pointers that could shorten the discovery.
The culprit seem to be "libpng error: profile 'icc': 1B0Ah: invalid
length", and digikam/kipi plugins has been compiled yesterday from git.

thanks


showfoto(7331)/digikam (core) Digikam::EditorWindow::showFileSaveDialog:
Writing file to 
KUrl("file:///home/vivo/docs/NIKON/2013/20130420-test/work/DSC_9665.png")

showfoto(7331)/digikam (core)
Digikam::EditorWindow::selectValidSavingFormat: Trying to find a saving
format with filter =  "*" , targetUrl = 
KUrl("file:///home/vivo/docs/NIKON/2013/20130420-test/work/DSC_9665.png") ,
autoFilter "*|All Files"
showfoto(7331)/digikam (core)
Digikam::EditorWindow::selectValidSavingFormat: KDE Offered types: 
("xpm", "pgm", "pbm", "rgb", "rgba", "bw", "sgi", "tga", "xv", "ppm",
"bmp", "pic", "eps", "epsi", "epsf", "jp2", "mng", "tiff", "tif", "png",
"jpeg", "jpg", "pcx", "xbm")
showfoto(7331)/digikam (core)
Digikam::EditorWindow::selectValidSavingFormat: Writable formats: 
("xpm", "pgm", "pbm", "rgb", "rgba", "bw", "sgi", "tga", "xv", "ppm",
"bmp", "pic", "eps", "epsi", "epsf", "jp2", "mng", "tiff", "tif", "png",
"jpeg", "jpg", "pcx", "xbm", "TIF", "TIFF", "JPG", "JPEG", "JPE", "J2K",
"JP2", "PGF")
showfoto(7331)/digikam (core)
Digikam::EditorWindow::selectValidSavingFormat: Possible format from
local file:  "png"
showfoto(7331)/digikam (core)
Digikam::EditorWindow::selectValidSavingFormat: Using format from target
url  "png"

showfoto(7331)/digikam (core) Digikam::EditorCore::Private::saveAs:
Saving to :
"/home/vivo/docs/NIKON/2013/20130420-test/work/EditorWindow-Ly7331.digikamtempfile.png"
( "png" )
showfoto(7331)/digikam (core) Digikam::EditorCore::Private::saveNext:
Saving file
"/home/vivo/docs/NIKON/2013/20130420-test/work/EditorWindow-Ly7331.digikamtempfile.png"
at -1

showfoto(7331)/digikam (core) Digikam::PNGLoader::save: DImg quality
level:  1
showfoto(7331)/digikam (core) Digikam::PNGLoader::save: PNG compression
level:  9
libpng error: profile 'icc': 1B0Ah: invalid length

showfoto(7331)/digikam (core) Digikam::PNGLoader::save: Internal libPNG
error during writing file. Process aborted!
showfoto(7331)/digikam (core) Digikam::EditorCore::slotImageSaved: error
saving image '
/home/vivo/docs/NIKON/2013/20130420-test/work/EditorWindow-Ly7331.digikamtempfile.png
showfoto(7331)/digikam (core) Digikam::EditorWindow::slotSavingFinished:
"/home/vivo/docs/NIKON/2013/20130420-test/work/EditorWindow-Ly7331.digikamtempfile.png"
false true

Re: [gentoo-dev] FYI: libpng16 won't be able to show some broken icons libpng15 was still able to

[viv...@gmail.com]

On 04/22/13 13:03, Tobias Klausmann wrote:
> Hi! 
>
> Since we probably will have to fix the files coming out of
> tarballs until the various upstreams have fixed them, I propose
> running a PNG fixer during or after the install phase. Since
> having pngcrush as dep for everything is not exactly lightweight,
> I hacked together a PNG file fixer in pure(ish, see below)
> Python:
No please, this real should stay really far from any package manager.
There are only two sane options:
1) fix libpng to be backward compatible
2) fix the package, and re-package / add a package for broken images

But please don't push on all our user systems something like this.

>
> http://git.schwarzvogel.de/?p=pngfixer;a=summary
>
> Feel free to send patches
>
> Note that all I wrote is the mind-numbingly simple pngfixer.py
> script. The rest of the Python code is excised from PIL
> (http://www.pythonware.com/products/pil/index.htm). I didn't have
> to change anything there.
>
> Also note that it is not _strictly_ pure Python I'm using: the
> PIL components use Python's zlib.so and therefore are subject to
> bugs in _that_ code.

Thanks for taking the time to write this it could be useful for
developers, but hopefully not as initially intended ;-)

>
> Still needed:
>
> - How do we ship this?
> - How do we run it for every ebuild? (probably something like
>   find /var/tmp/portage/.../image/ -iname \*.png -exec {...}\;)
>
> Regards,
> Tobias
Regards,
Francesco

Re: [gentoo-dev] rfc: oldnet scripts splitting out from OpenRC

[viv...@gmail.com]

On 04/24/13 21:17, William Hubbs wrote:
> On Wed, Apr 24, 2013 at 09:00:17PM +0200, Michał Górny wrote:
>> On Wed, 24 Apr 2013 11:16:06 -0500
>> William Hubbs  wrote:
>>
>>> This means when you emerge or upgrade to openrc-0.12, the net.* scripts
>>> will no longer be included. I am going to call the separate package that
>>> includes these scripts gentoo-oldnet.
>> Aside all the other, please don't name it like this :). It's just feels
>> wrong to start new and supposedly beneficial project and name it 'old'
>> like something you just thrown away off the main tree.
> The name is also per robbat2's request. I asked him about other names,
> but he specifically wanted oldnet in the name.
>
> A little bit of historical background may be in order here.
>
> In a nutshell, it is called old because Roy wanted to deprecate the
> whole thing eventually and switch us over to the newnet scripts that
> OpenRC has.
> name.
>
> We thought about killing off newnet entirely for a while in OpenRC, but
> I have since found that people do use it. It is more similar to what
> happens on the *bsd side, and it works well for simple setups.
s/it works well for simple setups/it work wonderfully for very complex
setups/

It can mimic very closely the 'ip' command, making it easy to test on
commandline and just copy and paste in conf.d/net.
At the same time it benefit from a lot of howtos and tutorials written
for sys-apps/iproute2

"old"net is the best network manager out there including all major distro.

>
> Also, I think it is more like what some other distros do for their
> network interfaces.
>
> The primary disadvantages of newnet are that services can't depend on a
> single network interface, and it is not possible to stop/start a single
> interface.
>
> William
>

Re: [gentoo-dev] [RFC] Shall econf append its arguments to end of ./configure invocation?

[viv...@gmail.com]

On 04/30/13 01:12, Rich Freeman wrote:
> On Mon, Apr 29, 2013 at 6:27 PM, Ciaran McCreesh
>  wrote:
>> What ultimately got approved by the Council, and what implementers
>> should be following, is the wording which ended up in PMS.
>>
> I can't speak for everywhere, but even in the highly regulated
> environment I work in, an error in a specification is a good reason to
> fix the specification, not to change the implementation.
Just out of curiosity what happen in a highly regulated environment if
an individual systematically try to find loopholes and use them against
the environment? In production?
Or to say it another way to boycott things staying in the rules, lawyers
enjoy this, but programmers?

>
> Whether this is retroactive or forward-going should be based on the
> practical impact of each, not on whether the council approved
> something without appreciating every possible ramification of the
> wording as-written.  Specs are a communication tool - not writ from
> heaven.
>
> Arguing over whether we should go ahead and break a whole bunch of
> packages in the interim just to comply with the spec until it is fixed
> is basically reducing human intelligence to algorithmic behavior.
> There is a reason that we program the machines, and not the other way
> around (yet).
>
> If it really is better for our users to follow the spec as-is for now,
> I'm sure everybody is all ears, but I haven't seen any examples
> offered.  The council is of course welcome to chime in if they'd
> rather the portage maintainers do so.
>
> This whole thing seems best chalked up to well-intending people making
> omissions (maybe), and the virtue of competent developers who don't
> just blindly follow the spec when it doesn't make sense.
>
> Sure, fix the spec, but it makes more sense to make this retroactive
> unless somebody can really point to something that this breaks.  If
> the damage from doing so exceeded the damage from not doing so you
> probably wouldn't even need the council to get everybody to go along
> with you.
>
> Rich
>

Re: [gentoo-dev] Re: [RFC] Shall econf append its arguments to end of ./configure invocation?

[viv...@gmail.com]

On 04/30/13 13:12, Ciaran McCreesh wrote:
> On Tue, 30 Apr 2013 05:30:03 + (UTC)
> Duncan <1i5t5.dun...@cox.net> wrote:
>> There's value in someone being just contrarian enough to purposefully 
>> look for the strangest or most illogical read of a spec and
>> (initially) implement it that way, in ordered to root out and get the
>> bugs in the spec fixed.  That said...
> I highly doubt the person implementing the code for Paludis was doing
> it in a contrarian way. As far as I can see, he simply implemented what
> the spec says.
>
Nice to know. For how the discussion has gone before the opposite seemed
true.
Now, is it possible to alter the behaviour of paludis to act, still
following the specs, in a way compatible with portage and which seem
more logical to the majority of people writing this thread?
Or at least discuss the possibility for paludis to change behaviour?
It seem there would be some gain and nearly no loss, and make everyone
happy (or at least try to)

Best regards,
Francesco

Re: [gentoo-dev] USE_EXPAND is not an IUSE replacement [was: New USE_EXPAND: CLAWS_MAIL_PLUGINS]

[viv...@gmail.com]

Il 04/05/2013 08:11, Dustin C. Hatch ha scritto:
> On 5/3/2013 16:08, René Neumann wrote:
>> Am 03.05.2013 22:20, schrieb Zac Medico:
>>> Is it worth changing?
>>
>> Nope. What's worth changing is the excessive use of USE_EXPAND for no
>> reason (your described usecase makes sense for reasonable USE_EXPAND
>> stuff like VIDEO_CARDS). But seems like I'm the only one concerned by
>> this, so I should probably rest my case and switch to silent sobbing
>> instead ;-).
>>
>> - René
>>
> I definitely agree with you. USE_EXPAND combined with nearly
> everything on-by-default (ENLIGHTENMENT_PLUGINS, for example) really
> annoys me. There are two ways to "turn off" USE_EXPADed flags:
> explicitly set everything but what you don't want in make.conf, or use
> the fully-qualified flag in make.conf:USE or package.use, which
> defeats the purpose entirely. Both of these are overly verbose, in my
> opinion. I don't know how the over-utilization of USE_EXPAND got
> started, but I would very much like to see it go away.
>
Actually this would not be that bad if USE_EXPAND where immutable (fix
it once and be ok) but they are not and as such suffer the same problem
as USE="-*"

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/id3lib: metadata.xml ChangeLog id3lib-3.8.3-r9.ebuild

[viv...@gmail.com]

Il 04/05/2013 19:42, Jeroen Roovers ha scritto:
> On Fri, 03 May 2013 20:18:42 +0200
> Justin  wrote:
>
 +  03 May 2013; Justin Lecher 
 +id3lib-3.8.3-r9.ebuild,
 +  metadata.xml:
 +  Fix obsolete macros to work with automake-1.13, #467704; bumped
 to EAPI=5 and
 +  autotools-utils.eclass
>>> There was no reason to use autotools-utils.eclass in the ebuild.
>> Any reason to not using it?
> I think he answered that already in his reply to self. It adds useless
> cruft and then doesn't use it. 
could not comment to this
> (Also, why do a revision bump and leave
> the stable revision unfixed?)
>
but this:
because automake-1.13 is _not_ stable an because there are enough
changes to risk to break it?
revision bump has been a good idea

Re: [gentoo-dev] Re: CPU use flag detection

[viv...@gmail.com]

On 05/19/13 17:47, Alexis Ballier wrote:
> On Sat, 18 May 2013 22:31:11 -0400
> "Walter Dnes"  wrote:
>
> [...]
>> ...shouldn't "mmxext" be moved out of use.local.desc into use.desc?
>
> all the cpu flags should be global IMHO, regardless of how many packages
> use them: we already mask/unmask them globally on arches where they are
> irrelevant.
>
> Alexis.
>
+1
also +1 they should be easily recognizable as cpu features USE flags, as
already mentioned recently by someone (sorry could not search)

Re: [gentoo-dev] robo-stable bugs

[viv...@gmail.com]

On 05/21/13 23:38, Andreas K. Huettel wrote:
> Am Dienstag, 21. Mai 2013, 15:38:44 schrieb Thomas Sachau:
>> And if a maintainer is not responding within 30 days, you can ping him
>> or, without a response, try to get a different maintainer. Just assuming
>> that a stable request is ok without a maintainer response is really not
>> a good idea.
> If none of the listed maintainers responds to a bug in 30 days in any way, 
> the 
> package is effectively unmaintained.
>
And thus its risky to mark it stable.

Re: [gentoo-dev] Re: robo-stable bugs

[viv...@gmail.com]

On 05/22/13 11:43, Michael Palimaka wrote:
> On 22/05/2013 19:22, viv...@gmail.com wrote:
>> On 05/21/13 23:38, Andreas K. Huettel wrote:
>>> Am Dienstag, 21. Mai 2013, 15:38:44 schrieb Thomas Sachau:
>>>> And if a maintainer is not responding within 30 days, you can ping him
>>>> or, without a response, try to get a different maintainer. Just
>>>> assuming
>>>> that a stable request is ok without a maintainer response is really
>>>> not
>>>> a good idea.
>>> If none of the listed maintainers responds to a bug in 30 days in
>>> any way, the
>>> package is effectively unmaintained.
>>>
>> And thus its risky to mark it stable.
>>
>>
> That's why we have arch teams in the first place, to test beforehand.
>
>
The risky part is about the after, not the before, to avoid the risks
arch teams should keep the package working *after* it has stabilized.
Seem to be a good case for those things that need to be evaluated case
by case and could not be written in stone.

Re: [gentoo-dev] Re: robo-stable bugs

[viv...@gmail.com]

On 05/22/13 13:06, Michael Palimaka wrote:
> On 22/05/2013 20:41, Thomas Sachau wrote:
>> Michael Palimaka schrieb:
>>> On 22/05/2013 20:07, viv...@gmail.com wrote:
>>>> On 05/22/13 11:43, Michael Palimaka wrote:
>>>>> On 22/05/2013 19:22, viv...@gmail.com wrote:
>>>>>> On 05/21/13 23:38, Andreas K. Huettel wrote:
>>>>>>> Am Dienstag, 21. Mai 2013, 15:38:44 schrieb Thomas Sachau:
>>>>>>>> And if a maintainer is not responding within 30 days, you can ping
>>>>>>>> him
>>>>>>>> or, without a response, try to get a different maintainer. Just
>>>>>>>> assuming
>>>>>>>> that a stable request is ok without a maintainer response is
>>>>>>>> really
>>>>>>>> not
>>>>>>>> a good idea.
>>>>>>> If none of the listed maintainers responds to a bug in 30 days in
>>>>>>> any way, the
>>>>>>> package is effectively unmaintained.
>>>>>>>
>>>>>> And thus its risky to mark it stable.
>>>>>>
>>>>>>
>>>>> That's why we have arch teams in the first place, to test beforehand.
>>>>>
>>>>>
>>>> The risky part is about the after, not the before, to avoid the risks
>>>> arch teams should keep the package working *after* it has stabilized.
>>>> Seem to be a good case for those things that need to be evaluated case
>>>> by case and could not be written in stone.
>>>>
>>>>
>>> I am confused as to what you are proposing. Do you want arch teams to
>>> continually test packages that are already in stable to make sure they
>>> haven't broken somehow?
>>>
>>>
>>>
>> The point is probably, that when you stable a package with inactive
>> maintainer, there will be noone following the opened bugs against this
>> new version.
>>
>> So this looks like a case, where one should ask for a new maintainer,
>> who then decides about the stable versions instead of doing
>> auto-stabilization.
>>
> If the maintainer is inactive, presumably nobody is looking at bugs
> for the old version either.
>
>
And the circle is closed since we started with the correlation "no
answer to stable bug in 30 days" => "package unmantained" ;-)

Re: [gentoo-dev] Draft news item: MySQL/MariaDB packages dropping support for PrimeBase (PBXT) engine

[viv...@gmail.com]

On 06/01/13 02:37, Robin H. Johnson wrote:
> Hi all,
>
> See attached the draft news item for MySQL/MariaDB dropping PBXT
> support.
from the draft:
"All users who have data stored in PBXT-backed tables should convert the
tables to another format before upgrading to MySQL/MariaDB 5.5, as the
tables will otherwise become inaccessible. "

s/before/BEFORE/

it should be very visible.

Also, is it possible to halt the merge into filesystem if some PBXT
tables exists in ${MY_DATADIR}?
Not that I like it but maybe users prefer this to be forced to downgrade
after.

>
> I would like to drop the blocks into the tree not later than June 3rd.
> I think it should affect very few users, as PBXT was a niche feature.
>
> This should clear us to get MySQL/MariaDB 5.5 into stable.
>
nice!

[gentoo-dev] RFC how to handle disappearing USE in (portage) dependency calculation

[viv...@gmail.com]

Hi everybody,
  sometimes a package depend from another with a particular USE flag
turned on, example llvm-3.2 on dev-libs/udis86 +pic
Sometimes a new ebuild can change IUSE, indeed udis86-1.7-r1 removed pic
use which was present in 1.7-r0.

This RFC is to understend what we (you actually) want the packages
manager to do in this situation, as I see it there are mainly two options.

1) when consider the dependency _always_ satisfied, if the requested USE
is not in IUSE.
  this will make user life easier, since portage now barf conflicts but
the "wrong" dependency goes unnoticed and nobody will clean the ebuilds.

2) error out always, both if requested USE flag should have been enabled
or not, since it's a bug and should be fixed.
  emerge -uDavNt will not that easy but the tree is cleaner as a
consequence, also the developer are forced^Wencouraged  to look at the
reason the USE flag disappeared analizing if their package will continue
to work.

finally the depend in llvm ebuild has this form:
DEPEND="udis86? ( dev-libs/udis86[pic(+)] )"
and the diff between udis86 ebuilds is like this:
-IUSE="pic test"
+IUSE="test"

best regards,
Francesco R.

Re: [gentoo-dev] RFC how to handle disappearing USE in (portage) dependency calculation

[viv...@gmail.com]

On 06/07/13 14:37, Sergey Popov wrote:
> 07.06.2013 15:26, viv...@gmail.com пишет:
>> Hi everybody,
>>   sometimes a package depend from another with a particular USE flag
>> turned on, example llvm-3.2 on dev-libs/udis86 +pic
>> Sometimes a new ebuild can change IUSE, indeed udis86-1.7-r1 removed pic
>> use which was present in 1.7-r0.
>>
>> This RFC is to understend what we (you actually) want the packages
>> manager to do in this situation, as I see it there are mainly two options.
>>
>> 1) when consider the dependency _always_ satisfied, if the requested USE
>> is not in IUSE.
>>   this will make user life easier, since portage now barf conflicts but
>> the "wrong" dependency goes unnoticed and nobody will clean the ebuilds.
>>
>> 2) error out always, both if requested USE flag should have been enabled
>> or not, since it's a bug and should be fixed.
>>   emerge -uDavNt will not that easy but the tree is cleaner as a
>> consequence, also the developer are forced^Wencouraged  to look at the
>> reason the USE flag disappeared analizing if their package will continue
>> to work.
>>
>> finally the depend in llvm ebuild has this form:
>> DEPEND="udis86? ( dev-libs/udis86[pic(+)] )"
>> and the diff between udis86 ebuilds is like this:
>> -IUSE="pic test"
>> +IUSE="test"
> What's the question here? How to handle this? Read about USEDEP_DEFAULTS
> in PMS.
yes "how to handle this", thanks for the pointer to USE-DEP-DEFAULTS,
Ciaranm you too
>
> If you see broken packages(somebody forgot to change dependency) - file
> a bug about it.
>
According to the now readed fine manual, the ebuilds seem to be right,
llvm is EAPI=5, udis86-1.7-r1 is EAPI=4 and the previous one is EAPI=3,
dependency should be considered enabled if absent.
So the bug would be in portage, but the overzealous dep resolution seem
to arise only with "--with-bdeps=y" so I'm not opening it a bug.

Re: [gentoo-dev] Calling die in a subshell

[viv...@gmail.com]

On 06/15/13 19:02, Mike Gilbert wrote:
> On Sat, Jun 15, 2013 at 1:01 PM, Ciaran McCreesh
>  wrote:
>> On Sat, 15 Jun 2013 12:56:00 -0400
>> Mike Gilbert  wrote:
>>> If we find that all known implementations of PMS/EAPI 4 have
>>> implemented a certain behavior, making a change to that version of PMS
>>> to properly document the behavior seems reasonable.
>> Part of the point of EAPI stability is that it doesn't just apply to
>> current versions of package manglers.
>>
> So look back at the first versions which implemented EAPI 4 support,
> and see what the behavior was implemented at the point in time.
>
it make sense but it stretch things a lot.

Is it possible to:
- keep an open bug (tracker) on named eclasses/ebuilds, so we (users and
devs) know that there is a (teoric) fallacy
- approve it for EAPI 6
- move all the eapi/ebuilds to EAPI 6
- close the bugs as WONT-FIX

In any case it should be easy to port an ebuild from EAPI4 to 6, if
gentoers want to keep things simple it could be more a version 5a than 6

regards

Re: [gentoo-dev] Packages up for grabs

[viv...@gmail.com]

On 06/16/13 11:49, Pacho Ramos wrote:
> Due ferringb retirement the following packages are up for grabs:
> app-arch/tarsync
* app-arch/tarsync
 Available versions:  (~)0.2.1 (~)0.2.1-r1
 Homepage:http://gentooexperimental.org/~ferringb/tarsync/
 Description: Delta compression suite for using/generating
binary patches

^^^ also this may need a new maintainer, it already need a new homepage
(404)

> dev-python/snakeoil
> dev-util/bsdiff
> dev-util/diffball
> sys-apps/pkgcore (likely to be treecleaned as it's no longer maintained
> and neither has eapi5 support)
>
>
>

Re: [gentoo-dev] Re: Calling die in a subshell

[viv...@gmail.com]

On 06/18/13 09:06, Duncan wrote:
>> > What on earth is a "teoric fallacy"?
> My question too.  Wictionary and google both appear to agree, however, 
> that while "teoric" isn't English, it's Catalan (or Aranese/Occitan, the 
> area is NE Spain into south France) for "theoretical", which it /is/ 
> close enough sounding/spelling to, to make sense as having the same 
> original root (which wikipedia traces to late Latin from ancient Greek).
>
> http://en.wiktionary.org/wiki/te%C3%B2ric
near enough, it was an (unwanted) chimera between Italian and English

Re: [gentoo-dev] s/disk space/drive space

[viv...@gmail.com]

On 07/30/13 15:03, Alexander Berntsen wrote:
> On 30/07/13 14:55, Douglas Freed wrote:
> >> How is it wrong?
> I don't have a disk so informing me that I don't have enough disk space
> does not make any sense..
>
> I think my suggestion and its justification has been made clear, so I
> will not proceed to feed the bikeshed monster.
>
>
> (Furthermore, because I am a non-developer, I should apparently be
> "more considerate" on this list, so I should probably not send as much
> email here until I become a developer; or figure out why people think
> I am brash and inconsiderate, and figure out a way to prevent coming
> across that way.)


does "storage space" make everyone happy?

Re: [gentoo-dev] renaming gentoo-oldnet

[viv...@gmail.com]

[snip]
> :p I'm actually thinking netrc if Robin is ok with it. William 

replaying to a random message in the tree
Not going to suggest a name but if has to be something for general
consumption, it should avoid the "gentoo" inside the name
just my 0.2¢

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[viv...@gmail.com]

On 08/09/13 13:38, Pacho Ramos wrote:
> El vie, 09-08-2013 a las 19:39 +0800, Patrick Lauer escribió:
>> On 08/09/2013 07:26 PM, Tom Wijsman wrote:
>>> On Fri, 09 Aug 2013 19:31:22 +0800
>>> Patrick Lauer  wrote:
>>>
 You just removed the upgrade path for users.
>>> The upgrade path is to install systemd or to implement openrc support.
>>>
>> Invalid upgrade path.
>>
>> "The upgrade path is to install Fedora" is about as reasonable, and also
>> not acceptable.
>>
>>
> The upgrade path is to run systemd, not migrate to fedora. As simply as
> such
>
>
is systemd useful if not run with PID=1 ? Honest question

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[viv...@gmail.com]

On 08/09/13 15:54, Michał Górny wrote:
> Dnia 2013-08-09, o godz. 14:14:12
> "viv...@gmail.com"  napisał(a):
>> On 08/09/13 13:38, Pacho Ramos wrote:
>>> El vie, 09-08-2013 a las 19:39 +0800, Patrick Lauer escribió:
>>>> On 08/09/2013 07:26 PM, Tom Wijsman wrote:
>>>>> On Fri, 09 Aug 2013 19:31:22 +0800
>>>>> Patrick Lauer  wrote:
>>>>>
>>>>>> You just removed the upgrade path for users.
>>>>> The upgrade path is to install systemd or to implement openrc support.
>>>>>
>>>> Invalid upgrade path.
>>>>
>>>> "The upgrade path is to install Fedora" is about as reasonable, and
also
>>>> not acceptable.
>>>>
>>> The upgrade path is to run systemd, not migrate to fedora. As simply as
>>> such
>>>
>> is systemd useful if not run with PID=1 ? Honest question
> Not a honest question but either honest troll, or you're awfully lazy
> and just making noise here.

No really, I've tried systemd but only as init, and,
since I'm not a gnome user I'm rather ignorant on it's internals.
Yet gnome it's an important piece of the opensource ecosystem, and
decision taken for gnome sometimes have repercusions also on different
DE like kde which is my main interest.

> So the answer is: yes, it's quite useful when run with PID!=1. It's
> called systemd user instance (something OpenRC totally can't handle)
> and it can be used to manage user services.
>
> But I have no idea how is that relevant since you obviously know that
> the problem here requires running systemd as PID 1.

I could have argued it was relevant, but again no, I didn't know for sure.
My experience with systemd has only been as only init system (PID=1)
even when using the (now dead?) overlay from Fabio which tried to make
openrc and systemd coexist.

Thanks to everyone responded

Re: [gentoo-dev] How to support C++11 in libraries?

[viv...@gmail.com]

On 12/19/13 16:17, Jan Kundrát wrote:
> On Thursday, 19 December 2013 10:18:55 CEST, Michał Górny wrote:
>> Would it be possible to have a consistent ABI for both C++03 and C++11?
>> The simpler changes like adding new fields can be backported quite
>> easily (even if it would mean having dummy fields in C++03), I have no
>> idea about the more complex changes.
>
> I don't know, but from a bystander's point of view, I surely hope that
> it will be possible. Otherwise there would be no option but providing
> a multilib-like setup for C++11, after all.
>
> Some messages on gcc's ML indicate that there are software vendors who
> are *very* afraid of doing the SONAME change again. Given that C++11
> forbids a refcounted std::string while libstdc++ currently use just
> that for its implementation, I suspect that the upstream developers
> have a very interesting problem to solve. (And there's much more.)
>
> It is pretty clear to me that even the gcc people have not reach a
> consensus on how the ABI of the standard library will look like in
> 4.9, so maybe it is premature for us to talk about how to solve this.
> The ball is on their side.
>
>> Well, if they considered the C++11 ABI in gcc-4.9 stable, we could
>> consider changing the default to C++11. Then, we could do our
>> bump/switch thing as a matter of gcc-4.9 upgrade problem.
>
> To put things into perspective, *if* the ABI changes and if the new
> version is compatible between C++98 and C++11, then we're talking
> something very similar to an upgrade from GCC 3.3.
>
> Cheers,
> Jan
>
just a question, what would do -fabi-version=6 added to CXXFLAGS even
w/o C++11?

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-sound/umurmur: metadata.xml ChangeLog

[viv...@gmail.com]

On 12/26/13 14:27, Ciaran McCreesh wrote:
> On Thu, 26 Dec 2013 14:25:04 +0100
> hasufell  wrote:
>> That is funny that you mention "cleaning up". I remember last time
>> when you broke 8 ebuilds at once because you just trusted your
>> outdated repoman warning to be correct. You didn't even file a BUG
>> for me, you did not contact me and after I told you that it was wrong
>> and that you should revert it, you didn't.
>>
>> That's what I call "ignoring the rest". You do not communicate, you do
>> not file bugs, you just go and do stuff.
> That kind of behaviour is what the QA team is supposed to be able to
> address. You should raise this issue with them rather than accusing
> each other on the lists.
>
Ciaranm doing peacekeeping ?!?

The world is really ending in 2013, and he is right too

Re: [gentoo-dev] RFC: Hosting daily gx86 squashfs images and deltas

[viv...@gmail.com]

On 01/17/14 17:27, Michał Górny wrote:
> Hello, all.
>
> I'm using squashfs to hold my Gentoo repositories on all of my systems
> for some time. As you probably know, this allows me to save space while
> keeping portage fast. However, it makes updating the tree quite
> burdensome and time-consuming.
Me too and you have my total support (maybe I've even proposed this
before to te list)

[snip]

>
> As you can see, the deltas are quite large compared to the actual
> changes. However, we could have expected that since we're diffing
> a compressed filesystem. What's important, however, is that applying
> it takes ~2.5 second on my 2 GHz Athlon64.

Have you tried to give an order (always the same) to the compressed files?
It could give an advantage, tough it may be limited to 2^16 files the
option is -sort 


thanks for it,
Francesco

Re: [gentoo-dev] RFC: Hosting daily gx86 squashfs images and deltas

[viv...@gmail.com]

On 01/27/14 08:35, Steev Klimaszewski wrote:
> On Sun, 2014-01-26 at 21:00 +0100, Michał Górny wrote:
>> Hi again.
>>
>> If someone is interested in the results of my tests and benchmarks,
>> I've uploaded the initial version of my article on the topic in our
>> dev-space.
>>
>> http://dev.gentoo.org/~mgorny/tmp/squashfs-deltas.pdf
>>
>> I am terribly busy with the uni right now so it will take some time
>> before I continue working on it. I will try to provide a final
>> specification for the first attempt at the idea and ask infra if they
>> are ready to sacrifice the hardware for it.
>>
>> Further possible improvements:
>>
>> 1. switch to LZ4 (stronger compression, even faster) -- will require
>> a newer kernel (3.14?),
>>
it should be in kernel 3.11 "windows for workgroups" release (check anyway)

> While the stronger compression, and being faster is definitely nice,
> having portage on squashfs is really nice on ARM devices, however the
> number of them that have a decently running kernel newer than 3.8 are
> few and far between, so I'd like to ask that this be held off as long as
> possible.  I know these are just possible improvements, but doing so
> would definitely alienate a really good place where this would shine.

yes, there are good reasons also for amd64

>
>> 2. dedicated SquashFS delta tool -- I'm working on it but
>> the format seems to be poorly documented so it will take some time :).
>>
>
>

Re: [gentoo-dev] RFC: using .xz for doc/man/info compression

[viv...@gmail.com]

On 05/13/14 13:01, Andrew Savchenko wrote:
> f we are trying to consider a majority of users (and thus to
> select reasonable defaults), from disk usage + decompression
> overhead point of view it will be the best to store compressed files
> if they are at least one filesystem block smaller than original
> file. FS block size may be extracted runtime for any man or doc, or
> alike directory used, so this is doable. But this approach may
> overcomplicate implementation.
The filesystem on which the files will end is totally unknown to
portage, since it could be a different machine using binpkg

Re: [gentoo-dev] My masterplan for git migration (+ looking for infra to test it)

[viv...@gmail.com]

Il 14/09/2014 14:03, Michał Górny ha scritto:
> The rsync tree
> --
>
> We'd also propagate things to rsync. We'd have to populate it with old
> ChangeLogs, new ChangeLog entries (autogenerated from git) and thick
> Manifests. So users won't notice much of a change.
>
If this will change all Changelog the first rsync from the users will
generate a lot of traffic, rsync network need to be prepared

Re: [gentoo-dev] Re: My masterplan for git migration (+ looking for infra to test it)

[viv...@gmail.com]

Il 16/09/2014 20:02, Duncan ha scritto:
> Rich Freeman posted on Tue, 16 Sep 2014 09:55:31 -0400 as excerpted:
>
>> Or they could just clone the git tree, and they can look at per-file
>> logs anytime they want to.
> Give me ro access to a current git repo and I'll *VERY* happily leave 
> changelogs to history along with 8-track tapes and 5.25-inch floppies! 
> =:^)
>
> I was strongly in favor of keeping changelogs (and mandating proper add/
> change/deletion entries) the last time the topic came up, but that was in 
> the context of (web)?rsync being the only viable user sync method and 
> thus changelogs being the only user-local-accessible record.  With user-
> git-repo access, I'll /very/ (very, very, very...) happily leave rsync 
> behind for git, and changelogs along with it! =:^)
>
yes, this probably is the same for everyone, and if it's not it should
be anyway.

Re: [gentoo-dev] Add bc back to the stage3

[viv...@gmail.com]

Il 17/09/2014 14:09, Jorge Manuel B. S. Vicetto ha scritto:
> On Wed, 17 Sep 2014, Luca Barbato wrote:
>
>> The bc utility is part of the posix tools and it might be used to build
>> linux among the other stuff.
>
> Luca,
>
> bc is not in the system set and is a dependency of the kernel or any
> other package that needs it, so why do we need to include a package
> that takes ~20 seconds to build?

Most people don't use the ebuild for the kernel

Re: [gentoo-dev] more help needed with gcc-4.8 stabilization, chromium starts heavily using C++11

[viv...@gmail.com]

Hi,
  have you considered to stabilize gcc:4.9 instead possibly 4.9.2 ?
I'm not really suggesting to do so, but seem that most of the problems
of 4.9.1 are the same of 4.8.3 so maybe it's worth considering.


Il 11/10/2014 13:57, "Paweł Hajdan, Jr." ha scritto:
> In my earlier thread
>  I explored the
> possibility to stabilize gcc-4.8, and we have that going now in
> .
>
> Meanwhile I just applied a small patch for chromium-38 that allows it to
> compile with gcc-4.7. It's in stable now.
>
> We'll really need gcc-4.8 in stable within 6-12 weeks from now. Chromium
> starts making heavy use of C++11 language features, see
>  . I don't realistically see us being
> able to just patch chromium to work around that.

for 4.9.2 the 6-12 week window could be a problem


> I'd like to ask for every possible help with
>  blockers on amd64 and
> x86. There are harder problems on arches like MIPS, but newer gcc is not
> as urgent there I think.
>
> One highlight is . It
> occurs only when the user has gcc-4.7 and 4.8 installed simultaneously
> and using 4.7 as the active compiler. It's not obvious to me whether we
> have to support this (while it's obviously better to support rather than
> not, it's webkit-gtk in a specific and rare configuration versus
> chromium with security updates in all configurations).
>
> There is also  which may
> be more tricky. I could reproduce that bug. It's also about webkit-gtk.
>
> There are couple more blockers of
> . If you can, please
> take a look and help. I think several other distros are using gcc-4.8 or
> later now, they may have hit the same problems and either have patches
> or something that could also help us. There may be some upstream patches
> to be backported etc.
>
> Paweł
>

Re: [gentoo-dev] Portage dependency solving algorithm

[viv...@gmail.com]

Il 07/11/2014 20:08, hasufell ha scritto:
> Also, I don't understand these discussions. The time dependency
> resolving takes is marginal compared to the whole update process, no
> matter what PM you use.
"The time dependency resolving takes is marginal compared to the whole
update process "
^^^ this is an utter lie for frequent updates

Re: [gentoo-dev] Portage dependency solving algorithm

[viv...@gmail.com]

Il 08/11/2014 14:35, Ciaran McCreesh ha scritto:
> On Sat, 08 Nov 2014 09:29:52 +0100
> "viv...@gmail.com"  wrote:
>> "The time dependency resolving takes is marginal compared to the whole
>> update process "
>> ^^^ this is an utter lie for frequent updates
> Uh, how long are your resolves taking?
>
I've updated the system half hour ago it's empty, but this system can
compile and install a good number of packages in 3 minutes.
Obviously this is without tuning the filesystem, with rotational disks
_and_ 3 overlays (which slow down a lot) plus it has more than 2000
packages installed
So I would not call this marginal at all. Not even if it was one minute,
for attended upgrades is annoying.

gentoo ~ # /usr/bin/time --verbose emerge -uDpN @world

These are the packages that would be merged, in order:

Calculating dependencies... done!
Command being timed: "emerge -uDpN @world"
User time (seconds): 178.45
System time (seconds): 1.58
Percent of CPU this job got: 100%
Elapsed (wall clock) time (h:mm:ss or m:ss): 2:59.88
Average shared text size (kbytes): 0
Average unshared data size (kbytes): 0
Average stack size (kbytes): 0
Average total size (kbytes): 0
Maximum resident set size (kbytes): 2470064
Average resident set size (kbytes): 0
Major (requiring I/O) page faults: 0
Minor (reclaiming a frame) page faults: 168879
Voluntary context switches: 11
Involuntary context switches: 1568
Swaps: 0
File system inputs: 0
File system outputs: 0
Socket messages sent: 0
Socket messages received: 0
Signals delivered: 0
Page size (bytes): 4096
Exit status: 0

Re: [gentoo-dev] [gentoo-project] Re: towards a more distributed model

[viv...@gmail.com]

Il 18/11/2014 14:12, Jauhien Piatlicki ha scritto:
> On 11/18/2014 04:19 AM, hero...@gentoo.org wrote:
>> Jauhien Piatlicki  writes:
>>
>>> It would be probably good to have in the tree only the core components and 
>>> move other stuff to the thematic overlays.
>>>
>>> Then we can have a clear understanding, how things should be: if
>>> something is a part of the core system, it goes to the tree, if
>>> something is a scientific packages, it lives in the science overlay,
>>> if something is a java stuff it lives in the java overlay, etc.
>> This is a good idea.  One difficulty: how to handle inter-overlay
>> dependence?  Either the dependency should be expressed by overlay +
>> ebuild, or the dependent ebuild should be moved into the "core overlay".
>> I haven't figured out a clean solution yet.
>>
> Yes, this is a weak point of decentralization. We should think how to
> solve it. The possible solution is using of dependencies between
> overlays (one overlay says, it depends on other). We already have such a
> feature, we only need to add more support for it. Example of such a
> dependency:
>
> %cat /var/lib/layman/melpa-stable/metadata/layout.conf
>
> repo-name = melpa-stable
>
> masters = gnu-elpa gentoo
>
> Dependencies on overlays in ebuilds is bad idea I think, as it only will
> introduce additional problems. Also think what if you need not a
> package, but an eclass or whatever else.
>
> In addition, one question that emerges is possible circular dependencies
> between overlays. We need a way to handle this.
As much as I dislike the idea to move development to overlays
circular dependancies is not a problem because it's a simple _mutual_ dep.
there is not really a concept of before and after at most priority for a
package.

Re: [gentoo-dev] [gentoo-project] Re: towards a more distributed model

[viv...@gmail.com]

Il 20/11/2014 00:58, Rich Freeman ha scritto:
> On Wed, Nov 19, 2014 at 12:54 PM, hasufell  wrote:
>> On 11/19/2014 06:27 PM, Jauhien Piatlicki wrote:
>>> On 11/19/2014 03:36 PM, hasufell wrote:
 In the end, I'm not sure if this is actually such a big problem. You can
 still use random ebuilds from random overlays and commit them straight
 to your own overlay.

>>> A bad idea. Bad because of the same reason why copy-past in your code
>>> would be bad.
>>>
>> Depends. If a third-party overlay dependency regularly breaks my
>> packages, I am going to copy paste it into my own to have more control
>> over it.
>>
>> At that point it is forked. I don't see what's wrong with forking.
>>
> What happens when 3 overlays all fork the same dependency, and you
> want to use all three?
somwthing bad
>
> The distributed repository works well for release-based distros since
> the core of the OS is fixed.  A repository for Ubuntu x.y will always
> work with Ubuntu x.y, since Ubuntu x.y isn't going to upgrade from
> libfoo-2 to incompatible libfoo-2.3.
I disagree distributed repository does NOT work well, even for release
based distro.
They are annoing, require magic updating at the right time and break often.
Gentoo being compiled can avoid some but not all pitfalls and could
introduce a lot more.

>
> On the other hand, libraries on Gentoo can change without warning, and
> the only quality standard we impose is that the main repo still works
> (with no forced testing of distributed repos).
And thinking to be able to impose something more is very optimistic
(maybe doable with a much smaller tree like USE=-X @system)
>
> If we want to truly support first-class distributed repos, then we'll
> need to impose a number of standards on the main tree that we do not
> impose today.
>
> --
> Rich
>
good luck

--
Francesco  Riosa

Re: [gentoo-dev] [gentoo-project] Re: towards a more distributed model

[viv...@gmail.com]

Il 20/11/2014 01:00, Jeroen Roovers ha scritto:
> On Wed, 19 Nov 2014 18:54:05 +0100
> hasufell  wrote:
>
>> At that point it is forked. I don't see what's wrong with forking.
> Forking wouldn't be the problem. Duplication of effort would be the
> problem.
>
>
>  jer
>
worse, mutually incompatibility would be much worse

[gentoo-dev] overlays.g.o status

[viv...@gmail.com]

hi,
  what's the status of o.g.o?

May I offer an lxc container?

Regards,
Francesco Riosa


http://infra-status.gentoo.org/

The CVS and Git Overlays services have been successfully migrated to the
new hosts.

Please note the following:

Gitweb as well as the http://overlays.gentoo.org/ and
http://anon{cvs,git}.gentoo.org/ web sites are currently not available
pending restructuring of our read-only access setup.
The SSH keys for the machine have changed:
DSA: 5f:c3:fe:9a:ac:a7:99:f4:d3:c1:93:4c:52:87:74:28
RSA: 24:3b:2d:3b:47:ca:7e:62:48:97:49:6a:f5:ad:66:88
ECDSA: aa:6a:e4:74:1d:73:d2:5a:9f:45:9f:18:55:81:c9:9a
ED25519: 1c:2e:99:7d:c7:f0:bc:3b:a9:fb:d0:3e:2c:2a:79:ba

Update (2014-09-19):

At this point there's still no ETA to resume the gitweb and http access.
We're waiting on systems from a new sponsor to host these services.

Re: [gentoo-dev] Re: sys-devel/gcc::mgorny up for testing

[viv...@gmail.com]

Il 08/12/2014 00:17, Martin Vaeth ha scritto:
> Michał Górny  wrote:
>> Have you tried mcpdf?
> I heard about it now for the first time.
>
> If I understand correctly, it uses the same library
> as pdfTK, only a somewhat later version
> (e.g. with improved unicode handling).
>
> The main difference seems to be that it does not insist
> on gcj but apparently should work with any java: I had
> suspected that it is the library which depends on some
> gcj internals and not just the front-end which consists
> just of a few lines, anyway.
>
> So, indeed, this looks like it should be a drop-in
> replacement, though I did not check whether the
> license of the updated library changed.
>
> Anyway, it would be nice to have it in the tree. ;)
>
>> but testing with your tricky PDFs
> I do not remember anymore. I just remember that
> several times, when some deadline approached,
> I had to resort to pdftk at my institute's Debian
> (in the lack of a gcj at home), even for simple tasks
> as merging pdftex output with some scanned PDF pages:
> neither pdfjam nor poppler did it satisfactory,
> though I do not remember the reasons.
>
A simple concatenation does not work for me:

$ alias pdftk='java -jar /srv/git/M/mcpdf-0.2.1-jar-with-dependencies.jar'
$ pdftk \
>  4265498/0010-visura_alvise.pdf 4265498/report_sister_AT00.pdf
4265499/0010-visura_alvise.pdf \
>  cat output OUT.pdf
java.lang.RuntimeException: Unknown operation:
4265498/report_sister_AT00.pdf
See README for more information.

also having it in tree would be better, and a pair of warnings:

- The project only has 20 commit, last one 8 months ago
  https://github.com/m-click/mcpdf.git
- in the readme there is this "Note that not all PDFtk operations are
implemented at the moment."

hardly a drop in I would trust to replace pdftk which only had problems
once (at compile time) because of a gcc upgrade.

but
find /g/portage/ -name '*.ebuild' -exec egrep 'sys-devel/gcc.*gcj' {} +
show that really only pdftk, dev-java/ecj-gcj and dev-java/gcj-jdk
depend on gcc with gcj enabled.
maybe too few to maintain a broken gcc extension, probably also "go"
should go

regards,
Francesco Riosa

Re: [gentoo-dev] Re: sys-devel/gcc::mgorny up for testing

[viv...@gmail.com]

Il 08/12/2014 01:05, Gordon Pettey ha scritto:
> On Sun, Dec 7, 2014 at 3:21 PM, Kristian Fiskers
>
>
> By all means, thanks for informing about an alternative, but I
> personally believe that it is important for the overall distribution
> to keep a wider perspective than personal non-free use (even if this
> is a developers primary focus as reason for contribution), otherwise
> we'll hit a wall quickly enough.
>
> In this specific case I at least use pdftk for some batch jobs on
> business-related servers and a non-commercial license would not be
> viable. 
>
>
> pdfTK is also GPLv2, (effectively GPLv3 since iText is /A/GPLv/3/?
> Effectively AGPLv3 when in a public-facing service?) unless you're
> paying for it. I doubt m-click would refuse to consider alternative
> paid licensing if they were asked.
pdftk 2.02 use an older itext with license GPLv2+

license_gpl_pdftk/third_party/itext-paulo.txt
 *
 *
 * This library is free software; you can redistribute it and/or
 * modify it under the terms of the GNU Library General Public
 * License as published by the Free Software Foundation; either
 * version 2 of the License, or (at your option) any later version.
 *
 * This library is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
 * Library General Public License for more details.
 *
 * You should have received a copy of the GNU Library General Public
 * License along with this library; if not, write to the
 * Free Software Foundation, Inc., 51 Franklin St, Fifth Floor,
 * Boston, MA  02110-1301, USA.

Re: [gentoo-dev] Re: sys-devel/gcc::mgorny up for testing

[viv...@gmail.com]

Il 09/12/2014 15:26, Martin Vaeth ha scritto:
> viv...@gmail.com  wrote:
>> - The project only has 20 commit, last one 8 months ago
>>   https://github.com/m-click/mcpdf.git
> The "project" is just a few lines anyway: merely a wrapper to the library.
> All the work happens in the itext library which AFAIK is the same project
> (in different versions) for pdftk as for mcpdf.
> Of course, the new library version might contain new bugs,
> as your example seems to suggest (did pdftk work with this example?)
my example work daily in a box with very few updated and some builds at
least 2 years old, and it's the simplest one.
yet it's working well from a lot of time.

pdftk is NOT only a wrapper to itext (a 9 years old version [2]) it also
include a java library for crypto and it's own management  in c++ files.
now,  without counting the java crypto lib the c++ files weight around
8k LOC [3]

itext may have been evolved, but calling a 90 LOC java program a "drop
in" replacement for pdftk seem adventurous ...
for comparison  `pdftk --help` output is 556 lines of text.

so we can conclude that the "project" is NOT what it claims to be and a
replacement (even using modern itext with licensing problems) will
weight at least at least 556 lines?


>
>> find /g/portage/ -name '*.ebuild' -exec egrep 'sys-devel/gcc.*gcj' {} +
> Searching also through all layman (remote) overlays with
>
> $ eix -#Rry 'sys-devel/gcc[^ ]*gcj'
>
> I found besides the mentioned
>
> app-text/pdftk
> dev-java/ecj-gcj
> dev-java/gcj-jdk
>
> one further dependency:
>
> $ eix -Rvle imule
>   net-p2p/imule [1]
>   [...]  irouter? ( sys-devel/gcc[gcj] ) [...]
>   P2P sharing software which connects through I2P and Kad network [...]
> [1] "zugaina" layman/zugaina
[2]
http://sourceforge.net/projects/itextpdf/files/itext-paulo/itext-paulo-155/
[3] $ LC_ALL=C wc -l  *cc
   542 attachments.cc
   498 passwords.cc
  4482 pdftk.cc
  2433 report.cc
   137 win32_utf8_include.cc
  8092 total

Re: [gentoo-dev] Re: Moving CPU flags into USE_EXPAND

[viv...@gmail.com]

Il 15/01/2015 11:30, Alexis Ballier ha scritto:
> On Thu, 15 Jan 2015 10:20:15 + (UTC)
> Martin Vaeth  wrote:
>
>> Christopher Head  wrote:
>>> All that requires is knowing the names, though; it would be
>>> fine if no package actually uses the feature yet.
>> ++
>>
>> More precisely: When changing the names anyway,
>> IMHO it would be a very good idea to follow the convention of the
>> "flag" names in /proc/cpuinfo and add all flags supported
>> there as possible USE-flags, no matter, whether they are currently
>> used in some package or not.
>
> seriously ?
>
> $ grep flags /proc/cpuinfo | head -n 1 | wc -w
> 94
>

Actually I like the idea, there are performances problems  related to
ebuilds or portage?

CPU_FLAGS=$(grep -m1 flags /proc/cpuinfo)
CPU_FLAGS=${CPU_FLAGS#*:}
echo $CPU_FLAGS | wc -w
92

Re: [gentoo-dev] Re: Review: news item and script for CPU_FLAGS_X86

[viv...@gmail.com]

Il 24/01/2015 00:12, Michał Górny ha scritto:
>   $ emerge -1v app-portage/cpuinfo2cpuflags
>   $ cpuinfo2cpuflags-x86.py
it's

cpuinfo2cpuflags-x86

w/o the .py here

Re: [gentoo-dev] toolchain.eclass: need to revert fixincludes commit

[viv...@gmail.com]

Il 02/02/2015 23:30, Pacho Ramos ha scritto:
> El sáb, 31-01-2015 a las 16:48 -0500, Anthony G. Basile escribió:
>> Hi everyone,
>>
>> We need to revert the following change to toolchain.eclass:
>>
>> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/toolchain.eclass?r1=1.647&r2=1.648
>>
>> It turns out that bsd and prefix need fixincludes while building gcc 
>> itself, so disabling their build will make gcc unbuildable on those 
>> systems.  Only after gcc is built can you dump them.  I did test on many 
>> exotic systems, but did not look at gentoo/fbsd.
>>
>> See bug #536878.  Thanks Ryan and Fabian.
>>
>> I'll revert after feedback.
>>
> Please remember to add a comment to the eclass with the reference to not
> forget in the future why fixincludes stuff is needed ;)
>
>
fixincludes only on prefix and bsd is doable/acceptable?

Re: [gentoo-dev] ffmpeg vs libav choice of default

[viv...@gmail.com]

Il 04/02/2015 10:24, Ben de Groot ha scritto:
> From an upstream that I care about:
> https://github.com/mpv-player/mpv/wiki/FFmpeg-versus-Libav Based on
> that I would say we should switch back the default to ffmpeg. 

on that page I see a information about why gentoo should stick with
libav, because cleaner code for a distro is very important.

also ebuilds seem to reflect that:

grep -v -e '^\s*#' -e '^\s*$' ffmpeg/ffmpeg-2.5.3.ebuild | wc -l
299

grep -v -e '^\s*#' -e '^\s*$' libav/libav-9.17.ebuild  | wc -l
248

cheers,
Francesco Riosa

Re: [gentoo-dev] Why gcc-config is a separate utility, not a module for eselect?

[viv...@gmail.com]

good memory,
maybe someone could write a frontend in eselect to gcc-config, to have a
proved manager _and_ everything in one place.

Il 28/02/2015 13:41, malc ha scritto:
> Read these :) There was an attempt, many years ago when I was still a
> Dev, but it never quite worked as intended and ended up getting punted
> again.
>
> malc.
>
> http://thread.gmane.org/gmane.linux.gentoo.devel/38739
> https://bugs.gentoo.org/show_bug.cgi?id=199914
> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-admin/eselect-compiler/?hideattic=0
>
>
> On Sat, Feb 28, 2015 at 11:40 AM, Юра Цимбалов  > wrote:
>
> Hi all!
> Why some utilites like a gcc-config or java-config is a separate
> utilites, not a module for eselect? Maybe these utilites has some
> features, that cannot be implemented with eselect?
>
> P.S. Sorry my poor and bad English language.
>
> --
> Yuri Tsimbaloff mailto:yura.t...@gmail.com>>
>
>