[gentoo-dev] Re: [gentoo-dev-announce] More packages up for grabs due to developer inactivity

[Marc Schiffbauer]

* Michał Górny schrieb am 14.02.24 um 11:38 Uhr:
> Hello,
> 
> The following packages are also left with no maintainer:

I will take care of this:

> sys-fs/zfs-auto-snapshot



-- 
0x8201F9436611ABF9 - 41C5 71F2 0535 7D66 2E71
 6DAA 8201 F943 6611 ABF9


signature.asc
Description: PGP signature

[gentoo-dev] Package up for grabs: net-dns/opendnssec

[Marc Schiffbauer]

Hi,

net-dns/opendnssec needs a new maintainer as I am not using it anymore.

Current version is in tree now and works fine. Three open bugs exist: 
One for failing tests and two for future compiler compatibilty.

-Marc

Re: [gentoo-dev] [RFC] A new GLSA schema

[Marc Schiffbauer]

* John Helmert III schrieb am 10.11.22 um 14:19 Uhr:
> On Thu, Nov 10, 2022 at 02:10:09PM +1000, Marc Schiffbauer wrote:
> > * Sam James schrieb am 10.11.22 um 13:58 Uhr:
> > > 
> > > I think we'd rename impact -> description but description would now
> > > be "description of the problem" and not "description of the package".
> > 
> > 
> > +1, but additionally having the short description of the package sounds 
> > still useful to me, as not always everybody knows what any package is 
> > exactly for and the description will help a lot in telling the 
> > impact/danger of your own infra that might be caused by that package.
> > 
> > -Marc
> 
> Are you saying you rely on the background field, which is generally
> just the package's DESCRIPTION? Maybe glsa-check should just spit out
> the package's DESCRIPTION then too.

Sometimes the GLSA-Mails will be send to some team mailbox for example, 
and a teammember has to decide how urgent an update may be. Having a 
little description for the software mentioned in the GLSA is helpful 
then.



signature.asc
Description: PGP signature

Re: [gentoo-dev] [RFC] A new GLSA schema

[Marc Schiffbauer]

* Sam James schrieb am 10.11.22 um 13:58 Uhr:
> 
> I think we'd rename impact -> description but description would now
> be "description of the problem" and not "description of the package".


+1, but additionally having the short description of the package sounds 
still useful to me, as not always everybody knows what any package is 
exactly for and the description will help a lot in telling the 
impact/danger of your own infra that might be caused by that package.

-Marc


signature.asc
Description: PGP signature

Re: [gentoo-dev] Add systemd/merged-usr profiles

[Marc Schiffbauer]

* Mike Gilbert schrieb am 03.09.22 um 01:11 Uhr:
> To more directly answer your question: yes, having /usr on a separate
> filesystem is still "supported" with an appropriate initramfs.

Thanks, makes me sleep better ;)

Maybe this can be pointed out a bit more in the docs, to make this more
clear.

Thanks again
-Marc

-- 
0x8201F9436611ABF9 - 41C5 71F2 0535 7D66 2E71
 6DAA 8201 F943 6611 ABF9


signature.asc
Description: PGP signature

[gentoo-dev] Last rites: mail-filter/sigh

[Marc Schiffbauer]

# Marc Schiffbauer  (2022-09-02)
# Dead upstream, open bugs, removal in 30 days
# bugs #829447, #836227, #862504
mail-filter/sigh


signature.asc
Description: PGP signature

Re: [gentoo-dev] Add systemd/merged-usr profiles

[Marc Schiffbauer]

* Mike Gilbert schrieb am 01.09.22 um 03:38 Uhr:
> On Wed, Aug 31, 2022 at 12:29 PM Jaco Kroon  wrote:
> >
> > Hi,
> >
> > That really depends.
> >
> > If the expectation is that everything in /usr/{bin,sbin,lib*} needs to now 
> > fit on / rather than /usr we're queued to re-install a very, very large 
> > number of hosts.
> 
> You have that reversed: the expectation is that everything in
> /{bin,sbin,lib} will fit in /usr. In other words, we move files from /
> into /usr.

So does this mean, that having /usr on a seperate filesystem remains 
"supported" but is now only possible with a proper initrd?

-Marc

-- 
0x8201F9436611ABF9 - 41C5 71F2 0535 7D66 2E71
 6DAA 8201 F943 6611 ABF9


signature.asc
Description: PGP signature

[gentoo-dev] Last-rites: app-misc/zygrib

[Marc Schiffbauer]

# Marc Schiffbauer  (2022-07-30)
# No update since 2016, compilation and build system
# errors
# Bugs #637150, #686078, #733066, #733068, #828986, #854744
# removal in 30 days (2022-08-29)
app-misc/zygrib


signature.asc
Description: PGP signature

[gentoo-dev] Last rites: dev-libs/bareos-fastlzlib

[Marc Schiffbauer]

# Marc Schiffbauer  (2022-03-22)
# Unmaintained upstream. No reverse dependencies.
# Removal on 2022-04-23.
dev-libs/bareos-fastlzlib


signature.asc
Description: PGP signature

Re: [gentoo-dev] Common options missed in OpenRC declarative scripts and how to improve them

[Marc Schiffbauer]

* Michael Orlitzky schrieb am 02.12.21 um 08:05 Uhr:
> On 2021-12-02 08:12:55, Alec Warner wrote:
> > 
> > Can we automate any of it? Emit QA warnings? etc.
> > 
> 
> I would love to be proven wrong, but I don't think so. We have two
> main problems. First, The service scripts are POSIX sh, which is
> better than bash, but still can't easily be parsed for semantic
> information.
> 
> Second, if the daemon is "special," then the service script is
> justified in being similarly unconventional. Unusual runtime behavior
> can't be statically detected, and I doubt that the well-behaved
> portion of daemons in the tree is large enough that we can warn about
> every script that smells a little bit fishy.

For "special" daemons, the ebuild could just set a QA_* variable to 
silence a qa warning if required.

-Marc

Re: [gentoo-dev] Experimental binary package hosting

[Marc Schiffbauer]

* Matt Turner schrieb am 23.09.21 um 09:28 Uhr:
> On Thu, Sep 23, 2021 at 7:12 AM Andreas K. Huettel  
> wrote:
> >
> > Hi Vadim,
> >
> > > Finally it happened!
> > > I already planned to try to ask infra/council about sponsoring few
> > > servers for build farm for "official gentoo binhosts" when I had
> > > enough time, but fortunately, you've already did that.
> > > It's very good news.
> >
> > Thanks! Nice to see that this is appreciated :)
> >
> > So far I'm only using "spare time" on the machine that builds the
> > releng stages (amd64, x86, m68k, riscv). So no need for a big server
> > farm.
> >
> > > Btw, do you need any help with that?
> > > I'd be very happy to help with that project.
> >
> > Sure! Feel free to add yourself to the Project:Binhost wiki page. I'll
> > ask for an alias and a channel soon.
> >
> > The most useful steps now are only half related to actual building. I
> > barely know any python and am not very familiar with portage
> > internals... this is what in my opinion we'd need next:
> >
> > 1) a tool to manage and manipulate a binpkg/ directory tree
> > The main functions that I see needed are
> > * delete packages/versions that are not in the gentoo repository
> > anymore (xpak and in index file), maybe with some grace time
> > * merge xpak files built elsewhere into the directory (also in the
> > index file)
> 
> eclean packages from gentoolkit does this exactly.

plus 'emaint binhost' for rebuilding the index after adding packages 
manually :)

-Marc

-- 
0xCA3E7BF67F979BE5 - F7FB 78F7 7CC3 79F6 DF07
 6E9E CA3E 7BF6 7F97 9BE5

Re: [gentoo-dev] New project: binhost

[Marc Schiffbauer]

* Andreas K. Hüttel schrieb am 10.02.21 um 12:57 Uhr:
> Hi all, 
> 
> I'm announcing a new project here - "binhost"
> 
> "The Gentoo Binhost project aims to provide readily installable, precompiled 
> packages for a subset of configurations, via central binary package hosting. 
> Currently we are still in the conceptual planning stage. "
> 
> https://wiki.gentoo.org/wiki/Project:Binhost
> 
> If you're interested in helping out, feel free to add yourself on the wiki 
> page.
> 
> Note that I see actually *building* the packages not as the central point of 
> the project (that could be e.g. a side effect of a tinderbox). I'm more 
> concerned about
> * what configurations should we use
> * what portage features are still needed or need improvements (e.g. binpkg 
> signing and verification)
> * how should hosting look like
> * and how we can test this on a limited scale before it goes "into production"
> * ...
> 
> Comments, ideas, flamebaits? :D

I like the idea very much. Lets make Gentoo suck less energy ;-)

I have thought of some aspects in the past.

My idea was to maybe have an additional term: 'flavours'. A flavour 
could be something like "most", "slim", "desktop" or "server" and each 
flavour may specify a subset of USE-flags to be enabled for packages or 
not.

That way people could propably make most out of a public binhost if the 
choose one of the available flavours. That way you would not need to set 
USE flags for any single package to match a packge available on a 
binhost and a binhost does not need to have any combination of USE flags 
for any package in order to be most effective.

With a flavour you could just express something like "I want the 
Plasma-Desktop profile with most features enabled". Or "I want the 
pasma-desktop as slim as possible". And we'd have some presets for that.

But before that, I think we'd need some features in portage that make 
binpkgs trustworthy by adding signatures to the packages or at least to 
the Metadata.

And Metadata should also be compressed or possibly be implemented in 
some incremental kind so that you will not have to download all the 
metadata everytime just because some random package changed that you do 
not even have installed or want to install.

If I had more time I would definitely join the project. Maybe this is 
the case in 2-3 years.

Cheers
-Marc

-- 
0xCA3E7BF67F979BE5 - F7FB 78F7 7CC3 79F6 DF07
 6E9E CA3E 7BF6 7F97 9BE5


signature.asc
Description: PGP signature

Re: [gentoo-dev] [News review] LibreSSL support discontinued

[Marc Schiffbauer]

Just a typo...

* Michał Górny schrieb am 03.01.21 um 21:47 Uhr:
> All these issued considered, we came to the conclusion that OpenSSL

s/issued/issues/

right?



signature.asc
Description: PGP signature

Re: [gentoo-dev] [virtualization project] Help needed with libvirt virtualization stack

[Marc Schiffbauer]

* Joonas Niilola schrieb am 22.09.20 um 14:06 Uhr:
> 
> On 9/22/20 3:02 PM, Marc Schiffbauer wrote:
> > I would like to help out with lxc 
> >
> > * Matthias Maier schrieb am 21.09.20 um 22:25 Uhr:
> >> Dear all,
> >>   app-emulation/lxc
> >>   app-emulation/lxc-templates
> >>
> >> If you use these packages and are interested in helping out with version
> >> bumps and maintenance, please contact me over e-mail / IRC and add
> >> yourself to the virtualization project :-)
> > I would like to help out with lxc
> >
> > -Marc
> >
> LXC is currently in a good state, but all help is of course welcome. I
> have multiple TODOs regarding them, just waiting for the next release.
> Let's discuss about those before touching ebuilds first please.

Yes sure, you can ping me via irc or mail anytime.

cheers
-Marc

-- 
0xCA3E7BF67F979BE5 - F7FB 78F7 7CC3 79F6 DF07
 6E9E CA3E 7BF6 7F97 9BE5


signature.asc
Description: PGP signature

Re: [gentoo-dev] [virtualization project] Help needed with libvirt virtualization stack

[Marc Schiffbauer]

I would like to help out with lxc 

* Matthias Maier schrieb am 21.09.20 um 22:25 Uhr:
> Dear all,
>   app-emulation/lxc
>   app-emulation/lxc-templates
> 
> If you use these packages and are interested in helping out with version
> bumps and maintenance, please contact me over e-mail / IRC and add
> yourself to the virtualization project :-)

I would like to help out with lxc

-Marc

-- 
0xCA3E7BF67F979BE5 - F7FB 78F7 7CC3 79F6 DF07
 6E9E CA3E 7BF6 7F97 9BE5


signature.asc
Description: PGP signature

Re: [gentoo-dev] rfc: kubernetes packaging

[Marc Schiffbauer]

* William Hubbs schrieb am 14.09.20 um 00:39 Uhr:
> All,
> 
> I would like to get some thoughts on kubernetes packaging.
> 
> When I started maintaining it in Gentoo, it was packaged as 7 ebuilds
> (one per executable), and only one of them was marked stable.
> 
> Since we normally do not split up monorepos into separate packages, I
> started moving everything over to one kubernetes ebuild.
> Now a bug has
> been opened which has a good case for kubeadm being a package on its
> own, so I have done that [1].
> 
> I need to know the best way to proceed, so I'll throw out a couple
> of questions:
> 
> 1) should I bring back the split packages and lastrites
> sys-cluster/kubernetes?
> 
> 2) should I just bring back other split packages that need to be split
> as I find them?
> 
> What do folks think would be the best way for us to package Kubernetes?


Interesting.

So it seems like at least kubeadm and kube-apiserver need to be in 
seperate packages.

I am not a kubernetes guy, but would SLOTting be an option? Like 
postgresql for example where you need both versions, old a new to do 
database migration.

If this is not an option I would say this is a case for split package 
and perhaps a meta-package bringing all of them together.

-Marc


-- 
0xCA3E7BF67F979BE5 - F7FB 78F7 7CC3 79F6 DF07
 6E9E CA3E 7BF6 7F97 9BE5


signature.asc
Description: PGP signature

Re: [gentoo-dev] Last rites: net-mail/automx

[Marc Schiffbauer]

* Rolf Eike Beer schrieb am 17.03.20 um 14:10 Uhr:
> Am Dienstag, 17. März 2020, 18:50:33 CET schrieb Marc Schiffbauer:
> > # Marc Schiffbauer  (2020-03-17)
> > # No py3 support, replaced by its successor automx2
> > # Removal in 30 days. Bug #708410
> > net-mail/automx
> 
> I still think it's a bad idea to put automx2 in www-servers. This is no 
> general web server, it's just a thing that uses HTTP transport. YMMV.

+1

