Re: [gentoo-dev] Why gcc-config is a separate utility, not a module for eselect?
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, Юра Цимбалов yura.t...@gmail.com mailto:yura.t...@gmail.com 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 yura.t...@gmail.com mailto:yura.t...@gmail.com
Re: [gentoo-dev] ffmpeg vs libav choice of default
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] toolchain.eclass: need to revert fixincludes commit
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.647r2=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] Re: Review: news item and script for CPU_FLAGS_X86
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] Re: Moving CPU flags into USE_EXPAND
Il 15/01/2015 11:30, Alexis Ballier ha scritto:
On Thu, 15 Jan 2015 10:20:15 + (UTC)
Martin Vaeth mar...@mvath.de wrote:
Christopher Head ch...@chead.ca 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-portage-dev] [RFC] New file layout for PKGDIR and binhosts
Il 24/12/2014 09:13, Zac Medico ha scritto:
I like this (and it has been a long time coming). What format are we
going to store the metadata of the use flag combinations and the rest?
The current approach is to store the data in an xpak segment that is
appended to the end of the tbz2 file. The $PKGDIR/Packages files serves
as a cache for the essential parts of the xpak data that are used in
dependency calculations.
I'd like to see the xpak data being put in it's own file at the
_beginning_ of the tar file.
tar -Jcf \
${PKGDIR}/${CATEGORY}/${PN}/${PF}-${COUNTER}.xpak \
tmp/${CATEGORY}:${PN}:${PF}-${COUNTER}.xpak \
*all_the_other_stuff*
this way reading it could be faster on some media and filesystem and it
would not deviate from the standard tar.
Being in /tmp/ is only for commodity but the place is debatable.
Instead the fact it _must_ be the first file it's not, in a sequential
archive file like tar some things depend on it.
seem to be the right time to do the change, since tool need to be
rewritten anyway, but I'll leave to you analyze the fallout of this change.
Best regards,
Francesco Riosa
Re: [gentoo-portage-dev] [RFC] New file layout for PKGDIR and binhosts
Il 24/12/2014 17:07, Zac Medico ha scritto:
On 12/24/2014 04:01 AM, viv...@gmail.com wrote:
Il 24/12/2014 09:13, Zac Medico ha scritto:
I like this (and it has been a long time coming). What format are we
going to store the metadata of the use flag combinations and the rest?
The current approach is to store the data in an xpak segment that is
appended to the end of the tbz2 file. The $PKGDIR/Packages files serves
as a cache for the essential parts of the xpak data that are used in
dependency calculations.
I'd like to see the xpak data being put in it's own file at the
_beginning_ of the tar file.
tar -Jcf \
${PKGDIR}/${CATEGORY}/${PN}/${PF}-${COUNTER}.xpak \
tmp/${CATEGORY}:${PN}:${PF}-${COUNTER}.xpak \
*all_the_other_stuff*
this way reading it could be faster on some media and filesystem and it
would not deviate from the standard tar.
There wouldn't be any benefit, because the data is practically always
read from the $PKGDIR/Packages cache anyway. The cache is generated when
the package is built, and the rate-limiting step there is the building
of the package.
ack, and what about emerge on destination host?
Being in /tmp/ is only for commodity but the place is debatable.
Instead the fact it _must_ be the first file it's not, in a sequential
archive file like tar some things depend on it.
With the current approach, the xpak segment is not part of the tar file.
The tar file is compressed, and the xpak segment is appended to the end
of the resulting bzip2 file.
seem to be the right time to do the change, since tool need to be
rewritten anyway, but I'll leave to you analyze the fallout of this change.
There will be zero benefits from doing that.
I see at least two however admittedly not too big
1) I see having a canonical tarball as an advantage, opposed to be
forced to use /usr/bin/{qtbz2,qxpak}
2) there is a small benefit in space (which increase using xz) for
bigger packages it would be smaller in percentage.
-rw-r--r-- 1 root root 8720 24 dic 18.25 linuxtv-dvb-headers-5.8.tar.bz2
-rw-r--r-- 1 root root 9691 24 dic 18.07 linuxtv-dvb-headers-5.8.tbz2
this has been obtained unpacking the xpak _and_ environment.bz2 (to
avoid double compression) and putting them in a subdirectory
ls -l tmp/linuxtv-dvb-headers-5.8/ usr
tmp/linuxtv-dvb-headers-5.8/:
total 80
-rw-r--r-- 1 root root11 Dec 24 18:20 BUILD_TIME
-rw-r--r-- 1 root root 8 Dec 24 18:20 CATEGORY
-rw-r--r-- 1 root root 2 Dec 24 18:20 DEFINED_PHASES
-rw-r--r-- 1 root root52 Dec 24 18:20 DESCRIPTION
-rw-r--r-- 1 root root 2 Dec 24 18:20 EAPI
-rw-r--r-- 1 root root 394 Dec 24 18:20 FEATURES
-rw-r--r-- 1 root root 1 Dec 24 18:20 IUSE
-rw-r--r-- 1 root root30 Dec 24 18:20 KEYWORDS
-rw-r--r-- 1 root root24 Dec 24 18:20 PF
-rw-r--r-- 1 root root31 Dec 24 18:20 RDEPEND
-rw-r--r-- 1 root root 2 Dec 24 18:20 SIZE
-rw-r--r-- 1 root root 2 Dec 24 18:20 SLOT
-rw-r--r-- 1 root root65 Dec 24 18:20 USE
-rw-r--r-- 1 root root 22859 Dec 24 18:21 environment
-rw-r--r-- 1 root root 443 Dec 24 18:20 linuxtv-dvb-headers-5.8.ebuild
-rw-r--r-- 1 root root 7 Dec 24 18:20 repository
usr:
total 9
drwxr-xr-x 3 root root 3 Dec 5 02:42 src
Re: [gentoo-dev] Re: sys-devel/gcc::mgorny up for testing
Il 09/12/2014 15:26, Martin Vaeth ha scritto:
viv...@gmail.com 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-portage-dev] [PATCH] Support @profile package set for bug #532224
just a typo: confgured BTW could this be used to shrink the @system set, and remove stuff like mandb for example? cheers, Francesco R.
Re: [gentoo-dev] Re: sys-devel/gcc::mgorny up for testing
Il 08/12/2014 00:17, Martin Vaeth ha scritto:
Michał Górny mgo...@gentoo.org 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
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.
[gentoo-dev] overlays.g.o status
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] [gentoo-project] Re: towards a more distributed model
Il 20/11/2014 00:58, Rich Freeman ha scritto: On Wed, Nov 19, 2014 at 12:54 PM, hasufell hasuf...@gentoo.org 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
Il 20/11/2014 01:00, Jeroen Roovers ha scritto: On Wed, 19 Nov 2014 18:54:05 +0100 hasufell hasuf...@gentoo.org 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
Re: [gentoo-dev] [gentoo-project] Re: towards a more distributed model
Il 18/11/2014 14:12, Jauhien Piatlicki ha scritto: On 11/18/2014 04:19 AM, hero...@gentoo.org wrote: Jauhien Piatlicki jauh...@gentoo.org 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] Portage dependency solving algorithm
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
Il 08/11/2014 14:35, Ciaran McCreesh ha scritto: On Sat, 08 Nov 2014 09:29:52 +0100 viv...@gmail.com 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] more help needed with gcc-4.8 stabilization, chromium starts heavily using C++11
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 http://thread.gmane.org/gmane.linux.gentoo.devel/92113 I explored the possibility to stabilize gcc-4.8, and we have that going now in https://bugs.gentoo.org/show_bug.cgi?id=516152. 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 http://chromium-cpp.appspot.com/ . 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 https://bugs.gentoo.org/show_bug.cgi?id=461954 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 https://bugs.gentoo.org/show_bug.cgi?id=513386. 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 https://bugs.gentoo.org/show_bug.cgi?id=500966 which may be more tricky. I could reproduce that bug. It's also about webkit-gtk. There are couple more blockers of https://bugs.gentoo.org/show_bug.cgi?id=461954. 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] Add bc back to the stage3
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] Re: My masterplan for git migration (+ looking for infra to test it)
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] My masterplan for git migration (+ looking for infra to test it)
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] RFC: using .xz for doc/man/info compression
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] RFC: Hosting daily gx86 squashfs images and deltas
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: Hosting daily gx86 squashfs images and deltas
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 sort_file thanks for it, Francesco
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-sound/umurmur: metadata.xml ChangeLog
On 12/26/13 14:27, Ciaran McCreesh wrote: On Thu, 26 Dec 2013 14:25:04 +0100 hasufell hasuf...@gentoo.org 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] How to support C++11 in libraries?
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] Gnome Stabilization 3.6 or 3.8
On 08/09/13 15:54, Michał Górny wrote: Dnia 2013-08-09, o godz. 14:14:12 viv...@gmail.com 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 patr...@gentoo.org 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] Gnome Stabilization 3.6 or 3.8
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 patr...@gentoo.org 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] renaming gentoo-oldnet
[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] s/disk space/drive space
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] Re: Calling die in a subshell
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] Calling die in a subshell
On 06/15/13 19:02, Mike Gilbert wrote: On Sat, Jun 15, 2013 at 1:01 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Sat, 15 Jun 2013 12:56:00 -0400 Mike Gilbert flop...@gentoo.org 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
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)
[gentoo-dev] RFC how to handle disappearing USE in (portage) dependency calculation
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
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] Draft news item: MySQL/MariaDB packages dropping support for PrimeBase (PBXT) engine
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!
Re: [gentoo-portage-dev] Re: Is portage (/usr)/bin-merge safe?
On 06/02/13 13:54, Duncan wrote:
viv...@gmail.com posted on Sun, 02 Jun 2013 13:14:41 +0200 as excerpted:
While portage can be safe, for various reason (including the resultant
pkg) I do prefer to do the move in post_src_install() #1 All my tests
have been done against a manually converted filesystem
That's what mine would be...
#1 excerpt from bashrc, this code is rough but work in the gentoo
ebuilds tree domain
move_root_to_usr() {
Thanks. What I was thinking would actually reverse that (/bin being the
real dir, /sbin being a symlink to it), given my (traditional sysadmin)
pref for short paths, but I hadn't thought of a bashrc solution at all,
so that gives me yet another way of doing it. =:^)
My first thought is that I prefer standard layout packages, however,
easing interoperability should I decide to swap binpkgs with someone.
(Yes, I'm aware of the security issues if the parties don't trust each
other...)
But OTOH I think that solves issues such as path-based equery belongs,
for instance. Being amd64 for nearing a decade now (and no-multilib for
several years of it), I'm used to worrying about that with the symlinked
lib/lib64 thing, and that's the one thing I wasn't looking forward to
with unified bins. (I think I'll keep bin/sbin separate at first, see
how bin/usr-bin go first, then think about bin/sbin.)
But if your bashrc solution /does/ solve the equery belongs path thing I
might well use it on lib/lib64 as well... (Either that or since I
believe the libs are a profile thing and I'm already running a heavily
modified profile, no @system for instance, I could probably simply modify
that... Actually, that's probably a better solution in any case, since
it's just undoing mainline settings the same way mainline does them in
the first place.)
I do generally leave profiles untouched but yes it could be a solution,
maybe some research in debian maillist could be beneficial too.
In the meantime these commands results should tell you about equery belongs:
homvivo$ qlist coreutils | grep -c '^/bin/'
0
homvivo$ qlist coreutils | grep -c '^/usr/bin/'
101
homvivo$ equery belongs /usr/bin/sleep
* Searching for /usr/bin/sleep ...
sys-apps/coreutils-8.21 (/usr/bin/sleep)
Re: [gentoo-dev] robo-stable bugs
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
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
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] Re: CPU use flag detection
On 05/19/13 17:47, Alexis Ballier wrote: On Sat, 18 May 2013 22:31:11 -0400 Walter Dnes waltd...@waltdnes.org 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] USE_EXPAND is not an IUSE replacement [was: New USE_EXPAND: CLAWS_MAIL_PLUGINS]
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
Il 04/05/2013 19:42, Jeroen Roovers ha scritto: On Fri, 03 May 2013 20:18:42 +0200 Justin j...@gentoo.org wrote: + 03 May 2013; Justin Lecher j...@gentoo.org +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] rfc: oldnet scripts splitting out from OpenRC
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 willi...@gentoo.org 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 oldnet 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] FYI: libpng16 won't be able to show some broken icons libpng15 was still able to
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] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
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
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
Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
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] call for testers: udev predictable network interface names
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: new qt category
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
Il 16/01/2013 17:25, Mike Gilbert ha scritto: On Wed, Jan 16, 2013 at 10:19 AM, Tobias Klausmann klaus...@gentoo.org 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] GCC 4.6 stabilization
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] Is /var/cache the right place for repositories?
Il 24/12/2012 10:11, Ciaran McCreesh ha scritto: On Mon, 24 Dec 2012 03:17:06 +0100 Sebastian Pipping sp...@gentoo.org 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] Defaulting for debug information in profiles
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] Defaulting for debug information in profiles
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] Last rites: app-admin/profiler
Il 28/11/2012 00:04, Sebastian Pipping ha scritto: # Sebastian Pipping sp...@gentoo.org (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] About DESCRIPTION in ebuilds needing to end with a dot .
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] GLEP: gentoo sync based unified deps proposal
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] EJOBS variable for EAPI 5?
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] EJOBS variable for EAPI 5?
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] Re: Questions about SystemD and OpenRC
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=label or UUID=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, the pieces
I already have thanks to discussions like this, will fall into place, and
it'll be far easier to get upto speed than it would have been had I tried
going
Re: [gentoo-dev] Re: Questions about SystemD and OpenRC
Il 12/08/2012 14:25, Rich Freeman ha scritto: On Sun, Aug 12, 2012 at 5:43 AM, Duncan1i5t5.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
Il 12/08/2012 09:44, Michał Górny ha scritto: On Sun, 12 Aug 2012 01:29:43 +0200 viv...@gmail.comviv...@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] Questions about SystemD and OpenRC
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: gentoo-x86 commit in dev-perl/XML-Parser: XML-Parser-2.410.0-r1.ebuild ChangeLog
Il 07/08/2012 18:26, Fabian Groffen ha scritto:
On 07-08-2012 18:03:14 +0200, Torsten Veller wrote:
* Fabian Groffen (grobian)grob...@gentoo.org:
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] Portage FEATURE suggestion - limited-visibility builds
Il 31/07/2012 21:27, Michał Górny ha scritto: On Tue, 31 Jul 2012 15:16:34 -0400 Rich Freemanri...@gentoo.org wrote: On Tue, Jul 31, 2012 at 10:56 AM, Ian Stakenviciusa...@gentoo.org 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] RFC: virtual/libudev
Il 11/07/2012 22:33, Mike Gilbert ha scritto: On Wed, Jul 11, 2012 at 3:54 PM, William Hubbswilli...@gentoo.org 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] Kernel compiles and you
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: Enable FEATURES=userpriv usersandbox by default?
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] RFC: Enable FEATURES=userpriv usersandbox by default?
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.
[gentoo-dev] [RFC] gcc-native-flags() proposal addition to toolchain-funcs.eclass
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] x32 release candidate
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? OTBSLCI'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)./LC/BS/OT -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
Re: [gentoo-dev] RFC: iotop needs to run as root after kernel change
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] About suggesting to create a separate partition for portage tree in handbook
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 tetrom...@gentoo.org 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