Your are right! We discussed this already and will move the package at a 
later time when other cleanups are done.

-Marc

-- 
0xCA3E7BF67F979BE5 - F7FB 78F7 7CC3 79F6 DF07
 6E9E CA3E 7BF6 7F97 9BE5


signature.asc
Description: PGP signature

[gentoo-dev] Last rites: net-mail/automx

[Marc Schiffbauer]

# Marc Schiffbauer  (2020-03-17)
# No py3 support, replaced by its successor automx2
# Removal in 30 days. Bug #708410
net-mail/automx




signature.asc
Description: PGP signature

Re: [gentoo-dev] [RFC] Replacing binary-only SLOTs with separate packages

[Marc Schiffbauer]

* Michał Górny schrieb am 19.01.19 um 17:25 Uhr:
> On Sat, 2019-01-19 at 17:37 +0300, Andrew Savchenko wrote:
> > I do not like the idea. Slots are very elegant and effective
> > mechanism and is one of the points where Gentoo outruns other
> > distributions. Proposed approach with compat packages will
> > effectively disable slots for most cases.
> 
> You haven't brought a single argument as to how slots are better than
> compat packages.  In fact, it's not even clear if you're talking about
> the same use of slots that I am.

One was, that you have one package (ebuild directory) for each piece of 
software. Unlike other distributions which have lots of different 
packages all for the same source an many cases.

So I'd agree that its the more gentooish way to have it all in one 
ebuild directory.

That having said I agree that current use of compat slots might be 
somewhat confusing even to developers.

So why not improve usability here?

I think it would increase the understanding of compat slots if we
changed the naming of thoss slots.

How about this:

dev-libs/openssl
 (0.9.8-compat) 0.9.8u 0.9.8v 0.9.8w 0.9.8x ~0.9.8y 0.9.8z_p8-r1
 (0)1.0.0h 1.0.0i […] [M]~1.1.1a [M]~1.1.1a-r1
 (1.0.0-compat) ~1.0.2q-r200


I can imagine that this might improve the situation a lot.

Of cource thet woult still be the job to fix ebuilds where dependencies
are wrong.

-Marc

-- 
0xCA3E7BF67F979BE5 - F7FB 78F7 7CC3 79F6 DF07
 6E9E CA3E 7BF6 7F97 9BE5


signature.asc
Description: PGP signature

[gentoo-dev] Packages up for grabs: dev-python/{cliapp,CoverageTestRunner,larch,tracing,ttystatus} dev-util/cmdtest

[Marc Schiffbauer]

Hello,

The following packages are up for grabs.

Since obnam has gone I have no use for them anymore:

Package # open bugs  needs bump?

dev-python/CoverageTestRunner   1*   yes
dev-python/cliapp   3*   no
dev-python/larch1no
dev-python/tracing  0no
dev-python/ttystatus2*   yes
dev-util/cmdtest1*   yes

[*]
There is one open keywording request for multiple packages:
https://bugs.gentoo.org/530672

-Marc

-- 
0xCA3E7BF67F979BE5 - F7FB 78F7 7CC3 79F6 DF07
 6E9E CA3E 7BF6 7F97 9BE5

Re: [gentoo-dev] net-dns/dnssec-root: Blind stable on arm, critical bug 667774

[Marc Schiffbauer]

On October 11, 2018 19:05:43 Thomas Deutschmann  wrote:


On 2018-10-11 17:45, Corentin “Nado” Pazdera wrote:

What's a "blind stable"? I'm guessing stabilizing without testing? If
yes, why?


Yes, stabilized without testing.

Reason: No ARM arch team member with access to an ARM box was available
for the last ~7 days.

However, this update is critical for anyone using something like
net-dns/unbound with DNSSEC validation enabled (which isn't enabled by
default but you are encourage to switch this on).


And for unbound the time was over 30 days ago. Note that the new key will 
only be accepted by unbound if it has seen it for at least 30 days.


-Marc





--
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5

Re: [gentoo-dev] [PATCH v2 09/11] glep-0063: Make recommended expiration terms mandatory

[Marc Schiffbauer]

* Kristian Fiskerstrand schrieb am 06.07.18 um 13:00 Uhr:
> On 07/05/2018 05:37 PM, Marc Schiffbauer wrote:
> > I have my primary key offline only, so renewing/editing it is a much 
> > more time consuming matter than if I had my primary key always with me 
> > which I consider a bad idea because you do not need to.
> 
> But is it sufficiently time-consuming / difficult that it is a problem
> to do it once a year? What do you do when certifying/signing other's UIDs?

Well, at least its annoying. For me personally it might even be that I 
cannot commit to gentoo for some time when the key expired until I have 
the chance to update my primary key again.

And "some time" being somthing between 1 day and several weeks as I am 
travelling a lot.

-- 
0xCA3E7BF67F979BE5 - F7FB 78F7 7CC3 79F6 DF07
 6E9E CA3E 7BF6 7F97 9BE5


signature.asc
Description: PGP signature

Re: [gentoo-dev] [PATCH v2 09/11] glep-0063: Make recommended expiration terms mandatory

[Marc Schiffbauer]

* Michał Górny schrieb am 06.07.18 um 11:33 Uhr:
> W dniu pią, 06.07.2018 o godzinie 11∶08 +0200, użytkownik Marc
> Schiffbauer napisał:
> > * Michał Górny schrieb am 05.07.18 um 20:25 Uhr:
> > > W dniu czw, 05.07.2018 o godzinie 17∶37 +0200, użytkownik Marc
> > > Schiffbauer napisał:
> > > > +1 for 5 years or at least 3.
> > > > 
> > > > Having to renew/edit the key each year seems crazy to me.
> > > > 
> > > > I have my primary key offline only, so renewing/editing it is a much 
> > > > more time consuming matter than if I had my primary key always with me 
> > > > which I consider a bad idea because you do not need to.
> > > > 
> > > 
> > > ...and you consider it a good idea to keep the primary key untouched for
> > > 5 years?  You don't even know if the medium holding it still works.
> > 
> > Yes. Backup media exists at a different place.
> 
> If you don't see it for 5 years, how can you be sure that it is even
> still there?

Are you serious? Who tells you that I do not check from time to time?

I am sure there will always be some scenario which makes a key 
unacessible in some way. I do not disagree with that. Its a matter of 
propability.
And for the worst case there is a revoke-Certificate which can be used.


-- 
0xCA3E7BF67F979BE5 - F7FB 78F7 7CC3 79F6 DF07
 6E9E CA3E 7BF6 7F97 9BE5


signature.asc
Description: PGP signature

Re: [gentoo-dev] [PATCH v2 09/11] glep-0063: Make recommended expiration terms mandatory

[Marc Schiffbauer]

* Michał Górny schrieb am 05.07.18 um 20:25 Uhr:
> W dniu czw, 05.07.2018 o godzinie 17∶37 +0200, użytkownik Marc
> Schiffbauer napisał:
> > +1 for 5 years or at least 3.
> > 
> > Having to renew/edit the key each year seems crazy to me.
> > 
> > I have my primary key offline only, so renewing/editing it is a much 
> > more time consuming matter than if I had my primary key always with me 
> > which I consider a bad idea because you do not need to.
> > 
> 
> ...and you consider it a good idea to keep the primary key untouched for
> 5 years?  You don't even know if the medium holding it still works.

Yes. Backup media exists at a different place.

-- 
0xCA3E7BF67F979BE5 - F7FB 78F7 7CC3 79F6 DF07
 6E9E CA3E 7BF6 7F97 9BE5


signature.asc
Description: PGP signature

Re: [gentoo-dev] [PATCH v2 09/11] glep-0063: Make recommended expiration terms mandatory

[Marc Schiffbauer]

* Matthias Maier schrieb am 05.07.18 um 15:51 Uhr:
> 
> On Thu, Jul  5, 2018, at 08:36 CDT, Michał Górny  wrote:
> 
> > That said, I'm open to using a different recommendation, e.g. 2 years
> > as in riseup [1].  I suppose having the same time for both primary key
> > and subkeys would make the spec simpler, and many developers are
> > mistaking expiration times (as specified now) anyway.
> >
> > [1]:https://riseup.net/en/security/message-security/openpgp/best-practices#use-an-expiration-date-less-than-two-years
> 
> Make it at most 2, 3, (or as it has been so far 5) years for both
> primary and subkeys.

+1 for 5 years or at least 3.

Having to renew/edit the key each year seems crazy to me.

I have my primary key offline only, so renewing/editing it is a much 
more time consuming matter than if I had my primary key always with me 
which I consider a bad idea because you do not need to.


-Marc

-- 
0xCA3E7BF67F979BE5 - F7FB 78F7 7CC3 79F6 DF07
 6E9E CA3E 7BF6 7F97 9BE5


signature.asc
Description: PGP signature

Re: [gentoo-dev] Regarding the State of PaX in the tree

[Marc Schiffbauer]

* Anthony G. Basile schrieb am 16.04.18 um 14:12 Uhr:
> On 4/16/18 4:05 AM, Marc Schiffbauer wrote:
> > * Anthony G. Basile schrieb am 16.04.18 um 02:04 Uhr:
> >> Hi everyone,
> > 
> > Hi Anthony,
> > 
> > I vote for keeping PaX Support as I am still using it and might be doing 
> > so in the future.
> > 
> > Thanks ;)
> > -Marc
> > 
> 
> How are you able to test?  Do you have your hands on the latest grsec
> patches or are you using an old kernel.  Old at this point means one
> year old.

Right now, I only have grsecurity-sources (4.9.74) but I may have access 
to latest grsecurity patches later this year.

Gruß
-Marc

-- 
0xCA3E7BF67F979BE5 - F7FB 78F7 7CC3 79F6 DF07
 6E9E CA3E 7BF6 7F97 9BE5


signature.asc
Description: PGP signature

Re: [gentoo-dev] Regarding the State of PaX in the tree

[Marc Schiffbauer]

* Anthony G. Basile schrieb am 16.04.18 um 02:04 Uhr:
> Hi everyone,

Hi Anthony,

I vote for keeping PaX Support as I am still using it and might be doing 
so in the future.

Thanks ;)
-Marc

-- 
0xCA3E7BF67F979BE5 - F7FB 78F7 7CC3 79F6 DF07
 6E9E CA3E 7BF6 7F97 9BE5


signature.asc
Description: PGP signature

Re: [gentoo-dev] reproducible builds

[Marc Schiffbauer]

* Matt Turner schrieb am 04.02.18 um 19:04 Uhr:
> On Sun, Feb 4, 2018 at 7:25 AM, Samuel Bernardo
>  wrote:
> > Hi,
> >
> > I send this email to know the opinion of gentoo developers about
> > registering gentoo profiles in the context of reproducible-builds.org
> 
> Reproducible builds makes sense when you're distributing binaries to
> users. 

+1 .. and I just wanted to add that this might be something very 
valuable if you want some sort of public binhost like it is the case in 
another current thread on this list.

I would think of a giantic cache. If someone else already has built a 
reproducable bin-package of an ebuild with the exact same 
profile/USE/binutils/gcc/... combination that I am using too, then this 
would be something very useful IMO which saves a lot of buildtime and 
energy.

-Marc


-- 
0xCA3E7BF67F979BE5 - F7FB 78F7 7CC3 79F6 DF07
 6E9E CA3E 7BF6 7F97 9BE5


signature.asc
Description: PGP signature

Re: [gentoo-dev] New package neomutt

[Marc Schiffbauer]

* Nicolas Bock schrieb am 10.08.17 um 11:35 Uhr:
> It does of course. What's appropriate here depends on whether we 
> think somebody might want to have both mutt and neomutt installed 
> at the same time. If we don't allow this use case, we don't have 
> to worry about eselect and the neomutt binary will be called 
> 'mutt' (as it is called by upstream already). If we do allow this 
> use case, being able to eselect makes sense because then the 
> binary is still always called 'mutt'.

Why not just have mutt and/or neomutt for both packages? Whoever only 
wants neomutt and run it with 'mutt' can "alias mutt=neomutt" and be 
done.

Having en eselect module here is not really KISS and looks a bit like 
bloat to me which make things more complicated than they have to be.

Just my 2¢

-- 
0xCA3E7BF67F979BE5 - F7FB 78F7 7CC3 79F6 DF07
 6E9E CA3E 7BF6 7F97 9BE5


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: The changes about the stabilization process

[Marc Schiffbauer]

* Ciaran McCreesh schrieb am 29.12.16 um 18:23 Uhr:
> On Thu, 29 Dec 2016 13:28:12 +0100
> Marc Schiffbauer <msch...@gentoo.org> wrote:
> > "atom" is a well defined term in the gentoo world, so why not use it?
> 
> Because it isn't... Are set names atoms? Are package names without an
> associated category atoms?

That would be subject to extend it, right?

-Marc

-- 
0xCA3E7BF67F979BE5 - F7FB 78F7 7CC3 79F6 DF07
 6E9E CA3E 7BF6 7F97 9BE5


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: The changes about the stabilization process

[Marc Schiffbauer]

* Ulrich Mueller schrieb am 29.12.16 um 16:52 Uhr:
> >>>>> On Thu, 29 Dec 2016, Marc Schiffbauer wrote:
> 
> > I'd prefer "package versions" but the people will come up with 
> > "sys-apps/eix-1.2.3" or just "1.2.3", not the desired 
> > "=sys-apps/eix-1.2.3". 
> 
> Why would the equals sign be needed there?

I supposed it to do because I assumed that we are not going to change 
the expected values.

But yes, propably only listing the PV would be enough.

-Marc

-- 
0xCA3E7BF67F979BE5 - F7FB 78F7 7CC3 79F6 DF07
 6E9E CA3E 7BF6 7F97 9BE5


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: The changes about the stabilization process

[Marc Schiffbauer]

* Ulrich Mueller schrieb am 29.12.16 um 13:08 Uhr:
> > On Thu, 29 Dec 2016, Michael Palimaka wrote:
> 
> >> Any suggestions for improved text? Ideally it would be
> >> stabilisation/keywording agnostic as the same field is used in both
> >> components.
> 
> > ago suggested "Packages list" or "Package list" - thoughts?
> 
> Isn't it rather a list of "ebuilds" or "package versions"? That's the
> term which https://devmanual.gentoo.org/keywording/index.html uses.

I'd prefer "package versions" but the people will come up with 
"sys-apps/eix-1.2.3" or just "1.2.3", not the desired 
"=sys-apps/eix-1.2.3". 

"atom" is a well defined term in the gentoo world, so why not use it?

If we really expect something in the field what used to be an "atom" we 
should use the new term for it like "package dependency spec".

But for me "atom" really works best here...


-Marc

-- 
0xCA3E7BF67F979BE5 - F7FB 78F7 7CC3 79F6 DF07
 6E9E CA3E 7BF6 7F97 9BE5


signature.asc
Description: PGP signature

Re: [gentoo-dev] rfc: /etc/hostname on gentoo

[Marc Schiffbauer]

* Rich Freeman schrieb am 22.08.16 um 20:29 Uhr:
> On Mon, Aug 22, 2016 at 1:51 PM, Sven Vermeulen  wrote:
> >
> > Yes, wouldn't the Docker project be happy to take on a patch that uses
> > gethostname() or so?
> >
> 
> This might be another option: symlink to /proc/sys/kernel/hostname

I think on boot the hostname is actually set from the contents of that 
file. With this approach that cat would bite itself into its tail ;-)

-Marc

-- 
0xCA3E7BF67F979BE5 - F7FB 78F7 7CC3 79F6 DF07
 6E9E CA3E 7BF6 7F97 9BE5


signature.asc
Description: PGP signature

Re: [gentoo-dev] Signed push & clock drift rejection

[Marc Schiffbauer]

* Rafael Goncalves Martins schrieb am 18.07.16 um 03:12 Uhr:
> On Sat, Jul 16, 2016 at 11:33 AM, Andrew Savchenko  wrote:
> > Set it for a minute or two. This will protect from commits from
> > really out-of-sync systems (like 14 days mentioned above) and will
> > keep usablity hight for others.
> 
> I second this "request" :)
> 
> remote: Your system clock is off by 6 seconds (limit 5)

Why not fix your system clock? No ntpd running?

Check 'ntpq -pn'

-Marc

-- 
0xCA3E7BF67F979BE5 - F7FB 78F7 7CC3 79F6 DF07
 6E9E CA3E 7BF6 7F97 9BE5


signature.asc
Description: PGP signature

Re: [gentoo-dev] Need design help/input for eclean-kernel

[Marc Schiffbauer]

* Michał Górny schrieb am 30.06.16 um 15:19 Uhr:
> > My /boot/:
> > 
> > grub
> > lost+found
> > backup -> linux-4.4.1-gentoo-2
> > boot
> 
> What's 'boot' here? Is that relevant?

This might be a symlink to '.' which I too have on many systems. You 
need it, so grub can find files that start with /boot/ if you have /boot 
in its own partition. (IIRC)

-Marc


-- 
0xCA3E7BF67F979BE5 - F7FB 78F7 7CC3 79F6 DF07
 6E9E CA3E 7BF6 7F97 9BE5


signature.asc
Description: PGP signature

Re: [gentoo-dev] [RFC] bugs.g.o: Merging UNCONFIRMED & CONFIRMED into NEW

[Marc Schiffbauer]

* Kent Fredric schrieb am 16.06.16 um 16:05 Uhr:
> On 17 June 2016 at 01:52, Joshua Kinard  wrote:
> > because
> > sometimes, issues can get reported that are really obscure and, for example,
> > tied to a particular hardware configuration, thus cannot be easily and
> > independently confirmed
> 
> 
> Isn't that why "RESOLVED: Need Info" exists?

For me "RESOLVED" and "Need Info" does not belong together, so I find 
this state superfluous...

How about "ON HOLD: Need Info" instead?


-- 
0xCA3E7BF67F979BE5 - F7FB 78F7 7CC3 79F6 DF07
 6E9E CA3E 7BF6 7F97 9BE5


signature.asc
Description: PGP signature

Re: [gentoo-dev] News item: Upgrading Apache from 2.2 to 2.4

[Marc Schiffbauer]

* Dirkjan Ochtman schrieb am 14.01.16 um 22:41 Uhr:
> On Thu, Jan 14, 2016 at 10:53 AM, Duncan <1i5t5.dun...@cox.net> wrote:
> >> Display-If-Installed: www-servers/apache
> >
> > Can't that be made  > 2.4 need a news item about something they've already taken care of?
> 
> This makes sense to me, though I imagine it could be annoying if
> people (stupidly, but whatever) postpone reading their news items
> until after the upgrade. Is this a canonical approach? Would like some
> feedback from the experts, here!


Personally I'd not like it, when the news item will disappear right 
after the upgrade. So I'd prefer to not change it.

-Marc

> 
> Cheers,
> 
> Dirkjan
> 

-- 
0x35A64134 - 8AAC 5F46 83B4 DB70 8317
 3723 296C 6CCA 35A6 4134


signature.asc
Description: Digital signature

Re: [gentoo-dev] News item: Apache "-D PHP5" needs update to "-D PHP"

[Marc Schiffbauer]

* Michael Orlitzky schrieb am 06.01.16 um 20:53 Uhr:
> On 01/06/2016 02:36 PM, Sebastian Pipping wrote:
> > On 05.01.2016 20:35, Michael Orlitzky wrote:
> >> I just pushed a new revision with this fix. In eselect-php-0.8.2-r1,
> >> we ship both the new 70_mod_php.conf and the old 70_mod_php5.conf. The
> >> latter comes with a big warning at the top of it, stating that it is for
> >> backwards compatibility only.
> > 
> > Cool, sounds like a great idea to me.
> > 
> > I guess we don't need a news item any more then?
> > 
> 
> Upgraders still have a problem, but a much less severe one. After
> upgrading eselect-php, further attempts to `eselect php set apache2`
> will appear to have no effect, because the old 70_mod_php5.conf is
> loading the old symlink to libphp5.so. There are a few options:
> 
> 1. Leave things as is, and tell people what to do (read the elog) if
>they hit this situation.
> 
> 2. Proceed with a news item that basically says "read the elog."
> 
> 3. I could try to hack some magic into eselect-php to detect whether or
>not you have -DPHP5 set. Something simple, like grepping /etc/conf.d
>/apache2 for "PHP5". In that case we could omit a notice.
>This one simultaneously makes the most sense and feels like the
>biggest hack.

+1 for 3.

You can remove the hack in a year or so. I think most important is a 
good user experience. If this requires a hack because the design of the 
tools give you no other choice than be it.


-- 
0x35A64134 - 8AAC 5F46 83B4 DB70 8317
 3723 296C 6CCA 35A6 4134


signature.asc
Description: Digital signature

Re: [gentoo-dev] Determenistic system group and user id

[Marc Schiffbauer]

* Alec Warner schrieb am 13.12.15 um 23:23 Uhr:
[...]
> I never understood why people would think the distro should handle unique
> gid / uids. Plus you usually end up running:
> 
> 1) More than one distro.

not in most places

> 2) More than one 'flavor' of a single distro where for whatever reason, uid
> and gid decisions differed (they renumbered, etc.)
> 
> So if you want a consistent GID for a group, store the group name and gid
> in ldap and sync it; do not rely on your distro to do it. IMHO doing so is
> a design error.

I disagree here. Most (enterprise) environments use just one distro. And 
its just very useful if you have sticky UIDs for daemon users for 
example.

One example: You build an apache two-node cluster using DRBD (and 
pacemaker...).  If you happen to install some daemons in random order on 
both nodes you might end up with apache having different UIDs which will 
break things. This is a PITA.

ANd you do not want another central LDAP-Cluster just to have apache 
UIDs in sync ;)

Red Hat for example has unique distro UIDs for many years now.

I would strongly vote for making GLEP27 reality. It makes life easier in 
many places.

-Marc

-- 
0x35A64134 - 8AAC 5F46 83B4 DB70 8317
 3723 296C 6CCA 35A6 4134


signature.asc
Description: Digital signature

Re: [gentoo-dev] <>-DEPENDS

[Marc Schiffbauer]

* Ulrich Mueller schrieb am 07.09.15 um 15:07 Uhr:
> >>>>> On Mon, 7 Sep 2015, Marc Schiffbauer wrote:
> 
> > I'd like to propose a new kind of DEPEND syntax: <>
> 
> > This would mean "Any version but the one specified" and is usefull
> > when you have a dependency on another package but a single version
> > of it is not compatible for example.
> 
> This doesn't look like a feature that would be needed very often.
> Since "<>cat/foo-1" is equivalent to "|| ( >cat/foo-1  I wonder if it's worth the effort.

Valid point. I am unsure. If it it would make the resolver noticable 
slower, I'd say now. Otherwise propably yes.

> 
> > [...]
> 
> > What do you think and would is the proper way to suggest this for a
> > new EAPI? A new bug? On what?
> 
> It should be filed as a bug (assigned to "Gentoo Hosted Projects" /
> "PMS/EAPI").

Thanks.

> 
> Your proposal looks like a special case of bug 4315, though.

Which is solved using || ( >foo 

signature.asc
Description: Digital signature

Re: [gentoo-dev] <>-DEPENDS

[Marc Schiffbauer]

* Kent Fredric schrieb am 07.09.15 um 15:18 Uhr:
> On 8 September 2015 at 00:35, Marc Schiffbauer <msch...@gentoo.org> wrote:
> > What do you think and would is the proper way to suggest this for a new
> > EAPI?  A new bug? On what
> 
> 
> My opposition would be I figure its more likely you want a range of
> exclusion, not a single version.
> 
> EG: you don't really want !=dev-python/paramiko-1.13.0 , you want
> !=dev-python/paramiko1.13.0{,-r{0..999}} or something.

Erm. +1 
You are of cause right. So you just discovered a potential bug in my 
ebuild :-P

> 
> But distinguishing between "Just this exact version" and "This range" is hard.
> 
> Does <> Imply "and any -rversion" ?
> 
> Does <> imply "and any sub-version" like ~ does ?

Well, than I might change my mind and prefer != over <> as it would be 
more flexible:

!=foo/bar-1 => exact version
!~foo/bar-1 => that version and any revision

And as the cherry on the cake theere could be

<> ( foo/bar-1 foo/bar-5 )

To express real ranges (that would include revisions)

-Marc

-- 
0x35A64134 - 8AAC 5F46 83B4 DB70 8317
 3723 296C 6CCA 35A6 4134


signature.asc
Description: Digital signature

Re: [gentoo-dev] <>-DEPENDS

[Marc Schiffbauer]

* Ian Stakenvicius schrieb am 07.09.15 um 16:41 Uhr:
> Why not just:
> 
> DEPEND="
> dev-python/paramiko
> !~dev-python/paramiko-1.13.0
> "
> 
> Depend on the package but block the individual atom(s) that don't work?

I like it. At least with the current possibilities. I was not aware that 
"!~" is already a valid blocker.


> 
> Given that there will be *very few* valid use cases for this type of
> syntax I don't know if it's such a good idea to add it.  I expect
> adding this new syntax would be more likely to cause issues via
> improper usage than it would add a benefit or fill any massively
> pressing need...

Depending on how it is implemented, I think it would be intuitive to 
use. I'd find having "=" vs. "!=" and "~" vs. "!~" straight forward.

You are of cource right that there is no "massively pressing need" atm.  
But that was not always a reason for a new feature ;)

-Marc

-- 
0x35A64134 - 8AAC 5F46 83B4 DB70 8317
 3723 296C 6CCA 35A6 4134


signature.asc
Description: Digital signature

Re: [gentoo-dev] <>-DEPENDS

[Marc Schiffbauer]

* Michał Górny schrieb am 07.09.15 um 17:16 Uhr:
> Dnia 2015-09-07, o godz. 14:35:07
> Marc Schiffbauer <msch...@gentoo.org> napisał(a):
> 
> > I'd like to propose a new kind of DEPEND syntax: <>
> > 
> > This would mean "Any version but the one specified" and is usefull when 
> > you have a dependency on another package but a single version of it is 
> > not compatible for example.
> > 
> > I currently have this case in app-backup/obnam which is not compatible 
> > to =dev-python/paramiko-1.13.0
> > 
> > In DEPEND I now have this:
> > 
> >   !=dev-python/paramiko-1.13.0
> >   || ( dev-python/paramiko-1.13.0 )
> > 
> > which does the trick, but I think much more straight forward would be:
> > 
> >   <>dev-python/paramiko-1.13.0
> > 
> > which would be the exact opposite of =dev-python/paramiko-1.13.0
> 
> What if you want to exclude two versions? This looks like an even worse
> case of the > + < -dep problem.
> 
> > An alternate syntax would be (but I'd prefer the former):
> > 
> >   !=dev-python/paramiko-1.13.0
> 
> This is a blocker syntax, so it's used already.

OK thanks. And I ignored that fact in one of my other mails. So I guess 
this ends up in: Never mind ;)



-- 
0x35A64134 - 8AAC 5F46 83B4 DB70 8317
 3723 296C 6CCA 35A6 4134


signature.asc
Description: Digital signature

[gentoo-dev] <>-DEPENDS

[Marc Schiffbauer]

Hi,


I'd like to propose a new kind of DEPEND syntax: <>

This would mean "Any version but the one specified" and is usefull when 
you have a dependency on another package but a single version of it is 
not compatible for example.

I currently have this case in app-backup/obnam which is not compatible 
to =dev-python/paramiko-1.13.0

In DEPEND I now have this:

  !=dev-python/paramiko-1.13.0
  || ( dev-python/paramiko-1.13.0 )

which does the trick, but I think much more straight forward would be:

  <>dev-python/paramiko-1.13.0

which would be the exact opposite of =dev-python/paramiko-1.13.0

An alternate syntax would be (but I'd prefer the former):

  !=dev-python/paramiko-1.13.0

What do you think and would is the proper way to suggest this for a new 
EAPI?  A new bug? On what?

TIA
-Marc

-- 
0x35A64134 - 8AAC 5F46 83B4 DB70 8317
 3723 296C 6CCA 35A6 4134


signature.asc
Description: Digital signature

Re: [gentoo-core] [gentoo-dev] Git Migration: go-live!

[Marc Schiffbauer]

* Michael Weber schrieb am 09.08.15 um 11:00 Uhr:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512
 
 On 08/09/2015 07:36 AM, Robin H. Johnson wrote:
  I'm only 90% sure that everything works, but I've spent almost the 
  entire day on it, and there's more to go tomorrow.
 Thanks a lot!
 
 use case: my cvs tree had uncommitted ebuild work (yes, you caught me
 actually doing something).
 now `cvs diff` no longer works, how can i track down my local changes?
 besides diffing against git tree, brain memory aka shell history and
 find -newer?

I'd say: 

- tar your *.ebuild and files/* stuff away
- then git clone the new git repo.
- untar your files in the new git repo
- use git diff


-Marc


-- 
0x35A64134 - 8AAC 5F46 83B4 DB70 8317
 3723 296C 6CCA 35A6 4134


signature.asc
Description: Digital signature

Re: [gentoo-dev] emerge --binpkg-changed-deps

[Marc Schiffbauer]

* Zac Medico schrieb am 05.08.15 um 00:04 Uhr:

On 08/04/2015 01:16 PM, Marc Schiffbauer wrote:

hi all,

i find it a bit hard to understand how --binpkg-changed-deps is supposed
to work and what implications it has. Moreover I think the man page is
not very clear about what it does:

--binpkg-changed-deps [ y | n ]
   Tells emerge to ignore binary packages for which thecorresponding
ebuild dependencies have changed since thepackages were built.  In
order to help avoid issues withresolving  inconsistent
dependencies,  this  option  is automatically enabled unless the
--usepkgonly option is enabled. Behavior with respect to changed
build-time dependencies iscontrolled by the --with-bdeps option.


This looks a bit confusing to me. Am I alone with that?

If I understand that option right, maybe this text is better?

--binpkg-changed-deps [ y | n ]
   When enabled tells emerge to ignore a binary package and do a
source build instead if the corresponding ebuild runtimedependencies
(RDEPEND) have changed in the portage tree sincethe package was built.


It doesn't necessarily imply a source build, since you can have multiple
binary packages available. 


I see. So this might be better:

When enabled tells emerge to ignore a binary package if the 
corresponding ebuild runtime dependencies (RDEPEND) have changed in 
the portage tree since the package was built.




With FEATURES=binpkg-multi-instance, you can
have multiple local binary packages of the same package version in
PKGDIR. Even without FEATURES=binpkg-multi-instance, you can also have
multiple binary packages of the same package version coming from
multiple binhosts.


I had hoped for a feature like that and did not realize its already 
there, great! But thats another story..






   To help avoid issues with resolving inconsistent dependenciesthis
option is enabled by default unless using source builds isdisabled
by the --usepkgonly option.


Adding using source builds is disabled would be a valid way to clarify
the meaning of --usepkgonly.


Yes, I think this will improve the description.




   If the --with-bdeps option is also enabled, changed build-time
dependencies (DEPEND) will be considered instead.


Not instead, but in addition to.


If the --with-bdeps option is also enabled, changed build-time
dependencies (DEPEND) will also be considered.

-Marc

--
0x35A64134 - 8AAC 5F46 83B4 DB70 8317
3723 296C 6CCA 35A6 4134


signature.asc
Description: Digital signature

[gentoo-dev] emerge --binpkg-changed-deps

[Marc Schiffbauer]

hi all,

i find it a bit hard to understand how --binpkg-changed-deps is 
supposed to work and what implications it has. Moreover I think the 
man page is not very clear about what it does:


--binpkg-changed-deps [ y | n ]
   Tells emerge to ignore binary packages for which the 
   corresponding ebuild dependencies have changed since the 
   packages were built.  In order to help avoid issues with 
   resolving  inconsistent  dependencies,  this  option  is  
   automatically enabled unless the --usepkgonly option is enabled.  
   Behavior with respect to changed build-time dependencies is 
   controlled by the --with-bdeps option.



This looks a bit confusing to me. Am I alone with that?

If I understand that option right, maybe this text is better?

--binpkg-changed-deps [ y | n ]
   When enabled tells emerge to ignore a binary package and do a 
   source build instead if the corresponding ebuild runtime 
   dependencies (RDEPEND) have changed in the portage tree since 
   the package was built.


   To help avoid issues with resolving inconsistent dependencies 
   this option is enabled by default unless using source builds is 
   disabled by the --usepkgonly option.


   If the --with-bdeps option is also enabled, changed build-time 
   dependencies (DEPEND) will be considered instead.


(Am not 100% sure whether the last sentence is technically correct)

What do you think?

-Marc

--
0x35A64134 - 8AAC 5F46 83B4 DB70 8317
3723 296C 6CCA 35A6 4134

Re: [gentoo-dev] News item review: SquashDelta syncing support

[Marc Schiffbauer]

* Michał Górny schrieb am 17.05.15 um 05:47 Uhr:

Dnia 2015-05-16, o godz. 20:38:36
Michael Orlitzky m...@gentoo.org napisał(a):


On 05/16/2015 06:01 PM, Michał Górny wrote:

 We have gentoo-announce@g.o and gentoo-user@g.o too!

 That's gentoo-dev-announce. 'dev' is the key part. And gentoo-user@ is
 doubtedly used by sysadmins.


This one:

https://archives.gentoo.org/gentoo-announce/


First time I hear about it. Looks to be used primarily for GLSAs.
I wonder if anyone actually uses it.


We use it to watch GLSA announcements.

-Marc

--
0x35A64134 - 8AAC 5F46 83B4 DB70 8317
3723 296C 6CCA 35A6 4134


signature.asc
Description: Digital signature

Re: [gentoo-dev] more packages up for grabs

[Marc Schiffbauer]

* Tim Harder schrieb am 18.05.15 um 23:13 Uhr:

Here are some packages that I've dropped (or will drop) myself as
primary maintainer from. Many of them (e.g. protobuf*) could really use
some more collaborative non-maintainer update method but no one has
gotten around to finalizing, documenting, and implementing the required
metadata.xml changes yet as far as I know.

Anyway, here's the package list (somewhat incomplete because some were
dropped months ago and might also have new maintainers already but I
doubt they'd mind extra help):

* net-dns/ldns
* net-dns/ldns-utils
* net-dns/unbound (has proxy maintainer who's mostly absent atm)



I will add myself to these three packages


-Marc


--
0x35A64134 - 8AAC 5F46 83B4 DB70 8317
3723 296C 6CCA 35A6 4134


signature.asc
Description: Digital signature

Re: [gentoo-dev] dev.gentoo.org outage resolved and postmortem report up

[Marc Schiffbauer]

* Robin H. Johnson schrieb am 07.05.15 um 09:47 Uhr:

Details on the wiki:
https://wiki.gentoo.org/wiki/Project:Infrastructure/Incident_Reports/2015-05-07_woodpecker
First rough draft, I'm going to bed now.


Thanks for you work and the great report.

I think the PAX error is a known issue. At least there were known 
issues resulting in detected refcount overflows.


I did not check the changelog, but using a later grsec/pax pacthset 
might help.


As a sidenote: I'd prefer going with LTS kernel 3.14 as this is 
declared LTS by both GKH for the kernel and spender/pipacs for 
grsec/pax patchset.


-Marc

--
0x35A64134 - 8AAC 5F46 83B4 DB70 8317
3723 296C 6CCA 35A6 4134


signature.asc
Description: Digital signature

Re: [gentoo-dev] Should Gentoo do https by default?

[Marc Schiffbauer]

TL;DR: Yes!

* Hanno Böck schrieb am 27.03.15 um 15:33 Uhr:

Hi,

Right now a number of Gentoo webpages are by default served over http.
There is a growing trend to push more webpages to default to https,
mostly pushed by google. I think this is a good thing and I think
Gentoo should follow.

Right now we seem to have a mix:
* A number of webpages default to http and have optional https
 (www.gentoo.org)
* Some with sensitive logins are already https by default (e.g.
 bugs.gentoo.org), but they don't use hsts, which they should
* Some with logins are mixed http/login-via-https, which makes them
 vulnerable to ssl-stripping-attacks (e.g. wiki.gentoo.org)

I'd propose the following:
* Make all pages under .gentoo.org https by default
* Make sure all use modern HTTPS features, including:
* OCSP Stapling
* HSTS
* A secure collection of cipher suites


- bettercrypro.org


* (one may add HPKP here, but it requires careful planning and has the
  potential to lock people out of the page if done wrong)
(On the long term I think it would also be good to have downloads over
https, but I'm aware that this is more difficult as it involves mirror
operators that are not under direct control of gentoo infrastructure.)


+1



As I know these discussions, I'll already answer to some
counter-arguments that may come up:

It's not neccessary to do https on pages without logins
These kinds of arguments show a fundamental misunderstanding of what
https does. It guarantees confidentiality *and* integrity. In short, it
protects content not only from observation, but also from manipulation,
which is always a good thing. A very practical example is that on some
networks foreign ads get injected into other peoples webpages.


ack



Makes things slower / servers can't handle it
The performance costs for TLS on a server are often vastly overstatet.
The performance hit on servers doing https is very close to zero, it
just doesn't matter much.
There are some latency problems for connections, but these can mostly
be wiped out by a sane configuration of the server. If http/2 is used
one can even improve the performance with https.


And often a too slow /dev/random is the cuplrit which can be fixed 
by using haveged.




Certificates are too expensive
Gentoo already has certs for all pages, so this is not an argument
here, but if this ever becomes an issue there are a number of CAs these
days that issue free certs. In summer the community based CA Let's
encrypt will start which will be another option.


Or CAs which offer a Cert Flatrate for a small fee per year like 
StartSSL.com




CAs are bad and the whole system is broken
Partly true, but it doesn't get any better if people stick to HTTP.
Many problems of the CA system can be mitigated by modern technologies
like Key Pinning and Certificate Transparency.

I think defaulting the net to HTTPS is a big step for more security and
I think Gentoo should join the trend here.


... DNSSEC with TLSA records comes to my mind


--
0x35A64134 - 8AAC 5F46 83B4 DB70 8317
3723 296C 6CCA 35A6 4134


signature.asc
Description: Digital signature

Re: [gentoo-dev] Review: Apache AddHandler news item

[Marc Schiffbauer]

* Sebastian Pipping schrieb am 26.03.15 um 19:15 Uhr:

  As of the momment, affected packages include:

^
Typo


--
0x35A64134 - 8AAC 5F46 83B4 DB70 8317
3723 296C 6CCA 35A6 4134


signature.asc
Description: Digital signature

Re: [gentoo-dev] Naming of repositories: gento-x86 edition, bike shedding wanted

[Marc Schiffbauer]

* Andreas K. Huettel schrieb am 14.03.15 um 23:34 Uhr:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

imho,


Questions:
0. What names for the tree/repository.


gentoo
(it's also the repo_name)


+1

My furst idea, too.






--
0x35A64134 - 8AAC 5F46 83B4 DB70 8317
3723 296C 6CCA 35A6 4134


signature.asc
Description: Digital signature

Re: [gentoo-dev] [news item review] bash-completion-2.1-r90, version 2

[Marc Schiffbauer]

* Michał Górny schrieb am 10.11.14 um 22:18 Uhr:

Hello, developers.

I'm planning to commit this news item before =2.1-r90 goes stable.
I have rewritten the message to be more user-oriented like Rich
suggested (big thanks to you!) and added a paragraph about loading
bashcomp in bashrc.

Please review.


Looks good to me, but to remove stale symlinks you need to add the 
-L option to find. Or write just symlinks, because like this it 
will remove *all* symlinks.




$ find /etc/bash_completion.d -type l -delete



-Marc

--
0x35A64134 - 8AAC 5F46 83B4 DB70 8317
3723 296C 6CCA 35A6 4134


signature.asc
Description: Digital signature

Re: [gentoo-dev] [news item review] bash-completion-2.1-r90, version 2

[Marc Schiffbauer]

* Michał Górny schrieb am 11.11.14 um 12:06 Uhr:

Dnia 2014-11-11, o godz. 09:53:58
Marc Schiffbauer msch...@gentoo.org napisał(a):


* Michał Górny schrieb am 10.11.14 um 22:18 Uhr:
Hello, developers.

I'm planning to commit this news item before =2.1-r90 goes stable.
I have rewritten the message to be more user-oriented like Rich
suggested (big thanks to you!) and added a paragraph about loading
bashcomp in bashrc.

Please review.

Looks good to me, but to remove stale symlinks you need to add the
-L option to find. Or write just symlinks, because like this it
will remove *all* symlinks.


Is the attached version more clear?


Yes, I think so.


--
0x35A64134 - 8AAC 5F46 83B4 DB70 8317
3723 296C 6CCA 35A6 4134


signature.asc
Description: Digital signature

Re: [gentoo-dev] Packages up for grab

[Marc Schiffbauer]

* Christian Ruppert schrieb am 22.02.14 um 14:57 Uhr:

Hi,

I don't use the listed packages anymore so feel free to take those:

net-analyzer/mk-livestatus
net-misc/igmpproxy
x11-misc/tint2
x11-misc/tintwizard
net-misc/cfengine - I'll just keep maintaining Cfengine 2.x for now since
we/Infra still use it.


I will take cfengine, since we use it a lot.

-Marc

--
0x35A64134 - 8AAC 5F46 83B4 DB70 8317
3723 296C 6CCA 35A6 4134


signature.asc
Description: Digital signature

Re: [gentoo-dev] sci-geosciences/googleearth is orphan and needs a dedicated maintainer

[Marc Schiffbauer]

* Mike Gilbert schrieb am 30.01.14 um 23:02 Uhr:

On Thu, Jan 30, 2014 at 4:36 PM, Pacho Ramos pa...@gentoo.org wrote:

El jue, 30-01-2014 a las 13:47 +0100, Marc Schiffbauer escribió:

* Pacho Ramos schrieb am 29.01.14 um 07:58 Uhr:
Currently, there is no really working version of it in the tree:
https://bugs.gentoo.org/show_bug.cgi?id=494624

But due its bumps and current bugs, this needs a maintainer...
otherwise, I would treeclean it (the problem is that looks like some
people use it, but without none of them willing to maintain it, it will
be difficult to handle :( )



I would help taking care of it, as I use it sometimes.

How oftes does this need to be bumped?




I am not sure :(, I am not too familiar with it since it never worked ok
on my machines



I do a lot of version bumping on google-chrome, and I have a script
that automates the process for me. If anyone is interested in
maintaining googleearth in a similar manner, you might find my script
useful.

http://dev.gentoo.org/~floppym/chrome-bump



Thanks, I will have a look!

--
0x35A64134 - 8AAC 5F46 83B4 DB70 8317
3723 296C 6CCA 35A6 4134


signature.asc
Description: Digital signature

Re: [gentoo-dev] sci-geosciences/googleearth is orphan and needs a dedicated maintainer

[Marc Schiffbauer]

* Tom Wijsman schrieb am 31.01.14 um 00:52 Uhr:

On Thu, 30 Jan 2014 13:47:27 +0100
Marc Schiffbauer msch...@gentoo.org wrote:


* Pacho Ramos schrieb am 29.01.14 um 07:58 Uhr:
Currently, there is no really working version of it in the tree:
https://bugs.gentoo.org/show_bug.cgi?id=494624

But due its bumps and current bugs, this needs a maintainer...
otherwise, I would treeclean it (the problem is that looks like some
people use it, but without none of them willing to maintain it, it
will be difficult to handle :( )



I would help taking care of it, as I use it sometimes.

How oftes does this need to be bumped?


Check the ChangeLog (`grep '^*' ChangeLog`):

   *googleearth-7.1.1.1888 (18 Aug 2013)
   *googleearth-7.1.1.1871 (01 Jul 2013)
   *googleearth-7.1.1.1580 (19 May 2013)
   *googleearth-7.0.3.8542 (02 Mar 2013)
   *googleearth-7.0.2.8415-r2 (10 Feb 2013)
   *googleearth-7.0.2.8415-r1 (04 Feb 2013)
   *googleearth-7.0.2.8415 (02 Feb 2013)
   *googleearth-6.2.2.6613 (05 May 2012)
   *googleearth-6.2.1.6014-r1 (02 Mar 2012)
   *googleearth-6.2.1.6014 (01 Mar 2012)
   *googleearth-6.0.3.2197 (24 May 2011)
   *googleearth-6.0.2.2074 (02 Apr 2011)
   *googleearth-6.0.1.2032_beta (31 Jan 2011)

Looks reasonable.

The tricky thing with this package (not sure whether it has improved
over the last year) is that there are bundled libraries; and depending
on how you handle (or don't handle) them, it can lead to breakages. Due
to a binary nature, this is often something you can't resolve yourself;
iotw, this means you'll need to check up with upstream to fix these.

Besides that, there is also RESTRICT=mirror; so, you are restricted
to providing the versions upstream provides (eg. in case you want to
mask newer versions until a bug is resolved).


Thanks for the info Tom.

I will subscribe myself to the package. Anybody else is invited to 
help me with it.


-Marc

--
0x35A64134 - 8AAC 5F46 83B4 DB70 8317
3723 296C 6CCA 35A6 4134


signature.asc
Description: Digital signature

Re: [gentoo-dev] sci-geosciences/googleearth is orphan and needs a dedicated maintainer

[Marc Schiffbauer]

* Pacho Ramos schrieb am 29.01.14 um 07:58 Uhr:

Currently, there is no really working version of it in the tree:
https://bugs.gentoo.org/show_bug.cgi?id=494624

But due its bumps and current bugs, this needs a maintainer...
otherwise, I would treeclean it (the problem is that looks like some
people use it, but without none of them willing to maintain it, it will
be difficult to handle :( )




I would help taking care of it, as I use it sometimes.

How oftes does this need to be bumped?


--
0x35A64134 - 8AAC 5F46 83B4 DB70 8317
3723 296C 6CCA 35A6 4134


signature.asc
Description: Digital signature

Re: [gentoo-dev] renaming gentoo-oldnet

[Marc Schiffbauer]

Am Mittwoch, 7. August 2013, 12:00:57 schrieb William Hubbs:
 On Tue, Aug 06, 2013 at 11:26:16AM -0500, William Hubbs wrote:
  On Mon, Aug 05, 2013 at 10:09:54PM +, Robin H. Johnson wrote:
   I'm replying the start of this thread, rather than picking a single
   person to respond to. I DO want more brainstorming on ideas for the
   naming of the package, and I think people need to cast a wider net for
   naming ideas.
  
  Robin, I would like the decision to be made soon. I need to release
  OpenRc-0.12 in the next day or so, and if I do not have the answer I
  will have to do the split in OpenRc-0.13.
  
  I thought of a name based on your last suggestion and a comment on the
  list. Instead of networkrc, maybe netifrc (network interface rc).
  
  So, my choices, in no particular order, would be, netifrc, networkrc or,
  if neither of those fly, keep gentoo-oldnet.
 
 All,
 
 Robin hasn't responded, so my choice for this is netifrc (network
 interface rc). Someone made a comment about rc implying old school,
 RC means run control. I'm not sure an implication of old school is a
 big concern.

Ich think it was me who was telling that. What I meant was that old school 
configuration file names are often called somethingrc which may imply that 
netifrc might be a configiration file for a tool called netif.

-Marc
-- 
0x35A64134 - 8AAC 5F46 83B4 DB70 8317  3723 296C 6CCA 35A6 4134

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

Re: [gentoo-dev] renaming gentoo-oldnet

[Marc Schiffbauer]

Am Dienstag, 6. August 2013, 11:26:16 schrieb William Hubbs:
 On Mon, Aug 05, 2013 at 10:09:54PM +, Robin H. Johnson wrote:
  I'm replying the start of this thread, rather than picking a single
  person to respond to. I DO want more brainstorming on ideas for the
  naming of the package, and I think people need to cast a wider net for
  naming ideas.
 
 Robin, I would like the decision to be made soon. I need to release
 OpenRc-0.12 in the next day or so, and if I do not have the answer I
 will have to do the split in OpenRc-0.13.
 
 I thought of a name based on your last suggestion and a comment on the
 list. Instead of networkrc, maybe netifrc (network interface rc).
 
 So, my choices, in no particular order, would be, netifrc, networkrc or,
 if neither of those fly, keep gentoo-oldnet.
 
 If we change away from gentoo-oldnet, we will need to open an
 infrastructure bug to change the name of the overlay, the bugzilla
 account and the component in bugzilla before we can take bugs for the
 new package.
 
 Thoughts anyone?

My 2¢:

* Keep a simple but straight forward and technical name
* Do not use *rc as this implies an oldschool configuration filename

Some more suggestions:

* openrc-net (if it is coupled to openrc)
* rcnet
* gentoo-networking
* gentoo-netconf
* netconf

Or maybe

* larry-net ;-)

-Marc
-- 
0x35A64134 - 8AAC 5F46 83B4 DB70 8317  3723 296C 6CCA 35A6 4134

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

Re: [gentoo-dev] Moving our/portage stuff to var

[Marc Schiffbauer]

Am Dienstag, 18. Dezember 2012, 22:33:06 schrieb Diego Elio Pettenò:
 No /var/gentoo. No /var/repositories.

 /var/db/gentoo, /var/db/repositories, /var/cache/portage ... as long as Zac
 is fine with one whatever, but let's not invent any new top-level.

Why not? From a FHS pov it seems ok...

I would suggest /var/portage ...

-Marc
--
0x35A64134 - 8AAC 5F46 83B4 DB70 8317  3723 296C 6CCA 35A6 4134

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

Re: [gentoo-dev] Moving our/portage stuff to var

[Marc Schiffbauer]

Am Mittwoch, 19. Dezember 2012, 14:43:56 schrieb Ulrich Mueller:
  On Wed, 19 Dec 2012, Diego Elio Pettenò wrote:
  On 19/12/2012 13:44, Marc Schiffbauer wrote:
  I would suggest /var/portage ...
 
  Seriously, mine is going to be a huge veto here with as much power I
  can put.

 Why? The portage tree is of central importance for Gentoo, so IMHO a
 second-level directory would be acceptable for it. Besides, it
 currently is in /usr/portage, so it wouldn't be new but would only
 move from /usr to /var.

+1

FHS 2.3: Applications must generally not add directories to the top level of
/var. Such directories should only be added __if they have some system-wide
implication__, and in consultation with the FHS mailing list.

-Marc
--
0x35A64134 - 8AAC 5F46 83B4 DB70 8317  3723 296C 6CCA 35A6 4134

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

Re: [gentoo-dev] Moving our/portage stuff to var

[Marc Schiffbauer]

Am 19.12.2012 17:25, schrieb Diego Elio Pettenò:

On 19/12/2012 17:19, Marc Schiffbauer wrote:
FHS 2.3: Applications must generally not add directories to the top 
level of
/var. Such directories should only be added __if they have some 
system-wide

implication__, and in consultation with the FHS mailing list.


Since you like adding emphasis:

FHS 2.3: Applications must generally not add directories to the top
level of /var. Such directories should only be added if they have some
system-wide implication, *and in consultation with the FHS mailing 
list.*


It's always nice to cherry-pick half a phrase from a standard, right?


No. That would be the next step. But I do not see any problem here. Do 
you?


--
8AAC 5F46 83B4 DB70 8317  3723 296C 6CCA 35A6 4134

Re: [gentoo-dev] Moving our/portage stuff to var

[Marc Schiffbauer]

Am Montag, 17. Dezember 2012, 11:23:00 schrieb Diego Elio Pettenò:
 On 17/12/2012 11:19, Tomáš Chvátal wrote:
  I've always myself override these defaults in make.conf to point for
  /var/portage/ (not /var/lib because I never bothered enough how to
  make world and config files to be put elsewhere :P).

 I would say let's work on that so that portage can keep them there.
 Although I'm more for /var/cache/portage myself, as both distfiles and
 tree can be re-generated.

What about setups where portage tree is mounted via NFS to reduce traffic and
disk space?

FHS states[1] that /var/cache is *locally* generated. Which aould not be the
case for such setups...

I prefer /var as well, but I am not such if /var/cache would be the right
place...


[1]
From FHS 2.3:
/var/cache is intended for cached data from applications. Such data is
locally generated as a result of time-consuming I/O or calculation.

-Marc
--
0x35A64134 - 8AAC 5F46 83B4 DB70 8317  3723 296C 6CCA 35A6 4134

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

Re: [gentoo-dev] Moving our/portage stuff to var

[Marc Schiffbauer]

Am Montag, 17. Dezember 2012, 15:56:11 schrieb Diego Elio Pettenò:
 On 17/12/2012 15:49, Marc Schiffbauer wrote:
  What about setups where portage tree is mounted via NFS to reduce traffic
  and disk space?

 Since nothing in Gentoo and/or other distributions _enforces_ FHS,
 you're allowed to do as you prefer

  FHS states[1] that /var/cache is *locally* generated. Which aould not be
  the case for such setups...

 Again, you can do as you prefer. Do you wish to violate FHS to just keep
 in the usual place? You can. You want to move it somewhere else to
 adhere to FHS? You can.

  I prefer /var as well, but I am not such if /var/cache would be the right
  place...

 Any other suggestions on where to place it? And please don't say
 /var/lib because that would usually be backed up.

FHS also states:

[...] Other portions may be shared [between systems], notably /var/mail,
/var/cache/man, /var/cache/fonts, and /var/spool/news.

So I think this might indeed be interpreted like that /var/cache/portage would
be perfectly ok.

Another place I could imagine is /var/portage because of its fundamental
importance in gentoo.

FHS about that: Applications must generally not add directories to the top
level of /var. Such directories should only be added if they have some system-
wide implication, and in consultation with the FHS mailing list.

I think this would also be ok because portage can be counted as system-wide
implication ...

-Marc
--
0x35A64134 - 8AAC 5F46 83B4 DB70 8317  3723 296C 6CCA 35A6 4134

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

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-fs/udev: udev-187-r1.ebuild udev-9999.ebuild ChangeLog

[Marc Schiffbauer]

Am Samstag, 4. August 2012, 10:31:05 schrieb Samuli Suominen:
  +   if [ -d ${ROOT}/lib/udev ]

 If you don't use double [[ then ${ROOT} will need  quoting

This was only true if ${ROOT} stood there on its own. IMO if you have
${ROOT}/foo you do not need  quoting because even if $ROOT is empty you will 
not get a syntaxt error.

-Marc
-- 
0x35A64134 - 8AAC 5F46 83B4 DB70 8317  3723 296C 6CCA 35A6 4134

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

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-fs/udev: udev-187-r1.ebuild udev-9999.ebuild ChangeLog

[Marc Schiffbauer]

Am Montag, 6. August 2012, 01:25:44 schrieb Peter Stuge:
 Marc Schiffbauer wrote:
+   if [ -d ${ROOT}/lib/udev ]
   
   If you don't use double [[ then ${ROOT} will need  quoting
  
  This was only true if ${ROOT} stood there on its own. IMO if you have
  ${ROOT}/foo you do not need  quoting because even if $ROOT is empty
  you will not get a syntaxt error.
 
 I think you will run into trouble if it contains whitespace.

Indeed. Convinced.

-Marc
-- 
0x35A64134 - 8AAC 5F46 83B4 DB70 8317  3723 296C 6CCA 35A6 4134

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

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Marc Schiffbauer]

Am Mittwoch, 23. Mai 2012, 18:33:41 schrieb Michał Górny:
 On Wed, 23 May 2012 14:42:37 +0200

 Michael Weber x...@gentoo.org wrote:
  *if you still read this* *wow*
 
  Please discuss my arguments and come to the conclusions to
  RESO/WONT-FIX testing git-cvsserver, make a clean cut and remove
  this bug from the blockers of [TRACKER] portage migration to git.

 Kill it! And while we're at it, kill ChangeLogs as well!

 /me hides...

with git log some-cat/foo we will have it automagically.

--
0x35A64134 - 8AAC 5F46 83B4 DB70 8317  3723 296C 6CCA 35A6 4134

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

Re: [gentoo-dev] rfc: location of portage tree

[Marc Schiffbauer]

* Aaron W. Swenson schrieb am 27.03.12 um 21:59 Uhr:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256
 
 On 03/27/2012 03:47 PM, Alec Warner wrote:
  On Tue, Mar 27, 2012 at 12:40 PM, William Hubbs
  willi...@gentoo.org wrote:
  On Wed, Mar 28, 2012 at 08:25:58AM +1300, Kent Fredric wrote:
  On 28 March 2012 08:05, William Hubbs willi...@gentoo.org
  wrote: /var/cache/repositories/gentoo/* 
  /var/cache/repositories/perl-experimental/* 
  /var/cache/distfiles/* /var/cache/packages/*
  
  These sub directories are all portage related, so it is best to
  put them under /var/cache/portage. Look in /var/cache on your
  system; most of the directories in there (at least on my system)
  are named for the program that uses them.
  
  The gentoo-x86 ebuild tree is not necessarily portage related. 
  However I think we should paint the bike shed '/srv/tree'
  
  -A
 
 /var/cache/{ebuilds,distfiles,eclasses,profiles}
 
 Or we can just call it Portage.
 
 We call it the Portage tree, just like we call it gentoo-x86 but
 that isn't what it only contains, in several places, both in official
 docs and unofficial docs, tweets, pins, notes, stickies
 
 /var/cache/portage is my vote.

+1

I like the idea of one directory because I wthink lots of people do
have that stuff in a dedicated filesystem which today is mounted on
/usr/portage. It would only have to be mounted to /var/cache/portage
and this people were done with migration.

Having several directories will make it much harder to make the
portage stuff be in its own fs. (be it several fs or symlinks ...)

-Marc
-- 
0x35A64134 - 8AAC 5F46 83B4 DB70 8317  3723 296C 6CCA 35A6 4134


pgp7KtZ1GGkBh.pgp
Description: PGP signature

Re: [gentoo-dev] RFC: License problem

[Marc Schiffbauer]

* Justin schrieb am 21.03.12 um 16:14 Uhr:
 On 21.03.2012 15:48, Ian Stakenvicius wrote:
  On 21/03/12 10:34 AM, Richard Yao wrote:
  On 03/21/12 10:18, Justin wrote:
  I will not extract part of the software, e.g. subroutines, for
  use in other contexts without permission of the author.
  
  Portage could be considered to be one of these contexts.
  
  
  If the entire package is installed (ie, it's not broken up into
  separate libraries or sub-packages) this would be fine (ie having the
  package in portage), wouldn't it?
  
  I guess the primary restriction here would be that nothing else would
  be allowed to link against any embedded libraries; ie, the package
  couldn't be a dep.
  
 
 It simply creates one binary which I am interested in. I don't see any
 problem if I use fetch restriction. The only remaining question would be
 the actual LICENSE?

How about asking the authors? Maybe they are fine with mirroring too
if updates they publish will be mirrored too.

If you get the permission to do it, it might be fine.

-Marc
Disclaimer: IANAL

-- 
0x35A64134 - 8AAC 5F46 83B4 DB70 8317  3723 296C 6CCA 35A6 4134


pgpojGSSDhbuW.pgp
Description: PGP signature

Re: [gentoo-dev] Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]

[Marc Schiffbauer]

Am Montag, 12. März 2012, 21:22:26 schrieb Joshua Kinard:
[...]
 After all, /usr was originally for user data, not system data,
 until someone cooked up /home (I don't know the full exact history here, so
 feel free to correct me).

IIRC usr = unified system resources (not an abbrev. for user)

-Marc
--
0x35A64134 - 8AAC 5F46 83B4 DB70 8317  3723 296C 6CCA 35A6 4134

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

Re: [gentoo-dev] Re: newsitem: unmasking udev-181

[Marc Schiffbauer]

On Sunday 11 March 2012 21:08:47 Robin H. Johnson wrote:
 On Sun, Mar 11, 2012 at 12:49:11AM -0600, Ryan Hill wrote:
  On Sat, 10 Mar 2012 20:27:06 -0600
  
  William Hubbs willi...@gentoo.org wrote:
   An initramfs which does this is created by =sys-kernel/genkernel-3.4.25
   or
   
   =sys-kernel/dracut-017-r1. If you do not want to use these tools, be
   
   sure any initramfs you create pre-mounts /usr.
  
  We should really have some documentation on how to create a minimal
  initramfs that mounts /usr (if we don't already, I haven't looked).  I've
  never needed one until now and don't have the foggiest idea how it's
  done.  I can't be the only one.
 
 The quickest initramfs, assuming that ALL kernel modules you need to
 boot are already compiled into your kernel:
 genkernel --install --no-ramdisk-modules initramfs

But this will not mount /usr. At least it did not for me.
To make it work you have to 

# echo /usr  /etc/initramfs.mounts

and recreate the ramdisk (genkernel ramdisk)

I had to look into the code for that as this seems not to be documented 
anywhere.

-Marc


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

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Marc Schiffbauer]

* Zac Medico schrieb am 08.03.12 um 17:30 Uhr:
 On 03/08/2012 01:42 AM, Marc Schiffbauer wrote:
  * Ulrich Mueller schrieb am 08.03.12 um 08:27 Uhr:
  Such constructs also cannot be used with any of the other proposed
  solutions. And in fact, nobody is using such things in practice.
  _All_ ebuilds in the Portage tree can be successfully parsed with the
  regexp proposed.
 
  Ebuilds are bash scripts. I think introducing exceptions or
  constraints here is not straightforward.
 
 Given that ebuilds already have to conform to a vast number of 
 constraints that ordinary bash scripts do not. I think that it's 
 perfectly reasonable for ebuilds to have a constrained syntax for EAPI 
 assignments.

There are constraints in ebuilds, right. But its an *ebuild* in the
end, not an ordinary shell script. Thats true.

So if EAPI is very special, and I am now convinced it is, then well, 
this might be the most important contraint in an ebuild at all.

If that is true I would vote to keep this as simple as possible:

* EAPI *must* *be* the first non-Argument / shell code in an ebuild
* The value of EAPI in the assignment *MUST* *NOT* contain any
  other variables or other shell substitutions.

Period. Done.

* That would be the least invasive change.
* Could easily be checked by repoman
* Is easy parsable by other programs (python code)

-Marc
-- 
8AAC 5F46 83B4 DB70 8317  3723 296C 6CCA 35A6 4134


pgpFVfsBDxzOc.pgp
Description: PGP signature

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Marc Schiffbauer]

* Ulrich Mueller schrieb am 08.03.12 um 08:27 Uhr:
  On Wed, 7 Mar 2012, Alec Warner wrote:
 
  *** Proposal 1: Parse the EAPI assignment statement ***
  [...]
 
  I don't like this idea because the sane way should be easy and
  straightforward. Mixing a constant declaration with bash assignment
  just confuses users who think the assignment is full bash when in
  fact it is not.
 
  EAPI=$(somefunc)
  EAPI=${SOMEVAR%%-*}
  and so forth all don't meet the regex (and would be flagged
  invalid.) However a naive author might think they work.
 
 Such constructs also cannot be used with any of the other proposed
 solutions. And in fact, nobody is using such things in practice.
 _All_ ebuilds in the Portage tree can be successfully parsed with the
 regexp proposed.

Ebuilds are bash scripts. I think introducing exceptions or
constraints here is not straightforward.

I think the only relevant part whether EAPI is set correctly or not
should be the outcome of $EAPI.

I would vote for a solution in a bash comment where repoman would
have to check for its existance and equality to $EAPI.

-Marc
-- 
8AAC 5F46 83B4 DB70 8317  3723 296C 6CCA 35A6 4134


pgpiOirLF4AWG.pgp
Description: PGP signature

Re: [gentoo-dev] Re: rfc: locations of binaries and separate /usr

[Marc Schiffbauer]

* Michał Górny schrieb am 05.01.12 um 09:26 Uhr:
 On Wed, 4 Jan 2012 19:30:07 +0100
 Marc Schiffbauer msch...@gentoo.org wrote:
 
  * Olivier Crête schrieb am 04.01.12 um 18:40 Uhr:
   On Wed, 2012-01-04 at 15:54 +, Ciaran McCreesh wrote:
On Wed, 4 Jan 2012 16:51:12 +0100
Michał Górny mgo...@gentoo.org wrote:
 /bin/systemctl
   libdbus-1.so.3 = /usr/lib64/libdbus-1.so.3

Here is a prime example of why vertical integration should
really be called a horrible mess of tight coupling...
   
   You clearly have failed to realize that d-bus is a now the bus for
   system messaging and is as much part of the system as syslog or
   bash. Probably even more so, for example, in Fedora 17, you'll be
   able to boot without syslog or bash, but you need d-bus.
  
  IMO a system should *always* be bootable without that high level
  stuff. And by bootable I mean that you can get a root prompt at
  least.
 
 And why do you consider D-Bus being high-level? Just because things
 used to reinvent the wheel before in a much worse fashion?

I meant hight-level only in a way that it is not really needed to
boot the very basic things of a system so that I can get a root
prompt at the console at least. E.g. you do not need dbus to find
and mount the rootfs, fire a getty and shell.

-Marc
-- 
8AAC 5F46 83B4 DB70 8317  3723 296C 6CCA 35A6 4134


pgp25u9OqPf4y.pgp
Description: PGP signature

Re: [gentoo-dev] rfc: locations of binaries and separate /usr

[Marc Schiffbauer]

* Olivier Crête schrieb am 04.01.12 um 18:32 Uhr:
 On Wed, 2012-01-04 at 18:12 +0100, Ulrich Mueller wrote:
   On Wed, 4 Jan 2012, Michał Górny wrote:
  
   What mistakes?
  
   The mistake of introducing a pointless separation based on a rule of
   thumb which becomes more and more blurry over time, and hacking
   packages just to make it work.
  
  There's really nothing pointless or blurry about this separation.
  The FHS has a nice definition: The contents of the root filesystem
  must be adequate to boot, restore, recover, and/or repair the system.
 
 The problem is that to boot a modern system, you need a shitload of
 stuff. 

To boot the system on its highest level: yes. But Linux/UNIX systems
have a concept called runlevels that can perfectly cover cases where
this shitload of stuff is not required.

For example, to make that FHS definition be reality there are (can
be) runlevels that will only boot a system with all basic stuff
required to mount the rootfs and make root being able to login to
the local text console. These are the things that make a unixoid
system valuable over other kind of systems.

 For example, modern network filesystems often have secure
 authentication and probably LDAP too, so that means we need to move ldap
 and openssl into / and all the dependencies. Also, anything that
 installs a udev rule needs to be in /, and the list goes on an on. Very
 soon, you have almost everything in /...

You do not need everything to make a system boot some sort of
recovery-console for example.

 
 This rule made sense in the 80s, but it doesn't match the modern world
 anymore.

Why? The benefits to keep a system bootable and repairable is one of
the reasons why unix systems are more robust or can better be
repeaired than, lets say windows systems for example.

I do not like the idea to throw away all those benefits just because
so many (younger/newer) people do not know about the possibilities
an old fashioned unix system tends to have.

-Marc
-- 
8AAC 5F46 83B4 DB70 8317  3723 296C 6CCA 35A6 4134


pgpkTWMsEkKlm.pgp
Description: PGP signature

Re: [gentoo-dev] Re: rfc: locations of binaries and separate /usr

[Marc Schiffbauer]

* Olivier Crête schrieb am 04.01.12 um 18:40 Uhr:
 On Wed, 2012-01-04 at 15:54 +, Ciaran McCreesh wrote:
  On Wed, 4 Jan 2012 16:51:12 +0100
  Michał Górny mgo...@gentoo.org wrote:
   /bin/systemctl
 libdbus-1.so.3 = /usr/lib64/libdbus-1.so.3
  
  Here is a prime example of why vertical integration should really be
  called a horrible mess of tight coupling...
 
 You clearly have failed to realize that d-bus is a now the bus for
 system messaging and is as much part of the system as syslog or bash.
 Probably even more so, for example, in Fedora 17, you'll be able to boot
 without syslog or bash, but you need d-bus.

If this was true, we will soon have problems with linux systems that
windows had in 1995.

IMO a system should *always* be bootable without that high level
stuff. And by bootable I mean that you can get a root prompt at
least.

-Marc
-- 
8AAC 5F46 83B4 DB70 8317  3723 296C 6CCA 35A6 4134


pgpHP0cF1oZ61.pgp
Description: PGP signature

Re: [gentoo-dev] Re: rfc: locations of binaries and separate /usr

[Marc Schiffbauer]

* Olivier Crête schrieb am 04.01.12 um 19:53 Uhr:
 On Wed, 2012-01-04 at 19:30 +0100, Marc Schiffbauer wrote:
  * Olivier Crête schrieb am 04.01.12 um 18:40 Uhr:
   On Wed, 2012-01-04 at 15:54 +, Ciaran McCreesh wrote:
On Wed, 4 Jan 2012 16:51:12 +0100
Michał Górny mgo...@gentoo.org wrote:
 /bin/systemctl
   libdbus-1.so.3 = /usr/lib64/libdbus-1.so.3

Here is a prime example of why vertical integration should really be
called a horrible mess of tight coupling...
   
   You clearly have failed to realize that d-bus is a now the bus for
   system messaging and is as much part of the system as syslog or bash.
   Probably even more so, for example, in Fedora 17, you'll be able to boot
   without syslog or bash, but you need d-bus.
  
  If this was true, we will soon have problems with linux systems that
  windows had in 1995.
  
  IMO a system should *always* be bootable without that high level
  stuff. And by bootable I mean that you can get a root prompt at
  least.
 
 d-bus is not high-level stuff... For example, you can't use bluetooth
 without d-bus. Even Android has it..

And you need bluetooth to boot your stable datacenter server
systems?

 That said, in the new systemd world, bash is.. Since it's only a UI
 tools (just like gnome-shell for example). Since you don't need it to
 boot.

Yeah right. Having dbus for bluetooth is much more important than
having a shell.

Please remember that there are *way* more server systems running linux 
without any graphical desktop at all than desktop systems.

-Marc
-- 
8AAC 5F46 83B4 DB70 8317  3723 296C 6CCA 35A6 4134


pgpWXb157aI0g.pgp
Description: PGP signature

Re: [gentoo-dev] Re: rfc: locations of binaries and separate /usr

[Marc Schiffbauer]

* Olivier Crête schrieb am 04.01.12 um 22:55 Uhr:
 On Wed, 2012-01-04 at 21:45 +0100, Marc Schiffbauer wrote:
  
   That said, in the new systemd world, bash is.. Since it's only a
  UI
   tools (just like gnome-shell for example). Since you don't need it
  to
   boot.
  
  Yeah right. Having dbus for bluetooth is much more important than
  having a shell.
  
  Please remember that there are *way* more server systems running
  linux 
  without any graphical desktop at all than desktop systems. 
 
 Please remember that servers and desktops are dwarfed by the number of
 embedded systems running Linux. Probably more devices are sold running
 Linux in a single day than the total number of servers in the world...

Yes, but these do most propably never run some stock distro.

 But well, this isn't a number's game. D-Bus is the system bus and
 bluetooth is just one example of a system level component that uses it.

... which is not really required to boot a system.

-Marc
-- 
8AAC 5F46 83B4 DB70 8317  3723 296C 6CCA 35A6 4134


pgplq0ahIKQFg.pgp
Description: PGP signature

Re: [gentoo-dev] Packages up for grabs

[Marc Schiffbauer]

* Tomáš Chvátal schrieb am 11.11.11 um 12:38 Uhr:
 Hello guys,
 
 As my only Gentoo installation is libreoffice test virtual I am not
 able to really care about these.
 
 So these packages are up for grabs if anyone finds them interesting:

I will take this one:

 net-dns/opendnssec


-Marc
-- 
8AAC 5F46 83B4 DB70 8317  3723 296C 6CCA 35A6 4134


signature.asc
Description: Digital signature

Re: [gentoo-dev] Packages up for grabs

[Marc Schiffbauer]

* Tomáš Chvátal schrieb am 11.11.11 um 12:38 Uhr:
 Hello guys,
 
 As my only Gentoo installation is libreoffice test virtual I am not
 able to really care about these.
 
 So these packages are up for grabs if anyone finds them interesting:
 

and those two as well as opendnssec depends on them

 dev-libs/softhsm
 dev-ruby/dnsruby

-Marc
-- 
8AAC 5F46 83B4 DB70 8317  3723 296C 6CCA 35A6 4134


signature.asc
Description: Digital signature

Re: [gentoo-dev] Packages up for grabs due cbrannon retirement

[Marc Schiffbauer]

* Pacho Ramos schrieb am 13.09.11 um 21:24 Uhr:
 Due cbrannon retirement the following packages need a new maintainer:
 
 net-misc/telnet-bsd
 

I will take that one.

-Marc
-- 
8AAC 5F46 83B4 DB70 8317  3723 296C 6CCA 35A6 4134


pgpYVzqWJeeUl.pgp
Description: PGP signature

Re: [gentoo-dev] Autodep project

[Marc Schiffbauer]

* Александр Берсенев schrieb am 04.09.11 um 09:13 Uhr:
 Hi!

Hi Александр,

seems to be a nice tool.

I am not a native english speaker, but I found at least some words
that need to be fixed:

* There is no readed its always read
* And: writed - written

-Marc


 
 I am Alexander Bersenev, I was participating in GSoC this year.
 I want to present you the tool I've developed during this program. I
 hope that you'll find it useful.
 
 The purpose of my project is to help ebuild developers to compose
 accurate dependency list for a package.
 The tool has many features in order to do it, most of them listed on
 the documentation site: http://soc.dev.gentoo.org/~bay/autodep/
 
 The killer-feature is an emulating the file system without
 non-dependency packages installed. I call it dependency checking or
 strict emerging. If program builds successfully in this environment
 then check is passed. If no - check is failed and user likely will be
 having a bad experience while trying to build this package if he
 hasn't some packages installed.
 
 It works fine, I've reported a few dozens of bugs about missing
 dependencies here: https://bugs.gentoo.org/show_bug.cgi?id=autodep.
 
 How to install and use it:
 1) add neurogeek overlay in your overlay list
 2) emerge autodep
 3) use autodep and emerge_strict commands.
 
 I want to tell you more about emerge_strict command. This is an emerge
 command but with strict dependency checking. I've modified a portage
 and add this feature into it. Actually, after emerge autodep you
 will have two versions of portage: one is from your system(emerge) and
 one is from modified portage(emerge_strict).
 
 !!!ATTENTION!!!
 I modified a last available portage version from git. It is about
 Portage 2.2.0_alpha50. The you running portage 2.1.x.x it
 theoretically can be unsafe to use them both. I used it together for
 about a month and not found any problems, but, anyway, be careful.
 !!!ATTENTION!!!
 
 Here is an example of emerge_strict dev-libs/nss output:
 https://381591.bugs.gentoo.org/attachment.cgi?id=285369
 
 Missing dependency is founded here:
 sdb.c:58:21: fatal error: sqlite3.h: No such file or directory
 compilation terminated.
 
 
 [NOT IN DEPS] dev-db/sqlite-3.7.7.1                   : [u'compile']
  /usr/include/sqlite3.h                                   blocked
 
 
 I've set up a tinderbox to catch missing dependencies. And it works
 right now. Also, I recently installed desktop gentoo linux on my new
 notebook using only emerge_strict. It is also works.
 
 Although GSoC is over, I want to support this tool in further. I will
 be appreciate for any feedback.
 
 Best,
 
 Alexander Bersenev
 

-- 
8AAC 5F46 83B4 DB70 8317  3723 296C 6CCA 35A6 4134

Re: [gentoo-dev] /usr vs. initramfs redux

[Marc Schiffbauer]

* Samuli Suominen schrieb am 05.08.11 um 15:43 Uhr:
 On 08/05/2011 04:12 PM, Marc Schiffbauer wrote:
  OTOH the initrd that Robin described would be a very static solution
  with almost no dependencies, so if genkernel had a USE flag like
  dracut it would be possible to build it without dracut
  dependency and thus would allow for smaller systems.
  
 To clarify,
 
 By dependencies in dracut you mean udev? 

For example yes.

 And by smaller systems you mean
 systems without udev?

No.

 
 Then yes, such minimal initramfs should propably be covered in the
 embedded's documentation, but otherwise trying to avoid dracut is
 reinventing the wheel...

You may be right, but to my understanding such a minimalistic initrd
would really do nothing special. Possibly a small shell script run
in a static busybox would do the job, Given some required conditions
like having a normal boot device like /dev/sda is given this
thingy would just mount the rootfs, read some config,, then mount
other things like /usr and thats it. Not to forget pivot_root and
starting the real init of course.

Maybe something like:
pseudo shell mode
#!/bin/sh
mount -t proc proc /proc
rootfs=`sed 's/.*root=\([^ ]*\)/\$1` /proc/cmdline
mount $rootfs /newroot
while read device mnt fstype; do
  mount -t $fstype $device $mnt
done  /newroot/etc/initramfs.mount
cd /newroot
pivot_root . /oldroot
exec chroot . /sbin/init
# END


-Marc
-- 
8AAC 5F46 83B4 DB70 8317  3723 296C 6CCA 35A6 4134


pgpgrutzKyU1Q.pgp
Description: PGP signature

Re: [gentoo-dev] /usr vs. initramfs redux

[Marc Schiffbauer]

* Robin H. Johnson schrieb am 05.08.11 um 02:46 Uhr:
[...]
 That leaves the only reasonable solution as #2. In terms of minimal
 impact, I propose that we offer users with a static system an absolutely
 minimal initramfs, that _just_ mounts the required directories.  No
 modules, no LVM, no MD, no crypto etc - if you want that functionality,
 go and use genkernel or dracut. If your fstab contains a line like:
 /dev/sdXN /usr ...
 Then this initramfs is for you.
 
 The minimal initramfs would do the following.
 
 1. Mount devtmpfs/sysfs/procfs as needed to access devices.
 2. Mount real_root to /newroot
 3. Read /newroot/etc/initramfs.mount and /newroot/etc/fstab
 4.1. If /newroot/etc/initramfs.mount does not exist
  Assume it contains only: /usr /var
 5. Mount the combined items from said files
 6. pivot_root.
 

That sounds like a good compromise to me!

Another thing to consider:

/etc/init.d/localmount should check whats already mounted and leave
that out. But it will act as fallback if the minimal initramfs fails
to mount /usr or /var for any reason.

That way anybody migrating to that minitramfs will not risc an
unbootable system.

-Marc
-- 
8AAC 5F46 83B4 DB70 8317  3723 296C 6CCA 35A6 4134


pgpm0QBMwgCgh.pgp
Description: PGP signature

Re: [gentoo-dev] /usr vs. initramfs redux

[Marc Schiffbauer]

* Rich Freeman schrieb am 05.08.11 um 14:42 Uhr:
 On Fri, Aug 5, 2011 at 6:16 AM, Marc Schiffbauer msch...@gentoo.org wrote:
  * Robin H. Johnson schrieb am 05.08.11 um 02:46 Uhr:
  [...]
  That leaves the only reasonable solution as #2. In terms of minimal
  impact, I propose that we offer users with a static system an absolutely
  minimal initramfs, that _just_ mounts the required directories.  No
  modules, no LVM, no MD, no crypto etc - if you want that functionality,
  go and use genkernel or dracut. If your fstab contains a line like:
  /dev/sdXN /usr ...
  Then this initramfs is for you.
 
  The minimal initramfs would do the following.
 
  1. Mount devtmpfs/sysfs/procfs as needed to access devices.
  2. Mount real_root to /newroot
  3. Read /newroot/etc/initramfs.mount and /newroot/etc/fstab
  4.1. If /newroot/etc/initramfs.mount does not exist
       Assume it contains only: /usr /var
  5. Mount the combined items from said files
  6. pivot_root.
 
 
  That sounds like a good compromise to me!
 
 Why would we build yet another initramfs vs just making dracut work
 reliably?  You can already build dracut without support for
 lvm+raid+luks/etc.

If dracut will have some sort of minimalistic mode where it would
generate such an initrd that would be ok IMO.

OTOH the initrd that Robin described would be a very static solution
with almost no dependencies, so if genkernel had a USE flag like
dracut it would be possible to build it without dracut
dependency and thus would allow for smaller systems.

-Marc
-- 
8AAC 5F46 83B4 DB70 8317  3723 296C 6CCA 35A6 4134


pgpOneX3Jhj27.pgp
Description: PGP signature

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Marc Schiffbauer]

* Samuli Suominen schrieb am 01.08.11 um 09:23 Uhr:
 On 07/31/2011 05:23 PM, Michał Górny wrote:
  On Sat, 30 Jul 2011 16:55:23 +0300
  Samuli Suominen ssuomi...@gentoo.org wrote:
  
  I dislike the IUSE=+static some packages are currently doing to
  workaround this, instead of moving the needed shared libs to /
 
  I dislike the idea of pciutils and usbutils database(s) in
  non-standard location in / to keep udev working
 
  I dislike the idea of moving libglib-2.0, libdbus-1, libdbus-glib-1,
  and couple of dozen more libs to /
 
  I dislike the idea of maintaining and keeping track of the files in /
  using files from /usr. Does any of the PMs have check for this, like
  NEEDED entries? I can imagine this getting past the maintainers easily
  otherwise
 
  Most likely still not seeing the full picture here, and just
  scratching the surface...
  Despite that, I don't have any strong opinion on any of this, just
  need to know if I should start moving the files over
  
  Honestly, I'd rather see system libs and apps being moved to /usr
  rather than the opposite. IMO the benefit of getting a clear tree is
  greater than benefits of having separate fs for 'system' and
  'non-system' packages which actually tend to randomly depend one on
  another.
 
 that's my impression now too since nobody has managed to provide useful
 case for separate /usr, or they have been very vague like adding 1+1 on
 / and /usr filesystem sizes and counting the risk of corrupted
 filesystem from that (one word: backup)
 and even then they can go with dracut and have the initramfs mount the
 /usr before init
 dracut with it's externsive modules covers the other mentioned cases too


I always keep /usr seperate from / for isolation reasons.

IMO there are some good reasons to do so:

* For example if a filesystem fills 100%. Imagine your /usr is 100%
  full by accident.

  If you have a seperate / you always can still write to /etc or /root
  which might save your life.

  Sometimes a system might not even be bootable if / has no space
  left.

  Sure, this is not the case normally and never should be. But if it
  happens to you, you will be happy to have them seperated.

* IMO its a good idea to seperate mostly static filesystems from
  those with many writes 

* Some people want a read-only /usr

* /usr/portage can get very huge and is often written to. With
  / and /usr being on the same FS you really want to have
  /usr/portage on a seperate FS then

I am sure there are some other reasons too. 

Just my 2¢

-Marc
-- 
8AAC 5F46 83B4 DB70 8317  3723 296C 6CCA 35A6 4134


pgpkzxf10zmuN.pgp
Description: PGP signature

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Marc Schiffbauer]

* Jorge Manuel B. S. Vicetto schrieb am 01.08.11 um 11:19 Uhr:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256
 
 On 01-08-2011 08:31, Eray Aslan wrote:
  On 2011-08-01 10:23 AM, Samuli Suominen wrote:
  that's my impression now too since nobody has managed to provide
  useful case for separate /usr, or they have been very vague
  
  I will switch if I have to but saying / and /usr on the same
  filesystem is the better technical solution just annoys me.
  
  I understand if going against upstream and keeping them seperate is
  not worth the hassle and noone steps up to do it.  But then we should
  say so.  Please don't kid yourself (or others).
 
 I agree with Eray. Furthermore, please stop trying to reverse the
 game. It's those that want to break existing policies and conventions
 that have to justify why they want to do that, not those that want to
 keep using what has worked for years. You may not need or like it, but I
 want to be able to use partition schemes like the following without
 needing to use an initramfs:
 
 /dev/md4/boot
 /dev/md2/
 /dev/sda1   swap
 /dev/sdb1   swap
 
 /dev/vg/home/home
 /dev/vg/usr /usr
 /dev/vg/portage /usr/portage
 /dev/vg/distfiles   /usr/portage/distfiles
 /dev/vg/var /var
 /dev/vg/vtmp/var/tmp
 /dev/vg/www /var/www
 /dev/vg/repos   /home/repositories
 /dev/vg/release /home/release
 
 Also, desktop users that don't split the /usr path might not like the
 stress that /usr/portage will add to the / partition - not to talk
 about the size and inode constraints.
 
 With the above design, I have on a system the following disk space use:
 
 FilesystemSize  Used Avail Use% Mounted on
 rootfs9,4G  262M  8,7G   3% /
 
 I'm growing tired of how complex and over-designed desktop technologies
 that hide stuff from the users keep trying to break the unix way and
 convince us they're awesome. No, I don't need or want *kit, groups
 exist for something. No, applications that do magic stuff with dbus
 and xml (and I like xml) on the users back and hide how X work aren't a
 good thing(tm).
 
 Finally, Gentoo's init system is and will likely be for a long time
 openrc, so stop trying to push crazy or experimental init systems - most
 with a seemingly poor design and unable to do what an init system
 needs to do (start and stop services).


I fully agree with you here!

I always considered systems with just one big / as badly designed.

It's simply not the unix way. Sure it makes some things easier in the
first place. But that does not mean that it is a better technical
solution.

-Marc
-- 
8AAC 5F46 83B4 DB70 8317  3723 296C 6CCA 35A6 4134


pgprJi4jLKHcH.pgp
Description: PGP signature

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Marc Schiffbauer]

* Pacho Ramos schrieb am 01.08.11 um 13:19 Uhr:
 El lun, 01-08-2011 a las 13:12 +0200, Marc Schiffbauer escribió:
 [...]
  * /usr/portage can get very huge and is often written to. With
/ and /usr being on the same FS you really want to have
/usr/portage on a seperate FS then
  
  I am sure there are some other reasons too. 
  
  Just my 2¢
  
  -Marc
 
 Having /usr/portage on a different partition will still be supported if
 I understood correctly (at least, it still works fine for me even having
 the rest of /usr under / partition)

yes. My point was, that if you have a separate /usr you may be ok
with no seperate /usr/portage

-Marc
-- 
8AAC 5F46 83B4 DB70 8317  3723 296C 6CCA 35A6 4134


pgpj9onqzaKEv.pgp
Description: PGP signature

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Marc Schiffbauer]

* Kacper Kowalik schrieb am 01.08.11 um 13:32 Uhr:
 
 I'm responding to this particular mail cause it's last in queue and
 because it replicates things already mentioned before.
 
 I am a zeleous follower of having seperate /usr partition, thus seeing
 moot arguments that goes in favour of my case is pretty annoying.
 
  * For example if a filesystem fills 100%. Imagine your /usr is 100%
full by accident.
 Thats bs, cause / can fill out even when you have /usr seperate. Even
 faster cause usually you've got very small / like 1Gb. You miss one
 thing that accidentally writes to / and you're as much toasted.
 

The point is that /usr/* has much more load and changes than /
alone. ANd a full /usr is much more common than a full / if it is
seperated.

  * IMO its a good idea to seperate mostly static filesystems from
those with many writes 
 How mering / and /usr increase that? What prevents you having separate
 partition for heavy write areas inside /usr ?

Nothing prevents me. But just having /usr seperat is much easier to
maintain.

And well, the FHS clearly allows a sepearte /usr. Everything that is
required to boot belongs to / until other filesystems get mounted.

 
  * Some people want a read-only /usr
 Yes, that's only reasonable argument here.
 
  * /usr/portage can get very huge and is often written to. With
/ and /usr being on the same FS you really want to have
/usr/portage on a seperate FS then
 Even with separate /usr it's good to have separate partition for
 /usr/portage. You can have partition with small blocks and large no. of
 inodes this way. How does that prevents merging / and /usr ?

I agree with you here. My point was that with a seperate /usr you
can go well without seperate /usr/portage where you cannot without.




-Marc
PS,OT: /usr/portage always seemed special to me.
Would'nt /var/lib/portage be a better place for it?
-- 
8AAC 5F46 83B4 DB70 8317  3723 296C 6CCA 35A6 4134


pgpt1PN13XRAO.pgp
Description: PGP signature

Re: [gentoo-dev] portage locations

[Marc Schiffbauer]

* William Hubbs schrieb am 01.08.11 um 19:49 Uhr:
 On Mon, Aug 01, 2011 at 07:22:15PM +0200, Francesco Riosa wrote:
  everything about portage is very specific and should be separated, I
  would like to see an addition of one root directory gentoo where
  ${PKGMANAGER} keep all it's stuff.
  Some of these are already moveable with ${*DIR} variables in
  make.conf, others are not
  
 I don't agree that we should create a gentoo root directory; however,
 to be technical, /usr/portage is wrong.

That was exactly my point in one of my mails in the /usr-Thread.

I disagree with introducing a non-FHS dir on the rootfs,

 
 I will list what My thoughts would be below your suggestions. Keep in
 mind that this is just being thrown out there without thinking about the
 details all that much.
 
  20K /gentoo/tmp
 
 Maybe /tmp?

Depends on which kind of tmp data this is. Should it survive a
system reboot? If yes /var/tmp is better.

I agree with the rest.

-Marc
-- 
8AAC 5F46 83B4 DB70 8317  3723 296C 6CCA 35A6 4134


pgprwsugoDw98.pgp
Description: PGP signature

Re: [gentoo-dev] RFC: leechcraft.eclass

[Marc Schiffbauer]

Am Freitag, 22. Juli 2011, 14:50:06 schrieb Maxim Koltsov:
 Hi devs,
 I'm about to add Leechcraft modular internet client to tree. It has 32
 packages and uses it's own eclass. Please review it and allow me to
 commit it to the tree.
 Also i'd want to ask: is it woth to add new category (e.g.
 leechcraft-plugins) to simplify managing leechcraft ebuilds. And the
 last question: is it good to add  versions for all ebuilds too?

IMO live ebuilds should only be held in an overlay.

-Marc

Re: [gentoo-dev] RFC: leechcraft.eclass

[Marc Schiffbauer]

* Alex Alexander schrieb am 22.07.11 um 13:30 Uhr:
 On Fri, Jul 22, 2011 at 14:21, Marc Schiffbauer msch...@gentoo.org wrote:
  Am Freitag, 22. Juli 2011, 14:50:06 schrieb Maxim Koltsov:
  Hi devs,
  I'm about to add Leechcraft modular internet client to tree. It has 32
  packages and uses it's own eclass. Please review it and allow me to
  commit it to the tree.
  Also i'd want to ask: is it woth to add new category (e.g.
  leechcraft-plugins) to simplify managing leechcraft ebuilds. And the
  last question: is it good to add  versions for all ebuilds too?
 
  IMO live ebuilds should only be held in an overlay.
 
  -Marc
 
  versions are nice, but they typically require more time and
 effort to maintain. I'd recommend adding them only if you are willing
 to do the work. Sometimes  ebuilds are useful as a way to prepare
 for the next release.

Yes, but the big drawback is that you do not have any checksums of
the source. So if for example an upstream source code gets exploited you 
will never notice until the trojan or whatever got in there will do
something. Sure this can happen with normal tarballs too,
but is much more unlikely and can only happen if the source is
already bad at the time of repoman manifest.

-Marc
-- 
8AAC 5F46 83B4 DB70 8317  3723 296C 6CCA 35A6 4134


pgpiMgjqTV4DQ.pgp
Description: PGP signature

Re: [gentoo-dev] validity of manifest signing key

[Marc Schiffbauer]

* Dane Smith schrieb am 25.03.11 um 12:35 Uhr:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On 03/25/2011 05:47 AM, Thomas Kahle wrote:
  Hi,
  
  it says here http://www.gentoo.org/doc/en/gnupg-user.xml#doc_chap2 that
  the validity should be 6 month.  What is the protocol when the expiry
  date is approaching?
  
  -) Extend expiry date and upload again?
  -) Create new key (and sign with ?? ) ?
  
  Cheers,
  Thomas
  
 
 Traditionally you start using your new key the day your old key expires.

Do you really mean a new key? This is not required. You can extend
the validity once you come close the expiry date (or do it after the
key has expired). 

-Marc
-- 
8AAC 5F46 83B4 DB70 8317  3723 296C 6CCA 35A6 4134


pgpdh6JJi913n.pgp
Description: PGP signature

Re: [gentoo-dev] Re: Removal of kdeprefix news item

[Marc Schiffbauer]

* Jonathan Callen schrieb am 19.05.11 um 11:49 Uhr:
 Ulrich Mueller wrote:
 
  On Wed, 18 May 2011, Jonathan Callen wrote:
  
  Display-If-Installed: kde-base/kdelibs[kdeprefix]
  
  I don't think that USE dependencies (or any other EAPI specific
  features) are allowed here.
 
 The GLEP does not make any meantion as to whether it is legal to use 
 USE dependencies here.  I have, however, tested with portage and 
 portage itself Does The Right Thing when faced with a USE dep in 
 Display-If-Installed.
 
  run: emerge --oneshot $(qlist -IC kde-base/)
  
  Is it guaranteed that your users have portage-utils installed?
  Otherwise the qlist command may not be available.
  
 
 I had thought that we depended on this, but I was mistaken (the 
 dependency was pulled in via pambase).  I guess we could just use 
 `emerge --update --deep --newuse @world` (and yes, @world is available 
 in stable portage).

test -x /usr/bin/qlist  emerge --oneshot $(qlist -IC kde-base/) \
|| emerge --update --deep --newuse @world

?

-Marc
-- 
8AAC 5F46 83B4 DB70 8317  3723 296C 6CCA 35A6 4134

Re: [gentoo-dev] rfc: use of the /run directory

[Marc Schiffbauer]

* Drake Wyrm schrieb am 18.05.11 um 00:26 Uhr:
 Nirbheek Chauhan nirbh...@gentoo.org wrote:
  2011/5/18 Olivier Cr??te tes...@gentoo.org:
   The main reason is that you want /run to be writable super early in the
   boot process, before even / has been fscked and re-mounted. That means
   you can do stuff like starting udevd in parallel with fsck of / which
   means faster boot. This is one of the things required to get 1 second
   boot.
  
   See http://lwn.net/Articles/436012/
  
  
  Related is that you don't need to manually wipe /tmp /var/run
  /var/lock via a service. They're automatically wiped when you reboot.
  This saves time during bootup.
 
 Even if you don't have to wipe them with a service, you're going to need
 to mount them with a service. You'll need to mount /run as tmpfs, create
 the /run/lock directory, and then mount /run/lock as tmpfs. Do you
 really want to add that to localmount?

Why mount /run/lock as tmpfs? If its created within /run its already
tmpfs

-Marc
-- 
8AAC 5F46 83B4 DB70 8317  3723 296C 6CCA 35A6 4134

Re: [gentoo-dev] git-2.eclass final review

[Marc Schiffbauer]

* Mike Frysinger schrieb am 23.03.11 um 00:08 Uhr:
 2011/3/22 Tomáš Chvátal:
  Dne 22.3.2011 22:26, Mike Frysinger napsal(a):
  # @BLURB: This eclass provides functions for fetch and unpack git 
  repositories
 
  fetching/unpacking
 
  Yarp fixed.
 
 well, the fix broke the blurb.  it has to be on one line.
 # @BLURB: foo
 
  EGIT_BRANCH=${x:-${EGIT_BRANCH:=${EGIT_MASTER}}}
  EGIT_COMMIT=${x:-${EGIT_COMMIT:=${EGIT_BRANCH}}}
 
 doesnt make much sense to use := ... it should be :-
 
  [[ $# -ne 1 ]]  die ${FUNCNAME}: requires 1 argument (path)
 
 quoting doesnt make much sense ... -ne compares an int, not a string

If using [[ you never need to quote anyway.

-Marc
-- 
8AAC 5F46 83B4 DB70 8317  3723 296C 6CCA 35A6 4134

Re: [gentoo-dev] KDE4 eclasses review

[Marc Schiffbauer]

* Tomáš Chvátal schrieb am 04.04.11 um 19:00 Uhr:
 Hi guys,
 since we didn't do this for quite long time I would like kde4 eclasses
 reviewed as whole rather than on patch basis (altho i attach the patches
 for convenience too).
 
 It is 2 years since we reviewed them last time fully on -dev so lets see
 how much weird/useless logic we can find (more heads know more).
 
 Remember: nitpick on everything cause this thing is used in quite a lot
 ebuilds so we need it in top-notch shape :)
 
 This update brings support for git since upstream is slowly moving to
 git repos from SVN. Dropped support for eapi2. Usage of fdo/gnome
 classes to update mime stuff. Most of the koffice code removed as being
 obsoleted and various loads of whitespace stuff.
 
 Cheers
 
 Tom

 # Copyright 1999-2010 Gentoo Foundation
 # Distributed under the terms of the GNU General Public License v2
 # $Header: $
 
 # @ECLASS: kde4-base.eclass
 # @MAINTAINER:
 # k...@gentoo.org
 # @BLURB: This eclass provides functions for kde 4.X ebuilds
 # @DESCRIPTION:
 # The kde4-base.eclass provides support for building KDE4 based ebuilds
 # and KDE4 applications.
 #
 # NOTE: KDE 4 ebuilds currently support EAPI 3.  This will be reviewed
 # over time as new EAPI versions are approved.
 
 # @ECLASS-VARIABLE: VIRTUALX_REQUIRED
 # @DESCRIPTION:
 # For proper description see virtualx.eclass manpage.
 # Here we redefine default value to be manual, if your package needs virtualx
 # for tests you should proceed with setting VIRTUALX_REQUIRED=test.
 : ${VIRTUALX_REQUIRED:=manual}

[...]

 
 KDE_MINIMAL=${KDE_MINIMAL:-4.4}

I'd suggest setting default for all variables the same way. I
personally like the : {X:=default} approach best.

: ${KDE_MINIMAL:=4.4} 

-Marc
-- 
8AAC 5F46 83B4 DB70 8317  3723 296C 6CCA 35A6 4134