[gentoo-dev] Call for Election Officials - 2024-25 Election Season
Team, The election wiki pages for the 2024-25 season have been created. They are not linked from anywhere yet. https://wiki.gentoo.org/wiki/Project:Elections/Council/202406 https://wiki.gentoo.org/wiki/Project:Elections/Trustees/202406 Notice that we are at least one official short of an election for both and an infra contact for the council election. If you will be around during June and the first few days of July (for the count), as long as you will not be candidates, elections would be pleased to hear from you. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods arm64 pgpmsfLFyAjJc.pgp Description: PGP signature
[gentoo-dev] Second Call for Election Officials - 2024-25 Election Season
Team, It looks like for the first time ever we will have two concurrent elections. On the bright side, it will make for a short election season. Suggested council election dates are Nominations open 01-Jun-24, Last meeting 09-Jun-24 (approx) Nominations close 15-Jun-24 Voting 17-Jun-24 to 01-Jul-24 Nobody has objected to those dates, so that's as good an endorsement as we will get. The trustees have already stated ... The trustees have determined that the recording date for the 2024 Trustee election will be 2024-06-01 00:00 UTC (June 1st). The 2024 Trustee election will tentatively use the following schedule, with 14 day periods for each of nominations and voting. Nominations open: 2024-06-01 00:00:00 UTC Nominations close: 2024-06-14 23:59:59 UTC (48 hour gap for election setup) Voting opens: 2024-06-17 00:00:00 UTC Voting closes: 2024-06-30 23:59:59 UTC Candidates cannot be officials. So far we have two volunteers, kangie and andrewammerlaan. Thank you both. We need two more and an infra contact as there are a few odds and ends that only infra can do. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods arm64 balsa-continue-T5SYN2 Description: PGP signature pgpEjFqZUqhbN.pgp Description: PGP signature
[gentoo-dev] Call for Election Offciials - 2024-25 Election Season
Team, We need some election officials for the Gentoo 2024-25 Election Season. The Council hold their last meeting in June, the new Foundation trustees take their seats at the AGM in August. Suggested council election dates are Nominations open 01-Jun-24, Last meeting 09-Jun-24 (approx) Nominations close 15-Jun-24 Voting 17-Jun-24 to 01-Jul-24 The council need not agree to those dates but its broadly in line with previous years. The new council could then meet on 07-Jul-24. The trustees dates are a bit more complex as the foundation needs to comply with NM statutes. The process starts with the trustees declaring a record date. Only members on record on that date can take part in the election. It ends with the newly elected trustees taking their seats at the AGM due in August. This year there is a complication. jmbsvicetto has retired and I'm expecting to be on devaway. The details of that are on the core ML. Officials may not be candidates. This sometimes leads to having different teams for different elections. 1. We need an -infra contact. Their remaining tasks are to harvest the votes when the election closes and add any email votes to the count. 2. A lead official to set up the election in the elections repo. https://cgit.gentoo.org/proj/elections.git/ The details are in https://cgit.gentoo.org/proj/elections.git/tree/ README.md There is also the incomplete https://wiki.gentoo.org/wiki/ User:NeddySeagoon/Election_Officials_HOWTO which is based on my experience at the school of hard knocks. 3. Create the 2024-25 Wiki pages https://wiki.gentoo.org/wiki/ Project:Elections for the elections team to maintain through the nomination period. 4. At least two other officials to count the votes. More than two is good.We have had officials become candidates and vanish at short/no notice before. 5. All officials need to be in #gentoo-elections and on the elections alias to respond to questions from the electorate. 6. Update topic in -dev with the turnout, post reminders to the electorate. Once we have a team, we can arrange a practice election. On behalf of the elections project. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods arm64 pgpsB7LcTb8aK.pgp Description: PGP signature
Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo
On 2024.04.06 12:57, Eddie Chapman wrote: > On 04/04/2024 15:24, Eddie Chapman wrote: > > Since there appears to be some interest I'll put together a single > email > > to the list later today detailing everything, as I needed to do more > > things overall in addition to replacing /usr/bin/xz. > > Below is a guide I've written to removing app-arch/xz-utils in case > anyone else wants to do so. Attached is the current version of the > Bash > wrapper script I now use in place of /usr/bin/xz > > Comments, corrections on anything technical in the guide or script are > > welcome, apart from flames about how this is ridiculous and > unnecessary :-). > > Best wishes, > Eddie > >[snip method] "Because I can" is a good enough reason to do anything with Gentoo. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods arm64 pgpwyJRBN8PRl.pgp Description: PGP signature
Re: [gentoo-dev] RFC: banning "AI"-backed (LLM/GPT/whatever) contributions to Gentoo
On 2024.02.27 14:45, Michał Górny wrote: > Hello, > > Given the recent spread of the "AI" bubble, I think we really need to > look into formally addressing the related concerns. In my opinion, > at this point the only reasonable course of action would be to safely > ban "AI"-backed contribution entirely. In other words, explicitly > forbid people from using ChatGPT, Bard, GitHub Copilot, and so on, to > create ebuilds, code, documentation, messages, bug reports and so on > for > use in Gentoo. > > Just to be clear, I'm talking about our "original" content. We can't > do > much about upstream projects using it. > > > Rationale: > > 1. Copyright concerns. At this point, the copyright situation around > generated content is still unclear. What's pretty clear is that > pretty > much all LLMs are trained on huge corpora of copyrighted material, and > all fancy "AI" companies don't give shit about copyright violations. > In particular, there's a good risk that these tools would yield stuff > we > can't legally use. > > 2. Quality concerns. LLMs are really great at generating plausibly > looking bullshit. I suppose they can provide good assistance if you > are > careful enough, but we can't really rely on all our contributors being > aware of the risks. > > 3. Ethical concerns. As pointed out above, the "AI" corporations > don't > give shit about copyright, and don't give shit about people. The AI > bubble is causing huge energy waste. It is giving a great excuse for > layoffs and increasing exploitation of IT workers. It is driving > enshittification of the Internet, it is empowering all kinds of spam > and scam. > > > Gentoo has always stood out as something different, something that > worked for people for whom mainstream distros were lacking. I think > adding "made by real people" to the list of our advantages would be > a good thing — but we need to have policies in place, to make sure > shit > doesn't flow in. > > Compare with the shitstorm at: > https://github.com/pkgxdev/pantry/issues/5358 > > -- > Best regards, > Michał Górny > > Michał, An excellent piece of prose setting out the rationale. I fully support it. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods arm64 pgp0BJ299ipp6.pgp Description: PGP signature
Re: [gentoo-dev] Registering media types for Gentoo files
On 2022.09.06 10:33, Michał Górny wrote: > Hi, everyone. > > Since we've been standardizing some things in Gentoo lately, I was > thinking we could try to get some media types registered with IANA. > > Particularly, I'm thinking of registering our Manifest format [1] as: > > text/vnd.gentoo.manifest > > and our new binary package container format [2] as: > > application/vnd.gentoo.gpkg > > However, the process is non-trivial and I'm not sure if the latter > really qualifies, given we're only specifying the container and not > the complete data format. To be honest, the specs are quite huge > and I'd really appreciate some help grasping all of this. > > Perhaps ebuilds and eclasses would also qualify for registration. > > WDYT? > > [1] https://www.gentoo.org/glep/glep-0074.html > [2] https://www.gentoo.org/glep/glep-0078.html > > -- > Best regards, > Michał Górny > > > Michał, > However, the process is non-trivial ... That's a down side. What are the benefits to Gentoo? -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods arm64 pgpBgVE0I6H9p.pgp Description: PGP signature
Re: [gentoo-dev] packages touching files in /dev
On 2022.05.24 12:58, Rich Freeman wrote: > On Tue, May 24, 2022 at 6:49 AM wrote: > > > > Is there some hook to emerge I can use where I can attach some code > to > > run tests after each individual package when doing emerge @world ? > > > > So, Portage has hooks, and that would work for any file being > installed normally (so would config protection and that would be a > much easier solution). > > There are a couple of problems though: > 1. The only package I'm aware of that directly touches /dev is > static-dev (which I hadn't even heard of until you mentioned it). It > uses a post-install hook to create device nodes, so there is no > opportunity to inspect anything before /dev is modified. This isn't > the normal way to install files, but of course it isn't installing > normal files. > 2. I think it is very unlikely that a package is directly modifying > /dev. It seems more likely that a package is installing some daemon > that gets run as root and then it modifies /dev, maybe on your next > boot. Obviously if you install something like udev you'd expect to > end up with /dev getting modified when it runs. Again, there is > nothing for a hook to detect. > > Having a backup (it is static after all), and something like a > read-only mount might be your better solutions, if you really want a > static dev, or maybe marking files as immutable or something. (You > might want to test that - I am assuming you could still write to a > device node on a read-only filesystem but it isn't like I've tried. I > don't think there is anything special about /dev so you could just > create a device node in some other read-only filesystem and test it > out.) > > If you do find a random package touching /dev I think most here would > be pretty interested, as that seems rather bizarre. > > -- > Rich > > Team, As a long time static /dev user the only thing I've noticed updates making a mess of is /dev/snd. I've not traced that, I know what it is and how to fix it. Its faster to fix it now and again that it is to establish the root cause. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods arm64 pgpw5Yv1QupXy.pgp Description: PGP signature
Re: [gentoo-dev] [PATCH] check-reqs.eclass: clamp MAKEOPTS for memory/RAM usage
On 2022.01.05 21:10, David Seifert wrote: > On Wed, 2022-01-05 at 21:06 +0000, Roy Bamford wrote: > > On 2022.01.05 20:22, Sam James wrote: > > > > > > > > > > On 5 Jan 2022, at 19:02, Roy Bamford > > > wrote: > > > > > > > > Sam, > > > > > > > > Do users with FEATURES=distcc still have to opt out of this > > > > MAKEOPTS clamping? > > > > > > > > > > Great point! I think we could add an exemption for that and make > it > > > a > > > noop or warning-only. > > > > > > Best, > > > sam > > > > > > > > > > > > Sam, > > > > You are building a better mousetrap here. That's not a reason to > try. > > > > Do users of I_KNOW_WHAT_I_AM_DOING, who have already > > opted to shoot themselves in both feet, get a free pass here? > > > > There are users who run emerge --jobs=X with MAKEOPTS='-jY" > > and get firefox, thunderbird and libreoffice all building > concurrently > > as they allow X * Y MAKE threads, reduced by this proposed > > throttling, still triggering the OOM. > > > > I don't think you can head that off beforehand. > > > > What's your proposed alternative? > > I don't really have one ... hence the better mousetrap analogy at the start of my post. grep -i killed on the build log, if portage can do that and tell the user the rules of thumb to try to stop it in future. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods arm64 pgpi7t5kmJD6n.pgp Description: PGP signature
Re: [gentoo-dev] [PATCH] check-reqs.eclass: clamp MAKEOPTS for memory/RAM usage
On 2022.01.05 20:22, Sam James wrote: > > > > On 5 Jan 2022, at 19:02, Roy Bamford > wrote: > > > > Sam, > > > > Do users with FEATURES=distcc still have to opt out of this > > MAKEOPTS clamping? > > > > Great point! I think we could add an exemption for that and make it a > noop or warning-only. > > Best, > sam > > Sam, You are building a better mousetrap here. That's not a reason to try. Do users of I_KNOW_WHAT_I_AM_DOING, who have already opted to shoot themselves in both feet, get a free pass here? There are users who run emerge --jobs=X with MAKEOPTS='-jY" and get firefox, thunderbird and libreoffice all building concurrently as they allow X * Y MAKE threads, reduced by this proposed throttling, still triggering the OOM. I don't think you can head that off beforehand. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods arm64 pgpcnTmqCeo2z.pgp Description: PGP signature
Re: [gentoo-dev] [PATCH] check-reqs.eclass: clamp MAKEOPTS for memory/RAM usage
On 2022.01.04 22:58, Sam James wrote:
> Crank down MAKEOPTS jobs if MAKEOPTS="-jN" is too high for the
> amount of RAM available (uses amount declared as needed
> in the ebuild). Typically should be ~2GB per job.
>
> Bug: https://bugs.gentoo.org/570534
> Signed-off-by: Sam James
> ---
> eclass/check-reqs.eclass | 42 +---
> 1 file changed, 39 insertions(+), 3 deletions(-)
>
> diff --git a/eclass/check-reqs.eclass b/eclass/check-reqs.eclass
> index 2130e2e349141..8c4adc8b4f121 100644
> --- a/eclass/check-reqs.eclass
> +++ b/eclass/check-reqs.eclass
> @@ -43,6 +43,8 @@ case ${EAPI} in
> *) die "${ECLASS}: EAPI=${EAPI:-0} is not supported" ;;
> esac
>
> +inherit multiprocessing
> +
> EXPORT_FUNCTIONS pkg_pretend pkg_setup
>
> if [[ ! ${_CHECK_REQS_ECLASS} ]]; then
> @@ -53,6 +55,13 @@ _CHECK_REQS_ECLASS=1
> # @DESCRIPTION:
> # How much RAM is needed? Eg.: CHECKREQS_MEMORY=15M
>
> +# @ECLASS-VARIABLE: CHECKREQS_MEMORY_MANGLE_JOBS
> +# @USER_VARIABLE
> +# @DESCRIPTION:
> +# Allow packages to reduce the number of multiprocessing (e.g. make,
> ninja) jobs
> +# to lower memory usage.
> +: ${CHECKREQS_MEMORY_MANGLE_JOBS=yes}
> +
> # @ECLASS-VARIABLE: CHECKREQS_DISK_BUILD
> # @DEFAULT_UNSET
> # @DESCRIPTION:
> @@ -346,9 +355,36 @@ _check-reqs_memory() {
> eend 0
> else
> eend 1
> - _check-reqs_unsatisfied \
> - ${size} \
> - "RAM"
> +
> + # Has the user allowed us to mangle their
> MAKEOPTS?
> + if [[ ${CHECKREQS_MEMORY_MANGLE_JOBS} ==
> "yes" ]] ; then
> + local jobs=$(makeopts_jobs)
> +
> + local
> estimated_max_memory=$((${actual_memory}/$(_check-reqs_get_kibibytes
> 1G)))
> + if [[ $((jobs*2)) -gt ${estimated_max_memory}
> ]] ; then
> + # Number of jobs exceeds RAM/2GB,
> so clamp it.
> + local
> new_jobs=$(($(_check-reqs_get_number
> ${estimated_max_memory}G)*10/20))
> +
> + # This might _still_ be too big
> on small machines. Give up in such cases.
> + # (Users can still set the do
> nothing variable which is independent of this.)
> + if [[ $((new_jobs*2)) -gt
> ${estimated_max_memory}
> ]] ; then
> + _check-reqs_unsatisfied \
> + ${size} \
> + "RAM"
> + else
> + # The clamped jobs seem to be
> enough to satisfy the check-reqs requirement from the ebuild.
> + ewarn "Clamping MAKEOPTS jobs
> to -j${new_jobs} to reduce memory usage"
> + ewarn "Compiler jobs may use
> around ~2GB each: https://wiki.gentoo.org/wiki/MAKEOPTS;
> + ewarn "To disable this, set
> CHECKREQS_MEMORY_MANGLE_JOBS=no."
> +
> + MAKEOPTS+=" -j${new_jobs}"
> + fi
> + fi
> + else
> + _check-reqs_unsatisfied \
> + ${size} \
> + "RAM"
> + fi
> fi
> else
> eend 1
> --
> 2.34.1
>
>
>
>
Sam,
Do users with FEATURES=distcc still have to opt out of this
MAKEOPTS clamping?
--
Regards,
Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
arm64
pgpBS7fAEMRjF.pgp
Description: PGP signature
Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.
On 2022.01.02 07:33, Sam James wrote: > [snip] > Note that having USE flags for things, even if forced on/masked (for > the opposite case) is useful for building embedded systems. So, if you > wanted to go this route, a sensible > first step would actually be forcing PAM on. But I don't think PAM is > a candidate for dropping. > > While I think it's hard to run a modern desktop system without it, > there are a fair number of people who do still run -pam and I don't > think > breaking it for the sake of it is a good idea. They already know there > be dragons. > > > > > Whats your view on it? > > I think I broadly agree, although PAM is a mildly controversial > example. > > I'd like to discuss specific examples of flags like USE=threads, > some-if-not-all instances of USE=ipv6, > And others which people raise if any others come up. > > Best, > sam > I'll stir the USE=-pam pot. A static busybox is a very good thing but that can only be achieved with USE=-pam. Sometimes it's the only way to pick up the pieces. In general, where USE=-foo makes the code size smaller I would be against dropping it. Think non Intel/AMD memory constrained systems. Gentoo is popular outside the desktop, so keep those users in mind too. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods arm64 pgpCLMlWhJelZ.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] Moving more architectures to ~arch only
On 2021.10.14 14:40, Marek Szuba wrote: > Dear everyone, > > Following some private discussions, I feel quite strongly now that it > would both considerably improve certain processes and make our use of > limited manpower more efficient were we to further reduce the number > of > stable arches in Gentoo Linux. Specifically, I propose to drop > - hppa, > - ppc, > - sparc, > - x86 > to ~arch-only status. > > Note that this does NOT mean we intend to drop support for those > arches > altogether. > > There are IMHO several good reasons for this: > - most of the arches from this list are quite dated and either > aren't > really developed upstream any more or got superseded by newer ones > (for > the record, it's been 18 years since the first amd64 CPUs came out) > - we have got very few people actually supporting these arches, and > in > case of hppa there is also the hardware bottleneck. Subsequently, > stabilisation requests often take a long time to resolve > - feedback we receive, e.g. by Bugzilla, suggests that Gentoo on at > least some of these arches have got very, very few users > - last but by no means least, my personal experience from the last > several years suggests that running ~arch is reasonably trouble-free > these days > > WDYT? > > -- > Marecki > > > Only x86 raised an eyebrow here but only one, and not very far. It has to come sooner or later, so if not now, then when? Datapoint: On the forums, x86 installs are either done by mistake or by users who know what they are doing on a 32 bit SoC, The first set of users will be helped, the second set know what they are doing. In case its not clear after all that waffle, I'll go with the flow. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods arm64 pgpu7gIwFkHei.pgp Description: PGP signature
Re: [gentoo-dev] Experimental binary package hosting
On 2021.09.21 18:22, Andreas K. Huettel wrote: > So let's experiment with this... :) announcing: > https://gentoo.osuosl.org/experimental/amd64/binpkg/default/linux/17.1/x86-64/ > > More information can be found in a blog post, which will also be on > planet.g.o > soon: > https://dilfridge.blogspot.com/2021/09/experimental-binary-gentoo-package.html > > Cheers -A > > -- > Andreas K. Hüttel > dilfri...@gentoo.org > Gentoo Linux developer > (council, qa, toolchain, base-system, perl, libreoffice) > Andreas, How is USE=bindist treated? Its on for stage building and off in profiles. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods arm64 pgp5qFocEumHc.pgp Description: PGP signature
[gentoo-dev] Election Officials Wanted
Ladies and Gentlemen The elections project is looking for two officials to conduct the count for the base-system project lead position. Nominations are already complete and the infra contact is setting up the election. Voting is expected to last seven days, starting soon, so if you will be around for the count and have shell access to Woodpecker you are qualified. Candidates in the election need not apply. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods arm64 pgp3adNZDH64p.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] Removing SHA512 hash from Manifests
On 2021.07.25 00:12, Thomas Deutschmann wrote: > Hi, > > I don't understand. Isn't it the same motion we put down just 2 months > > ago [1]? Or is this something new? > > If this isn't something new, what has changed since May [2]? > > To remember: Currently we have two different hashes for every > distfile. > If we are going to throw this data away, we should really have good > reasons to do that. Like said during that council meeting, BLAKE2B and > > SHA512 are competing hashes. What's wrong with having a backup plan > even > for a very unlikely scenario, that BLAKE2B will get broken? > > It's not like SHA512 is requiring any additional deps which are > unmaintained or something like that. SHA has even hardware > acceleration > support in modern systems. > > In addition it is even more likely that you will find SHA checksum > files > with upstream release tarballs than BLAKE2B files. > > Remember that verify-sig.eclass I criticized last year? Of course some > > scenarios I outlined were very unlikely and I never expected that I > can > run around in near future saying "I told you". But in January 2021, > CVE-2021-3345 happened in libgcrypt... > > So again: Why should we throw the data we currently have away and put > Gentoo unnecessarily at risk that we will end up without hashes > because > the only hash algorithm we used became broken and given that we will > be > unable to re-hash every file in a timely manner (remember how long it > took to get a BLAKE2B hash for every file)? > > > > See also: > = > [1] https://bugs.gentoo.org/784710 > > [2] https://projects.gentoo.org/council/meeting-logs/20210509.txt > > > -- > Regards, > Thomas Deutschmann / Gentoo Linux Developer > fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 > > I'm in the "if it's not broken don't fix it" school. The original proposal uses the word 'negligible' twice when describing the the benefits, which makes it sound like busywork. However, it's not me doing the work, so my opinion count for very little. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods arm64 pgp3G7Gf0Tace.pgp Description: PGP signature
Re: [gentoo-dev] My resignation from Gentoo
On 2021.07.18 05:37, Marco Scardovi wrote: > Hi everyone, > > while I'm writing these words I'm full of sadness because you all are > an > awesome family before being an incredible team. > It's been a while I've been thinking about that but actually I've > realized > Gentoo is just something where I spending and "trash" the biggest part > of > my time (not only free time but actually all my time) and I can't > continue > like that. > I don't know if I will come back again or not but actually I have to > take a > long pause for me and for people around me in my private life. > @sam, @juippis: if you mind I'll leave my PRs open on github, > otherwise > tell me here or on irc. I really want to thank you for your patience > (like > other people here :D). > > You are all awesome and I won't thank you enough for all the thing you > have done for me. > > /me hides. > > Marco Scardovi ( scardracs ) > > PS > > My resignation is for GURU, BGO and WIKI too: I will start today > adding m-n > to metadatas > Marco, Nobody ever leaves Gentoo, people just stray for a while. :) Its good that you recognise the signs of over doing it. Have a break. Have a very long break. I'm confident that Gentoo will be here when you decide to join in the fun again. Time permitting. My best wishes to you and and whatever you decide to do in the future. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods arm64 pgpKH46Xgqw84.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo 18th Anniversary Edition - Help Needed
On 20/04/2021 06:31, Robin H. Johnson wrote: Here's two I have so far https://dev.gentoo.org/~robbat2/neddy/ On Mon, Apr 19, 2021 at 10:24:41AM +0100, Roy Bamford wrote: Here's where I reed your help. The missing distfiles are MD5 38adc94a4953a6b29e8619c25dda4887 4.2.0-4.2.1.diff.gz 54763 MD5 d5cc6a93c7d3ad2eb02bc637a1de9cf3 net-tools-1.60-gentoo-extra.tar.bz2 5785 If your Gentoo history goes back as far as mine and you still have those files, please share them with me. I am reasonable certain that I have an archive with the others, but it's a media accessibility problem: they are stuck on either an LTO1 or LTO3 tape, and while I have an LTO drive that might work, I don't have a suitable external SAS controller on hand. It should probably be a project for me to media-shift those old backups onto cloud storage. Robin, Thank you. I have a similar media problem with a pile of 5 1/4" floppies. A have a drive that reads all the 5 1/4" formats and a motherboard to connect it to ... until I replace this 12 year old system. USB to Floppy interfaces won't do it as they are all made for the data rate used in 3 1/2" floppies. Maybe I'll just move this system along my desk and put it under my APPLE ][ :) -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods arm64
Re: [gentoo-dev] Gentoo 18th Anniversary Edition - Help Needed
On 19/04/2021 15:55, Benda Xu wrote: Roy, Roy Bamford writes: Its my 18th anniversary of installing Gentoo. A number of coincidences gave rise to my original liveCD turning up when I was searching for bits to get an old system to boot just one more time to get some forgotten data off its hard drives. I just had to try it out. Anyway, one thing lead to another and now I have a 2003 Gentoo install as a Virtualbox guest https://wiki.gentoo.org/wiki/User:NeddySeagoon/Historical_Gentoo all except 10 files. It boots, GNOME and KDE run, it won't play blurays but it has a few bits missing, so its not quite original. Here's where I reed your help. The missing distfiles are MD5 0d9151faa28fcbdff6b37559ce4895f5 kdegraphics-3.1.1a.diff.bz2 MD5 38adc94a4953a6b29e8619c25dda4887 4.2.0-4.2.1.diff.gz 54763 MD5 43e5e0209a9400b946f38d7c731c968c sis_drv_src_210303-1.tar.gz 378880 MD5 45133b34f10632f3ffc012401e2a4b19 util-linux-2.11y-crypt-gentoo.patch.gz 18843 MD5 4d84dd6a0f00d84850f2765766c6b780 kdebase-3.1.1a.diff.bz2 MD5 50891a2431cc829d98829e385e2c452c XFree86-4.2.1-patches-1.2.tar.bz2 405424 MD5 5687b1f9d7e0698f63c35c53322c786a kdelibs-3.1.1a.diff.bz2 MD5 6dc1978d748dc6519933743b0337f718 pam_login-3.10.tar.bz2 131130 MD5 aaeb8f8b276a6849f7a570097d69788e glide3-headers.tar.bz2 14564 MD5 d5cc6a93c7d3ad2eb02bc637a1de9cf3 net-tools-1.60-gentoo-extra.tar.bz2 5785 If your Gentoo history goes back as far as mine and you still have those files, please share them with me. I regret that I did not understand GNU/Linux back in 2003 to help you. This is indeed a cool project to celebrate your 18th anniversary of Gentoo ;) Please share some videos after you finish that. Benda Benda, It works now, its just not quite authentic. Follow the instructions in the wiki page I linked, or if you can't wait, there is a link to a root filesystem image for Virtualbox. I have hosted all the source files I have found, so go ahead and do a 2003 stage1 install. KDE is 3.1.1 not 3.1.1a pam_login is 3.11, not 3.10. net-tools-1.60-gentoo-extra.tar.bz2 I had to remake, based on the comments in the ebuild. The file size and md5sum don't match but I used 2021 tar to put the bits together. XFree is there, just not the version portage wanted to install. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods arm64
[gentoo-dev] Gentoo 18th Anniversary Edition - Help Needed
Team, Its my 18th anniversary of installing Gentoo. A number of coincidences gave rise to my original liveCD turning up when I was searching for bits to get an old system to boot just one more time to get some forgotten data off its hard drives. I just had to try it out. Anyway, one thing lead to another and now I have a 2003 Gentoo install as a Virtualbox guest https://wiki.gentoo.org/wiki/User:NeddySeagoon/Historical_Gentoo all except 10 files. It boots, GNOME and KDE run, it won't play blurays but it has a few bits missing, so its not quite original. Here's where I reed your help. The missing distfiles are MD5 0d9151faa28fcbdff6b37559ce4895f5 kdegraphics-3.1.1a.diff.bz2 MD5 38adc94a4953a6b29e8619c25dda4887 4.2.0-4.2.1.diff.gz 54763 MD5 43e5e0209a9400b946f38d7c731c968c sis_drv_src_210303-1.tar.gz 378880 MD5 45133b34f10632f3ffc012401e2a4b19 util-linux-2.11y-crypt-gentoo.patch.gz 18843 MD5 4d84dd6a0f00d84850f2765766c6b780 kdebase-3.1.1a.diff.bz2 MD5 50891a2431cc829d98829e385e2c452c XFree86-4.2.1-patches-1.2.tar.bz2 405424 MD5 5687b1f9d7e0698f63c35c53322c786a kdelibs-3.1.1a.diff.bz2 MD5 6dc1978d748dc6519933743b0337f718 pam_login-3.10.tar.bz2 131130 MD5 aaeb8f8b276a6849f7a570097d69788e glide3-headers.tar.bz2 14564 MD5 d5cc6a93c7d3ad2eb02bc637a1de9cf3 net-tools-1.60-gentoo-extra.tar.bz2 5785 If your Gentoo history goes back as far as mine and you still have those files, please share them with me. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods arm64 pgpm6HvoSTTjZ.pgp Description: PGP signature
Re: [gentoo-dev] rfc: switching default udev provider for new systems to udev
On 2020.08.10 16:22, William Hubbs wrote: > On Mon, Aug 10, 2020 at 12:00:44AM -0400, Joshua Kinard wrote: > > On 8/8/2020 14:51, William Hubbs wrote: > > > All, > > > > > > I would like to propose that we switch the default udev provider > on new > > > systems from eudev to udev. > > > > > > This is not a lastrites, and it will not affect current systems > since > > > they have to migrate manually. Also, this change can be overridden > at > > > the profile level if some profile needs eudev (the last time I > checked, > > > this applies to non-glibc configurations). > > > > > > What do people think? > > > > > > Thanks, > > > > > > William > > > > Is eudev broken in some way? If so, has a bug been filed? If not, > why not? > > > > If eudev is not broken, then why your proposed fix? > > bitrot and bus factor. > > > It works fine for new installs, having just done one myself. Seems > like we > > aught to keep it that way. I count six open bugs against eudev > right now, > > and none of them look to be critical, so I vote "no" on your > proposal unless > > there is some verifiable reason why eudev is no longer suitable to > be the > > default udev provider. > [snip] > ...because of fear of > what > the udev devs might do. That fear never came true. > [snip] > > William > William, Never is a very long time. That promise has not been made good ... yet. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods arm64 pgpshyF9TLPFs.pgp Description: PGP signature
Re: [gentoo-dev] rfc: switching default udev provider for new systems to udev
On 2020.08.08 23:22, Rich Freeman wrote: > On Sat, Aug 8, 2020 at 4:17 PM Roy Bamford > wrote: > > > > With the declared aim from upstream of making udev inseparable from > > systemd, its not something to be done lightly. > > That's the entire reason that eudev was necessary. > > > > I would want some convincing that it was not another step on the > road > > to Gentoo being assimilated by systemd. > > So, I really could care less what the default is since it won't impact > any of my Gentoo hosts either way, .. [snip] > > -- > Rich > Rich, I don't have a dog in this fight. Being old and cynical, I have static /dev, so I use neither. I'm interested in what's changed since the Council decision [1] to make eudev the default. [1] https://bugs.gentoo.org/573922#c28 -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods arm64 pgp8OZnGNadvH.pgp Description: PGP signature
Re: [gentoo-dev] rfc: switching default udev provider for new systems to udev
On 2020.08.08 19:51, William Hubbs wrote: > All, > > I would like to propose that we switch the default udev provider on > new > systems from eudev to udev. > > This is not a lastrites, and it will not affect current systems since > they have to migrate manually. Also, this change can be overridden at > the profile level if some profile needs eudev (the last time I > checked, > this applies to non-glibc configurations). > > What do people think? > > Thanks, > > William > > William, With the declared aim from upstream of making udev inseparable from systemd, its not something to be done lightly. That's the entire reason that eudev was necessary. I would want some convincing that it was not another step on the road to Gentoo being assimilated by systemd. We had this discussion several years ago when the default became eudev. What's changed? -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods arm64 pgpb6AvBiQ28_.pgp Description: PGP signature
Re: [gentoo-dev] */*: Mask Py2 only packages
On 2020.06.20 05:58, Aaron Bauman wrote: > > # Aaron Bauman (2020-06-20) > > # Py2 only > > # Removal in 14 days [list of stuff] > > -- > Cheers, > Aaron > Aaron, If everything that needs python2 is being removed, why not python2 itself? Al least, python2 is not on your list. Be first into the future by masking this stuff and Last out of the past by leaving up to users to decide. It could stay in the tree, masked, as long as python2. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods arm64 pgp9CIkLXPSD0.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo Foundations Trustee Election 2020 - Election Team Formation
On 2020.06.17 10:40, David Abbott wrote: > On Wed, Jun 17, 2020 at 5:08 AM Roy Bamford > wrote: > > > > Team, > > > > Its time to kick off the Trustee Election for this year. > > > > It will span June 21 to about August 3. > > We need two or three election officials and an infra contact to > staff this election. > > > > If you will be available and have a little free time in that period > recruiting is now open. > > Potential candidates should not apply. > > > > -- > > Regards, > > > > Roy Bamford > > (Neddyseagoon) a member of > > elections > > gentoo-ops > > forum-mods > > arm64 > > Hi Roy, > I can help out. > Regards, > > -- > David Abbott (dabbott) > > David, Thank you. I've signed you up at https://wiki.gentoo.org/wiki/Project:Elections/Trustees/202006 -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods arm64 pgpuDUKOvE2Vu.pgp Description: PGP signature
[gentoo-dev] Gentoo Foundations Trustee Election 2020 - Election Team Formation
Team, Its time to kick off the Trustee Election for this year. It will span June 21 to about August 3. We need two or three election officials and an infra contact to staff this election. If you will be available and have a little free time in that period recruiting is now open. Potential candidates should not apply. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods arm64 pgpzBD_87RDHL.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo Council Election 2020 - Call For Election Officials
On 2020.05.30 13:14, Rich Freeman wrote: > On Sat, May 30, 2020 at 6:09 AM Roy Bamford > wrote: > > > > We sill need more volunteers. > > > > Not going to be running, so I'm happy to pitch in. > > -- > Rich > > > Rich, Thank you. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods arm64 pgps3MQbFCaNk.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo Council Election 2020 - Call For Election Officials
On 2020.05.29 21:10, David Abbott wrote: > On Fri, May 29, 2020 at 4:03 PM Roy Bamford > wrote: > > > > Team, > > > > Our current council will hold their last meeting on 14-Jun-20. > > We therefore need to elect a new council before the July meeting. > > > > To do this, I'm calling for three volunteers to be election > officials and an > > infra member to be the infra contact. > > > ... [snip] > > > > -- > > Regards, > > > > Roy Bamford > > (Neddyseagoon) a member of > > elections > > gentoo-ops > > forum-mods > > arm64 > > Hi Roy, > Count me in. > Regards, > > -- > David Abbott (dabbott) > > David, Thank you. The election page is up now. https://wiki.gentoo.org/wiki/Project:Elections/Council/202006 We sill need more volunteers. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods arm64 pgpfHGn3U4xxH.pgp Description: PGP signature
[gentoo-dev] Gentoo Council Election 2020 - Call For Election Officials
Team, Our current council will hold their last meeting on 14-Jun-20. We therefore need to elect a new council before the July meeting. To do this, I'm calling for three volunteers to be election officials and an infra member to be the infra contact. The timeline, still exactly to be determined will span just over 4 weeks. Two weeks nominations, a few days for infra to set up the ballot on Woodpecker, two weeks for voting followed by a few days to check results. The timeline I have in mind is nominations open at midnight between 5/6 Jun. and close at midnight 19/20 Jun. Voting starts Midnight 22/23 June and runs until midnight 6/7 July. Results announced a few days later. Election officials monitor the project ML for nominations and update the election Wiki page to keep track of nominations, acceptances and manifestos. Once the votes are in, they rank the results and compare notes. They should also join #gentoo-elections on freenode. Please don't volunteer to support the election if you plan to run. Candidates may not be election officials. For completeness, only three election officials are required, so with myself, we will have a spare. That's good, every now and again, real life can intervene at the last moment. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods arm64 pgpQSMgQtzZQs.pgp Description: PGP signature
Re: [gentoo-dev] zoom concerns
On 2020.04.07 09:48, Ulrich Mueller wrote: > >>>>> On Tue, 07 Apr 2020, Samuel Bernardo wrote: > > > No assurance is also a level that takes place in the lower ranking > > level. If someone needs to use zoom because they are demanded by > their > > boss I think that would be even more useful to know that it is > possible > > to install zoom in Gentoo and that is rated as the worst possible > > software. Maybe this would allow others to join our zoom claim... > > We could add a README.gentoo file with our caveats. It won't be > perfect, > but maybe better than nothing. (And certainly better than displaying a > warning on every upgrade, which will eventually annoy people [1].) > > Any suggestions for a wording? > > Ulrich > > > [1] https://bugs.gentoo.org/416769 > Team, Just 'No.' Its not useful to anyone to single out a single binary only package for special treatment. Lets compare zoom to firefox-bin as a worked example. Nobody except Mozilla knows whats in firefox-bin. Gentoo doesn't build it, its the official Mozilla binary build. Mozilla distubute source code too. There is no assurace that they are the sources used to build firefox-bin. Over the years Firefox has had its share of CVEs. How is firefox-bin any different to zoom? I've only selected firefox-bin as a worked example. There are other binary packages in ::gentoo. In the same boat. They all need to be treated consistently. Then there is the question of the liability exposure. There are two prongs to this. a) any advice will be incomplete and or out of date. That will damage trust. b) one day, it will be plain wrong and zoom or whoever will get very upset and be able to prove it. Its OK to publish advice based on beliefs or opinions, there is no requirement for beliefs or opinions to be based on fact but we are not discussing beliefs or opinions here. In summary, we can't be sure of our facts. We can't be sure that any warning complete and correct. Gentoo must not single out any package for special treatment. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods arm64 pgpv44y3BnnyV.pgp Description: PGP signature
Re: [gentoo-dev] Vanilla sources
On 2020.01.04 13:43, Thomas Deutschmann wrote: > On 2020-01-04 14:08, Roy Bamford wrote: > > emerge -1 vanilla-sources > > eselect kernel ... > > genkernel all > > ... > > Please tell user to do > > genkernel --kernel-config=/proc/config.gz all > > by default which will give them a better experience because new kernel > will be build based on kernel configuration from current running > kernel. > Without providing a kernel config, user will probably fall back to > generic configuration which isn't intended for daily usage. > > > -- > Regards, > Thomas Deutschmann / Gentoo Linux Developer > C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 > > Thomas, Ten years ago the user did genkernel all and used the default .config provided with genkernel. Today, genkernel --kernel-config=/proc/config.gz all does not improve that config. genkernel --kernel-config=/proc/config.gz all perpetuates the existing .config which is only useful if its not an earlier generic configuration. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods arm64 pgpjhN8CA5bom.pgp Description: PGP signature
Re: [gentoo-dev] Vanilla sources
On 2020.01.04 12:54, Rich Freeman wrote: > On Sat, Jan 4, 2020 at 6:42 AM Roy Bamford > wrote: [snip] > > Apparently git and tar are too complicated for Gentoo users, but > managing symlinks, using make, managing a bootloader, dealing with the > kernel's configuration system, and so on are just fine? emerge -1 vanilla-sources eselect kernel ... genkernel all ... Yep, lots of users have trouble managing their boot loader. They come to the forums and IRC every day not running the kernel they think they are. That's not related to any particular kernel sources though. [snip] > > On a further aside, I just noticed how up-to-date gentoo-sources are. > Kudos to whoever is doing that these days - for a while it was tending > to slip a bit but it seems like we're basically current. +1 > > -- > Rich > > -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods arm64 pgpOaAY6RX0hb.pgp Description: PGP signature
Re: [gentoo-dev] Vanilla sources
On 2020.01.04 11:01, Rich Freeman wrote: > > Is there some reason that we should keep vanilla sources despite not > getting security handling? > > -- > Rich > Rich, Gentoo had this discussion before. The outcome was that vanilla-sources is just as Linus intended. If Gentoo did anything to it, it wouldn't be vanilla any longer. Yes, it should be kept. We should not force users to learn git or tar. I agree git or a tarball of vanilla-sources is faster and more efficient but that's not a reason to drop it. By the same argument we could drop linux-firmware too. There are probably other packages that only install whatever they fetch. Could they be dropped? -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods arm64 pgpNeBPcQXuuf.pgp Description: PGP signature
Re: [gentoo-dev] Need ARM/AArch64 test data for cpuid2cpuflags
On 2019.09.10 21:44, Michał Górny wrote: > Hi, everyone. > > I've recently (finally!) started adding tests to cpuid2cpuflags. > Tests > are based on mocked syscalls that return arch-specific data read from > text files. So far I've got x86 and ppc covered, and now I'd like to > add tests for various arm hardware. Since ARM covers a pretty broad > range of hardware, I'd use as much data as possible, especially from > different ARM generations. > > If you have an ARM board and would like to help, please: > > wget https://dev.gentoo.org/~mgorny/dist/cpuid2cpuflags-7-dev.tar.bz2 > tar -xf cpuid2cpuflags-7-dev.tar.bz2 > cd cpuid2cpuflags-7-dev > ./configure > make hwcap-dump > ./hwcap-dump > > and send me the output along with 'uname -m'. TIA! > > -- > Best regards, > Michał Górny > > Team, this is going to be a long rambling tale of woe. Sorry in advance. On arm64 cpuid2cpuflags-8 tells me Pi4_~arm64 /usr/portage # cpuid2cpuflags CPU_FLAGS_ARM: edsp neon thumb vfp vfpv3 vfpv4 vfp-d32 crc32 v4 v5 v6 v7 v8 thumb2 but by chance I hit [Bug 695854] net-misc/freerdp-2.0.0_rc4 on arm64 - aarch64-unknown-linux-gnu-gcc: error: unrecognized command line option ‘-mfpu=neon’ The 32 bit arm instruction set is optional on arm64. The 64 bit Raspberry Pis all have it The Cavium Thunder does not. It is unlikely that there will ever be a multilib arm64. Only a subset of arm64 could ever support it, so should we be using CPU_FLAGS_ARM to cover arm64 too? There is nothing in the name. Its the content that matters. On a Pi4 in 64 bit mode, cpuinfo shows Pi4_~arm64 /usr/portage # cat /proc/cpuinfo processor : 0 BogoMIPS: 108.00 Features: fp asimd evtstrm crc32 cpuid CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x0 CPU part: 0xd08 CPU revision: 3 In 32 bit mode, the same CPU shows $ cat pi4_32.txt processor : 0 model name : ARMv7 Processor rev 3 (v7l) BogoMIPS: 108.00 Features: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part: 0xd08 CPU revision: 3 Cavium (64 bit) arm64-build / # cat /proc/cpuinfo processor : 0 BogoMIPS: 200.00 Features: fp asimd evtstrm aes pmull sha1 sha2 crc32 CPU implementer : 0x43 CPU architecture: 8 CPU variant : 0x1 CPU part: 0x0a1 CPU revision: 1 The Cavium does not have any 32 bit instructions. From bug 695854, CPU_FLAGS_ARM: neon is not correct on the Cavium. I suspect that the other 32 bit flags will fail there, as it does not have them but they might work on the Pi, as it does. Other than pointing out the problem, I don't know how to test further. Guidance welcome. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods arm64 pgp5Xqz7kShdv.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] Mass last-riting of x86-but-not-amd64 packages
Hi Michał, On 2019.08.31 09:03, Michał Górny wrote: > Hello, > > We still have a lot of packages that are keyworded ~x86/x86 but were > never keyworded ~amd64. While I suppose there might be exceptions to > that, in most cases it means that simply nobody has been using it for > years. x86, the 32 bit variety, is still popular at the low power end of the spectrum for things like network appliances. Not the sort of hardware you would play many games on these days. Proceed with caution. Mask them and leave them in the tree. Wait and see who shouts, if anyone. Low power systems don't get updated terribly regularly, so be prepared to leave the packages in the tree for a lot longer than the customary 30 days. > > Many of them are still at EAPI 0; some were ported to newer EAPIs > specifically to clean old EAPIs. > > I've already cleaned up some false positives (like svgalib). If you > know more, please let me know. > > I have mixed feelings about games on the list. On one hand, it's > rather > obvious that they're x86 binary games. However, if somebody actually > used them, they would have probably gained amd64 multilib compat by > now. > > --- > [snip list] > > -- > Best regards, > Michał Górny > > -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods arm64 pgp66BNhk29KZ.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] New QA policy: Packages must not disable installing manpages via USE flags
On 2019.07.17 14:25, Michał Górny wrote: > Hello, > > The QA team would like to introduce the following policy: > > """ > Packages must not disable installing manpages via USE flags (e.g. > USE=man or USE=doc). If upstream does not ship prebuilt manpages > and building them requires additional dependencies, the maintainer > should build them and ship along with the package. > """ > > > Explanatory note: > > This applies to having USE flags that specifically control building > manpages. It obviously does not affect: > > a. USE flags that disable building both a program and its manpage > (e.g. > if USE=gui disables building gfrobnicate, not installing > gfrobnicate(1) > is correct), > > b. use of LINGUAS to control installed manpages. > > > Rationale: > > Manpages are the basic form of user documentation on Gentoo Linux. > Not > installing them is harmful to our users. On the other hand, requiring > additional dependencies is inconvenient. Therefore, packaging > prebuilt > manpages (whenever upstream doesn't do that already) is a good > compromise that provides user with documentation without additional > dependencies. > > > What are your comments? > > -- > Best regards, > Michał Górny > > Michał, This works on systems with plenty of resources. I suspect very few arm users have man/doc/info pages installed. FEATURES="noman nodoc noinfo" is less than ideal as everything is still built, so you pay the build time, but not installed. Does anyone read documentation on embedded class hardware? I know I don't. Personally, I don't build much on embedded hardware either but I'm aware of users that do. I like to have the choice to not build documentation on low power systems. Its a part of Gentoos flexibility that should not be removed. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods arm64 pgpsuZgzBJDUh.pgp Description: PGP signature
Re: [gentoo-dev] [News item review] amd64 17.1 profiles are now stable
On 2019.05.19 07:59, Michał Górny wrote: > Hi, > > As discussed during the Council meeting, I'm sending an updated news > item for 17.1 profile migration. This item will be published along > with > the profiles being marked stable, and the old one will be removed. > > Besides removing all references to the profiles being 'experimental', > I've reformatted and updated the text to be a little more clear about > the new design. > > --- > Title: amd64 17.1 profiles are now stable > Author: Michał Górny > Posted: 2019-05-xx > Revision: 1 > News-Item-Format: 2.0 > Display-If-Profile: default/linux/amd64/13.0 > Display-If-Profile: default/linux/amd64/13.0/selinux > Display-If-Profile: default/linux/amd64/13.0/desktop > Display-If-Profile: default/linux/amd64/13.0/desktop/gnome > Display-If-Profile: default/linux/amd64/13.0/desktop/gnome/systemd > Display-If-Profile: default/linux/amd64/13.0/desktop/plasma > Display-If-Profile: default/linux/amd64/13.0/desktop/plasma/systemd > Display-If-Profile: default/linux/amd64/13.0/developer > Display-If-Profile: default/linux/amd64/13.0/no-multilib > Display-If-Profile: default/linux/amd64/13.0/systemd > Display-If-Profile: default/linux/amd64/17.0 > Display-If-Profile: default/linux/amd64/17.0/selinux > Display-If-Profile: default/linux/amd64/17.0/hardened > Display-If-Profile: default/linux/amd64/17.0/hardened/selinux > Display-If-Profile: default/linux/amd64/17.0/desktop > Display-If-Profile: default/linux/amd64/17.0/desktop/gnome > Display-If-Profile: default/linux/amd64/17.0/desktop/gnome/systemd > Display-If-Profile: default/linux/amd64/17.0/desktop/plasma > Display-If-Profile: default/linux/amd64/17.0/desktop/plasma/systemd > Display-If-Profile: default/linux/amd64/17.0/developer > Display-If-Profile: default/linux/amd64/17.0/no-multilib > Display-If-Profile: default/linux/amd64/17.0/no-multilib/hardened > Display-If-Profile: default/linux/amd64/17.0/no-multilib/hardened/selinux > Display-If-Profile: default/linux/amd64/17.0/systemd > > A new set of 17.1 amd64 profiles has been added to the Gentoo > repository in Dec 2017. These profiles switch to a more standard > 'no SYMLINK_LIB' multilib layout, [snip] > > For more information on the layout, please see the wiki article > on AMD64 multilib layouts [2]. > > [1]:https://bugs.gentoo.org/506276 > [2]:https://wiki.gentoo.org/wiki/Project:AMD64/Multilib_layout > > -- > Best regards, > Michał Górny > > > > > Team, "These profiles switch to a more standard 'no SYMLINK_LIB' multilib" layout, Does that mean that no migration action is required by /no-multilib/ users? I notice that no-multilib users will get the news item. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods arm64 pgpuEgHshod8P.pgp Description: PGP signature
Re: [gentoo-dev] State of elogind integration and the default +elogind local USE flag on xorg-server.
On 2019.03.22 20:32, Piotr Karbowski wrote: > Hi, > [snip] > - We should go back to +suid -elogind default. > - We should actually NOT put suid on Xorg if USE="suid elogind" but > put > suid bit with USE="suid -elogind". > - We should only ever enable elogind in desktop profiles. > > Personally I'd like to stay without enabling suid by default on > xorg-server, as otherwise hardly anyone will ever drop the suid from > it, > which would be a big step back. Gentoo tried to drop suid from > xorg-server a handful of times, let's make the current one a final one > :) > > I'd like to propose doing the following: > > - Keywording elogind on missing archs > - Making elogind a global USE flag > - Switching desktop profiles to elogind from consolekit while still > preserving -suid +elogind on xorg-server for those that does not use > desktop profiles (systemd profiles users not affected) > - Making pambase always install the configuration for pam_elogind.so, > the same way it does for pam_gnome_keyring.so at this very moment, > effectively removing elogind USE flag from it. > > What do you all think about? > > -- Piotr. > This looks broken by default. [ebuild R] x11-base/xorg-server-1.20.4:0/1.20.4::gentoo USE="doc glamor ipv6 udev xorg xvfb -debug -dmx (-elogind) -kdrive -libressl -minimal (-selinux) -static-libs -suid* -systemd -unwind -wayland -xcsecurity -xephyr -xnest" elogind is hard masked and suid is being turned off. Its arm64, so I expect to find a few rough edges. However, changes like this need to be coordinated across all arches. Take a pat on the back for the elogind work and a slap on the wrist if my arm64 systems don't work any more. Its still building, I'll test later. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods pgp9X1hZnO3mp.pgp Description: PGP signature
Re: [gentoo-dev] [pre-GLEP r3] Gentoo binary package container format
On 2018.11.30 17:06, Michał Górny wrote: > On Mon, 2018-11-26 at 21:43 +0000, Roy Bamford wrote: > > On 2018.11.26 18:58, Michał Górny wrote: > > > Here's the newest version. > > > > > > Changes: > > > > > > - added explicit notion of parent directory (missing in previous > GLEP > > > but present in implementation), > > > > > > - explicitly named GNU tar format with list of permitted > extensions, > > > > > > - changed volume label to 'gpkg-1.txt' file to improve > portability; > > > made > > > it explicit version identifier as well, > > > > > > - added info on other package formats to rationale. > > > > > > > [snip] > > > > The image archive stores all the files to be installed by the binary > > package. It should be included as the last of the files in the > binary > > package container. > > > > [snip] > > > > > > -- > > > Best regards, > > > Michał Górny > > > > > > > Its a nit today but that says that any future extensions, none > > yet planned, should be placed before the image archive. > > Yes. > > > The specification needs to avoid the use of relative references. > > > > I don't understand. Could you be more specific what you expect > instead? > > -- > Best regards, > Michał Górny > Michał, Enumerate the elements, in the preferred order, which you have already done. The is no need, in a specification that is intended to be easily extensible to specify that any element should be last. That constrains extensions. To build on an example extension given earlier. Suppose an extension came along to add the ebuild, required eclasses and sources. The present wording says that they should be included before image archive. Implementations may be capable of working with partial downloads, why force the download of elements that may not be required to get the payload. The overhead of the presently define elements is small compared to the image and its useful to be able check the metadata to determine if the image is really what is required. image 'last' works with the presently defined elements but may not be so good in the years to come. Its a subtle difference between 'last', which means always at the end, no mater what, and 'fifth' which is last today but might not be in the future. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods pgp_Ox59p3DZ7.pgp Description: PGP signature
Re: [gentoo-dev] [pre-GLEP r3] Gentoo binary package container format
On 2018.11.26 18:58, Michał Górny wrote: > Here's the newest version. > > Changes: > > - added explicit notion of parent directory (missing in previous GLEP > but present in implementation), > > - explicitly named GNU tar format with list of permitted extensions, > > - changed volume label to 'gpkg-1.txt' file to improve portability; > made > it explicit version identifier as well, > > - added info on other package formats to rationale. > [snip] The image archive stores all the files to be installed by the binary package. It should be included as the last of the files in the binary package container. [snip] > > -- > Best regards, > Michał Górny > Its a nit today but that says that any future extensions, none yet planned, should be placed before the image archive. The specification needs to avoid the use of relative references. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods pgpXu1HdOG3la.pgp Description: PGP signature
Re: [gentoo-dev] [pre-GLEP r1] Gentoo binary package container format
On 2018.11.19 19:33, Rich Freeman wrote: > On Mon, Nov 19, 2018 at 2:21 PM Roy Bamford > wrote: > > > > "The archive members support optional OpenPGP signatures. > > The implementations must allow the user to specify whether OpenPGP > > signatures are to be expected in remotely fetched packages." > > > > Or can the user specify that only some elements need to be signed? > > > > Is it a problem if not all elements are signed with the same key? > > That could happen if one person makes a binpackage and someone > > else updates the metadata. > > > > IMO this is going a bit into PM details for a GLEP that is about > container formats. > Rich, Not really. The GLEP needs to be clear about the signing. Is it every element or none? The GLEP hints that a mix of is possible with If the implementation needs to manipulate archive members, it must either create a new signature or discard the existing signature. An individual binpackage could start life with all elements signed by the same key. Some element could be updated and the key for the signature of that element changed. Later still, another element can be changed an have its signature dropped. Should some combinations have no practical value, they should not be permitted by the GLEP. > -- > Rich > > > -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods pgpaUbIZBgWaT.pgp Description: PGP signature
Re: [gentoo-dev] [pre-GLEP r1] Gentoo binary package container format
On 2018.11.19 18:35, Michał Górny wrote: > Hi, > > On Sat, 2018-11-17 at 12:21 +0100, Michał Górny wrote: > > Here's a pre-GLEP draft based on the earlier discussion on gentoo- > > portage-dev mailing list. The specification uses GLEP form as it > > provides for cleanly specifying the motivation and rationale. > > Changes in -r1: took into account the feedback and restructured > the motivation into pointing out advantages of the existing format, > and focusing on the two real issues of non-transparency and OpenPGP > implementations deficiencies. Also added a section on why there's no > explicit version number. > > > Also available via HTTPS: > > > > rst: https://dev.gentoo.org/~mgorny/tmp/glep-0078.rst > > html: https://dev.gentoo.org/~mgorny/tmp/glep-0078.html > > > [snip] Team, Looks good to me. I can manually unpick the binpackage with tar. Choose, if I will check the signatures or not, then spray files all over my broken Gentoo with tar in the same way as I do now. Implementation detail question. It appears that all members must be signed, or none of them since "The archive members support optional OpenPGP signatures. The implementations must allow the user to specify whether OpenPGP signatures are to be expected in remotely fetched packages." Or can the user specify that only some elements need to be signed? Is it a problem if not all elements are signed with the same key? That could happen if one person makes a binpackage and someone else updates the metadata. > -- > Best regards, > Michał Górny > -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods pgpX6ueFyt3EF.pgp Description: PGP signature
Fwd: Re: [gentoo-dev] [pre-GLEP] Gentoo binary package container format [gen...@jonesmz.com]
See attached. Replying off list because I am not on the whitelist ... -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods --- Begin Message --- On Sun, Nov 18, 2018 at 5:04 AM Roy Bamford wrote: > On 2018.11.18 09:38, Michał Górny wrote: > > On Sun, 2018-11-18 at 10:16 +0100, Fabian Groffen wrote: > > > On 17-11-2018 12:21:40 +0100, Michał Górny wrote: > > > > Problems with the current binary package format > > [snip] > > > > > 2. **The format relies on obscure compressor feature of ignoring > > > >trailing garbage**. While this behavior is traditionally > > implemented > > > >by many compressors, the original reasons for it have become > > long > > > >irrelevant and it is not surprising that new compressors do not > > > >support it. In particular, Portage already hit this problem > > twice: > > > >once when users replaced bzip2 with parallel-capable pbzip2 > > > >implementation [#PBZIP2]_, and the second time when support for > > zstd > > > >compressor was added [#ZSTD]_. > > > > > > I think this is actually the result of a rather opportunistic > > > implementation. The fault is that we chose to use an extension that > > > suggests the file is a regular compressed tarball. > > > When one detects that a file is xpak padded, it is trivial to feed > > the > > > decompressor just the relevant part of the datastream. The format > > > itself isn't bad, and doesn't rely on obscure behaviour. > > > > Except if you don't have the proper tools installed. In which case > > the 'opportunistic' behavior made it possible to extract the contents > > without special tools... except when it actually happens not to work > > anymore. Roy's reply indicates that there is actually interest in > > this > > design feature. > > > [snip] > > Team, > > I use to post something like https://wiki.gentoo.org/wiki/Fix_My_Gentoo > with a link to Patricks binhost on the forums every three or four months. > It made it worth writing that wiki page anyway. > > We still get users removing elements of their toolchain or glbc from time > to time. The requirement that I didn't express very well, is that it > shall > be possible to install binary packages without the use of any Gentoo > specific tooling. > > The current tarball of tarballs proposal would satisfy that requirement. > > Its unlikely that a custom binary format would. Of course, this being > Gentoo someone would write a run anywhere script that did the > unpicking, We already have deb2targz and rpm2targz. We have the > opportunity to design out binpgk2targz before it exists. > > -- > Regards, > > Roy Bamford > (Neddyseagoon) a member of > elections > gentoo-ops > forum-mods > Replying off list because I am not on the whitelist. Please also consider my use case: I have a cluster file system, cephfs, which all of my gentoo machines mount for access to various shared file resources. I want to have all of them mount a cephfs path to the folder which portage is configured to look for binary packages. This works great if all of the machines have identical portage configurations, but breaks down as soon as one machine uses a different use flag. The reason for this is that the package file names do not encode anything other than the package name and version number. So if a binpkg already exists in my binpkg repository, and another machine builds with different use flags, the binpkg gets overwritten, potentially while a third machine is reading the binpkg file. The filename also does not represent compile time dependencies, or any number of other possible points of differentiation This issue could be (at least partially) solved at least 3 ways. 1) append a uuid to each filename. Generated when the bin package file is generated. 2) encode the hostname of the machine that generated the file 3) encode the use flags in the filename. Perhaps a fuller solution is to respect an environment variable "BINARY_PKG_FILENAME_FORMAT" that accepts a series of variable substitutions to append after the package name and version number? This variable would be used only when generating the binary package. Portage would still use any binary package that it found that matched its needs, regardless of suffix. Thanks for your time. --- End Message --- pgpoqDkTyX_48.pgp Description: PGP signature
Re: [gentoo-dev] [pre-GLEP] Gentoo binary package container format
On 2018.11.18 09:38, Michał Górny wrote: > On Sun, 2018-11-18 at 10:16 +0100, Fabian Groffen wrote: > > On 17-11-2018 12:21:40 +0100, Michał Górny wrote: > > > Problems with the current binary package format [snip] > > > 2. **The format relies on obscure compressor feature of ignoring > > >trailing garbage**. While this behavior is traditionally > implemented > > >by many compressors, the original reasons for it have become > long > > >irrelevant and it is not surprising that new compressors do not > > >support it. In particular, Portage already hit this problem > twice: > > >once when users replaced bzip2 with parallel-capable pbzip2 > > >implementation [#PBZIP2]_, and the second time when support for > zstd > > >compressor was added [#ZSTD]_. > > > > I think this is actually the result of a rather opportunistic > > implementation. The fault is that we chose to use an extension that > > suggests the file is a regular compressed tarball. > > When one detects that a file is xpak padded, it is trivial to feed > the > > decompressor just the relevant part of the datastream. The format > > itself isn't bad, and doesn't rely on obscure behaviour. > > Except if you don't have the proper tools installed. In which case > the 'opportunistic' behavior made it possible to extract the contents > without special tools... except when it actually happens not to work > anymore. Roy's reply indicates that there is actually interest in > this > design feature. > [snip] Team, I use to post something like https://wiki.gentoo.org/wiki/Fix_My_Gentoo with a link to Patricks binhost on the forums every three or four months. It made it worth writing that wiki page anyway. We still get users removing elements of their toolchain or glbc from time to time. The requirement that I didn't express very well, is that it shall be possible to install binary packages without the use of any Gentoo specific tooling. The current tarball of tarballs proposal would satisfy that requirement. Its unlikely that a custom binary format would. Of course, this being Gentoo someone would write a run anywhere script that did the unpicking, We already have deb2targz and rpm2targz. We have the opportunity to design out binpgk2targz before it exists. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods pgpFaerHiTnmN.pgp Description: PGP signature
Re: [gentoo-dev] [pre-GLEP] Gentoo binary package container format
On 2018.11.17 11:21, Michał Górny wrote: > Hi, > > Here's a pre-GLEP draft based on the earlier discussion on gentoo- > portage-dev mailing list. The specification uses GLEP form as it > provides for cleanly specifying the motivation and rationale. > >[snip glep proposal] > -- > Best regards, > Michał Górny > Team, One of the attractions of the existing format is that tar xf /path/to/tarball -C /mnt/gentoo works to fix things like glibc being removed and other missing essential portage components. In effect, each binary package can be treated as a single package stage3 when a user needs a get out of jail free card. Does this proposal allow for installing the payload without the use of the Gentoo package manager from some random distro being used as a rescue media? -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods pgpGykl9iWp_g.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] Solving the problem of huge number of wrong LICENSES=*GPL-[23]
On 2018.08.26 12:15, Michał Górny wrote: > On Sun, 2018-08-26 at 13:09 +0200, Paweł Hajdan, Jr. wrote: > > On 26/08/2018 12:53, Mart Raudsepp wrote: > > > The common issue here is that upstream COPYING files really do > only > > > talk about one of the versions. And then you get to validate or > source > > > files to be sure that they do have a "or later" clause in them. > And > > > then on each bump you ideally should validate it again, etc, that > no > > > sources without "or later" allowance are in there... > > > > Yup, precise tracking of license metadata can be a pain. > > > > I'm not really sure if that level of it is worth for us as a distro. > For > > _importing_ other project's source code directly into one's project > > precise license compatibility matters a lot. That's not the scenario > > we're in. I see LICENSES as mostly a mechanism for end users to > accept > > or reject EULAs etc, and I'm curious what are other common > scenarios. > > > > Michał, could you elaborate on why not distinguishing more precisely > > between these GPL variants in LICENSES is a _problem_ ? I can > certainly > > see the information is not always accurate, but it's not obvious to > me > > how severe is the downside, what are the consequences in practice. > > > > I'm not aware of any major implications. However, I think that if we > provide for the distinction, the distinction should be used correctly. > > -- > Best regards, > Michał Górny > Michał, How far do you want to dig? Every upstream file or do you trust the upstream top level licence? What about bundled libs? Do you trust upstream to have that that right too? It looks like a lot of work for what is at most, a convenience to users. What matters most is the licensing for things we distribute as binaries. That would make an interesting and more manageable test case. As has already been pointed out. Fixing it is one thing, keeping it fixed is another. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods pgplAdhXytuo_.pgp Description: PGP signature
Re: [gentoo-dev] Adding USE=udev to linux profiles
On 2018.07.20 14:14, Rich Freeman wrote: > While you can get Gentoo > running with busybox and such and I completely support having profiles > to enable this, I'm not sure this is the sort of thing that we want to > point new users towards as a starting point. > > -- > Rich > New to Linux users, I agree. Linux users new to Gentoo should maybe have more freedom to shoot themselves in the foot. They are more likely to be coming to Gentoo to get what they think they want. They just don't know how yet, so lets not make it too difficult. I_KNOW_WHAT_I_AM_DOING or something similar comes to mind. -- Regards, Roy Bamford (Neddyseagoon) a member of arm64 elections gentoo-ops forum-mods pgpU9UN94Wo7a.pgp Description: PGP signature
Re: [gentoo-dev] Idea for a new project: gentoo-libs
On 2018.06.23 09:55, Marty E. Plummer wrote: > On Sat, Jun 23, 2018 at 10:15:06AM +0200, Paweł Hajdan, Jr. wrote: > > On 23/06/2018 09:43, Mikle Kolyada wrote: > > > But how would it serve gentoo itself? Lots of packages in the > distro > > > have dead upstream but still work. > > > Why would you want to make gentoo an upstream area rather than > moving a > > > dead project itself, say, > > > to github and do the job there? > > > > +1 > > > > I like the idea of taking responsibility for the abandoned packages > that > > are still useful. > > > > It's probably not Gentoo-specific, so a distro-neutral way of > handling > > that seems most appropriate. > > > > It may even be worth it to coordinate with other distros (and maybe > > downstreams) so that the new version becomes a standard. > > > > Finally, having more than one person on this (to help continuity), > and a > > common platform like GitHub also seem very helpful. > > > > Paweł > > > Agreed in general; the problem is getting it started at all; difficult > to get other distros to join if there is nothing to join. > > > A couple of generalisations. The first solution to unmaintained packages should be to move to an alternative, if that's possible. Gentoo does not have the resource to be upstream for very much for the entire Linux community, a point already made by others. In volunteer groups things get done by those who want to do them. Others join later. I think the quote I'm looking for is "Build it and they will come". -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods pgpVfuXnGRrnH.pgp Description: PGP signature
Re: [gentoo-dev] Suggestions for simplifying VIDEO_CARDS situation
On 2018.06.17 08:49, Brian Dolbec wrote: > On Sat, 16 Jun 2018 21:40:10 -0700 > Matt Turner wrote: > > > Hello, > > > > VIDEO_CARDS is an annoying mess. We used to have radeon, intel, and > > some others in media-libs/mesa's VIDEO_CARDS. radeon and intel > > corresponded to disparate sets of drivers -- VIDEO_CARDS=radeon has > > meant classic r100, r200, r300, and r600 drivers and gallium r600 > and > > radeonsi drivers. VIDEO_CARDS=intel has meant classic i915 and i965 > > drivers as well as gallium i915. > > > > I added more-specific VIDEO_CARDS for those separate drivers a few > > years ago, so that users could set VIDEO_CARDS="radeon radeonsi" and > > only get the one radeonsi driver they actually wanted while still > > enabling support for x11-libs/libdrm's radeon support code which is > > used by most of those radeon drivers. Of course some users want this > > control and others don't care at all. > > > > The confusion comes in with "classic" DRI drivers vs Gallium > drivers. > > The Gallium abstraction layer allows a hardware driver to handle > > multiple APIs -- OpenGL, D3D9, OpenCL, video decode APIs, etc. For > > instance, users try to build the classic i965 driver (there is no > > Gallium driver for this hardware) with USE=opencl or USE=vaapi and > > don't understand why they didn't get what they wanted (or > REQUIRED_USE > > prevents them from doing so). > > > > Should of Mesa's USE flags, d3d9, llvm, lm_sensors, opencl, openmax, > > unwind, vaapi, vdpau, xa, and xvmc are Gallium-only. Should I make a > > USE_EXPAND for Gallium-only options to attempt to avoid confusion? > > Another point of confusion: not all Gallium drivers support all of > > these features. For instance only the r600 and radeonsi drivers > > support OpenCL. How to best handle this? > > > > It seems like at one extreme you build an extensive set of > > REQUIRED_USE conditions that force users to micromanage their USE > > flags, or you let them enable all sorts of impossible combinations > and > > deal with the confused bug reports. > > > > I would like to somehow get rid of the 'classic' and 'gallium' USE > > flags entirely, but I'm not totally sure how. Maybe I can enable > them > > dependent on VIDEO_CARDS... > > > > Suggestions welcome. > > > > What about creating a tiny pkg that has all the combinations in a > dictionary and can set the USE and VIDEO_CARDS flags according to the > video card(s) you have. > > This would be along the same lines as the > app-portage/cpuid2cpuflags pkg. Then the pkg is updated as new > drivers > and combinations are changed. Perhaps have it run in pkg_postisnt to > print any irregularities it finds and ewarn they need fixing. > > -- > Brian Dolbec > > > > That would break for cross compiling. My Raspberry PI has a VC4 GPU but I build things on an AMD64 box. Any autodetection needs an emergency manual override, even if its hidden behind the I_KNOW_WHAT_I_AM_DOING flag. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods pgp49aOi1n44G.pgp Description: PGP signature
Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny
On 2018.03.23 09:48, Ulrich Mueller wrote: > >>>>> On Thu, 22 Mar 2018, Geaaru wrote: > > > for both portage and your fork I think that could be interesting add > > an extension to PMS for define inside profiles or targets masking of > > packages of a particular repslository. Currently PMS doesn't permit > > this but have this feature could be help users to define our > > profiles under overlays. > > > Something like this: > > > sys-devel/gcc::gentoo > > Conceptually that makes no sense. sys-devel/gcc is the name of an > upstream package, so what does it even mean to mask it in one > repository but not in another? If it's the same package, then it > should behave in the same way, regardless of the repository its ebuild > it hosted in (or the package being installed, in which case it is no > longer in an ebuild repository). > > If it is a different package however, then it should have a different > name. > > Ulrich > Ulrich, That has just irritated me. The use case is sdlmame. !!! The following installed packages are masked: - games-emulation/sdlmame-0.195::Pi_aarch64 (masked by: package.mask) /usr/portage/profiles/package.mask: # Pacho Ramos <pa...@gentoo.org> (18 Mar 2018) # Fails to build (#634662), version bump long time pending (#596162). # Removal in a month. games-emulation/sdlmame is masked. I have a higher version in my overlay than the one in the tree and it gets masked too. Its not a problem to me as I know how to manage it. Its just untidy. With apologies to Pacho for citing his name in the worked example. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods pgpTpwKGF0FbM.pgp Description: PGP signature
Re: [gentoo-dev] Questions on overlays, repositories and PMS
On 2018.02.24 01:32, Michael Lienhardt wrote: > > > Il 23/02/2018 20:37, Alec Warner ha scritto: > > My general observation is that Gentoo is not successful as an > organization about deprecating and removing things. One area where > Gentoo has done well is in EAPI and in PMS itself, with mostly-clear > versioning and standards and whatnot. But in general if something > worked 15 years ago, it probably still works today (doubly so for > sys-apps/portage). > > > > There is a different question when building a tool like yours if it > is worth the effort to support things that are 15 years old and are > possibly not used (particularly in cases where functionality was > replaced). I'd recommend starting with the basic implementation and > adding support for the 'older' formats when users ask for them; but > this is mostly a trade-off in efforts. If your goal is to build > > a "100% compatible" tool then you will probably need to support > these edge cases. > > You have a very good point. > I'd like to be complete (it's a side effect of working in formal > methods), but it's quite unrealistic as I am the only developer in > this project, and it's true that there are few technical design > choices that were made in portage that I'd be happier not to > implement. > I'd like to implement the /etc/portage/repos.conf system to remove as > many hard coded references to /usr/portage in my code as possible. > Moreover, the /etc/portage/repos.conf system looks nice, modular with > explicit dependencies and it almost unifies all the repositories (I > don't really understand the need of a DEFAULT section). > > If possible, I'd rather avoid implementing things that are deprecated, > but like you pointed out, few are (portage seems to be always > expanding with new/alternative functionalities). > The ones that are, like the /etc/portage/package.keywords file, seem > to be still used (I've got a request to support it in my > get_installation.sh script). > Additionally, there are two systems that I did not want to implement > but had to: the IUSE_IMPLICIT and USE_EXPAND. > I didn't find any good documentation on these systems (nor the PMS nor > https://dev.gentoo.org/%7Ezmedico/portage/doc/man/portage.5.html are > very clear on the subject -- the PMS is still clearer), I tested a lot > and looked at the portage implementation... > I don't understand the reason to implement these systems with bash > variables expanded with prefixes, while many of the USE flag > manipulation is done with dedicated files (use.*, package.use.*). > It really felt like an old design choice kept there because it worked, > but which could be simplified. > > On a similar topic, does anyone still have USE-related variables in > his /etc/env.d folder? (https://wiki.gentoo.org/wiki/USE_ORDER) > It seems to me that portage's current effort is to have all > configuration files in /etc/portage or in the profile. > > Best, > Michael Lienhardt > > > Michael, 'Support' can be as simple as nagging the user to move with the times and failing. I suspect that many older systems (including mine) are not updated because it still works. crossdev users may be familiar with this approach. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods pgp8okkf_VHbW.pgp Description: PGP signature
Re: [gentoo-dev] SAT-based dependency solver: request for test cases
On 2018.02.06 10:52, Michael Lienhardt wrote: > Dear all, > > With the help of some friends and colleagues, I am working on an > SAT-based dependency solver for portage. > We need your help to test it and possibly improve in the long run the > already great portage toolset. > > To help, you can send us the tar generated by this bash script: > https://raw.githubusercontent.com/HyVar/gentoo_to_mspl/master/benchmarks/get_installation.sh > This bash script extracts your world file, the USE flags and keywords > configuration of your system and the list of installed packages you > have (it should not take more than few seconds). > With this, we will see if our solver is able to recreate your system > and how much time it takes. > > You can send everything to my professional email: mlien...@di.unito.it > > > The goal of this alternative solver is to overcome some of the > limitations of emerge. > Thanks to some users of the forum and the gentoo-user mailing list, I > already tested the solver on 8 systems, and the results for now are: > - emerge is not able to recreate any of these systems (i.e., 'cat > world_of_test_configuration | xargs emerge -vp' on a gentoo osboxes VM > does not succeed, even with the right /etc/portage/package.* files) > - our solver takes 2 minutes in average (with little variation), and > gives either a yes answer (with what to install, which USE flags to > set, which packages to keyword) or a no answer (with the set of > conflicting constraints) for every systems > - we solved one bug in our solver (a behavior of emerge that seems > documented only in the PMS document, not in devmanual nor in the wiki, > and that is visible only in 15 packages), but at least one seems to > still be around. > > I started discussing this on the gentoo-portage-dev and the > gentoo-user mailing lists (sorry for the duplicates), and on the forum > with three posts: > - https://forums.gentoo.org/viewtopic-t-1074170.html about the > documentation I collected to implement the solver > - https://forums.gentoo.org/viewtopic-t-1074202.html about the > solver and its motivations > - https://forums.gentoo.org/viewtopic-t-1075286.html about the tests > I'm doing > > > About me: > I'm a researcher in computer science, about formal methods, > concurrency and software engineering. > Friday, I will present my first paper on portage, showing that its > packages and their dependencies constitute what is called a > "Multi-Software Product Line" in software engineering. If you skip the > algebraic definition, it should be readable ^^: > http://www.di.unito.it/~mlienhar/vamos.pdf > In 2013, I designed and contributed to the implementation of a > dependency solver for dynamic cloud architecture (currently maintained > by Jacopo Mauro https://bitbucket.org/jacopomauro/zephyrus2/src ) > I'm a gentoo user since 2007, and I'm very happy by this opportunity > to contribute back :). > > > Thank you! > Michael Lienhardt > > > Michael, Posting here to alert other potential helpers. Your script uses PACKAGE_KEYWORDS="/etc/portage/package.accept_keywords" but thats a recent name change. PACKAGE_KEYWORDS="/etc/portage/package.keywords" is the old name and my older systems still use that. You probably need to harvest both and process both as portage does. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods pgpjZkguBNLdT.pgp Description: PGP signature
Re: [gentoo-dev] [pre-GLEP] Split distfile mirror directory structure
On 2018.01.27 08:30, Michał Górny wrote: > W dniu pią, 26.01.2018 o godzinie 20∶48 -0500, użytkownik Michael > Orlitzky napisał: > > On 01/26/2018 06:24 PM, Michał Górny wrote: > > > > > > The alternate option of using file hash has the advantage of > having > > > a more balanced split. Furthermore, since hashes are stored > > > in Manifests using them is zero-cost. However, this solution has > two > > > significant disadvantages: > > > > > > 1. The hash values are unknown for newly-downloaded distfiles, so > > >``repoman`` (or an equivalent tool) would have to use a > temporary > > >directory before locating the file in appropriate subdirectory. > > > > > > 2. User-provided distfiles (e.g. for fetch-restricted packages) > with > > >hash mismatches would be placed in the wrong subdirectory, > > >potentially causing confusing errors. > > > > > > > The filename proposal sounds fine, so this is only academic, but: > are > > these two points really disadvantages? > > > > What are we worried about in using a temporary directory? Copying > across > > filesystem boundaries? Except in rare cases, $DISTDIR itself will be > > usable a temporary location (on the same filesystem), won't it? > > Why add the extra complexity when there's no need for one? Note that > there's also the problem of resuming transfers, so in the end we're > talking about permanent temporary directory where we keep unfinished > transfers. > > > For the second point, portage is going to tell me where to put the > file, > > isn't it? Then no matter what garbage I download, won't portage look > for > > it in the right place, because where-to-put-it is determined using > the > > same manifest hash that determines where-to-find-it? > > No, it won't. Why would it? You're going to call something like: > > edistadd foo.tar.gz bar.tar.gz > > ...and it will place the files in the right subdirectories. > > -- > Best regards, > Michał Górny > > > > Michał, How does this work for fetch restricted files and finding other files no longer on the mirrors? Its no longer a download and move it to $DISTFILES, or is it? Whatever it is, users will need to do it unless files in $DISTFILES are accepted by package managers if they are not found in the main structure. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods pgpqad588ZI9H.pgp Description: PGP signature
Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list
On 2018.01.11 01:03, Andreas K. Huettel wrote: > > Does being 'struck off' the list in this way apply to devs, > including > > Council and comrel members? > > So far noone has even considered "striking" devs off the list. If this > even > were to happen ever, it would have to be backed by a full comrel team > decision > / vote. And these don't happen often, don't happen quickly, and don't > happen > lightly. (I much prefer fixing the glibc ebuilds, horrible as these > may be.) > > We have now an imperfect solution to an unneccessary problem. If > anyone can > come up with a better solution (that is still an improvement over > doing > nothing), I'm all ears. List moderation is not one, since a) it still > hasn't > been implemented technically, b) even if that were done, we would > still > require an active moderation team, and c) then we start bikeshedding > about the > moderation rules. > > > -- > Andreas K. Hüttel > dilfri...@gentoo.org > Gentoo Linux developer > (council, toolchain, perl, libreoffice, comrel) Andreas, Does removing non @gentoo.org email address from the ML not require that process too? Gentoo does not have any other disiplinary process than the action by comrel that you describe. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods pgp0aZ8m0b6IP.pgp Description: PGP signature
Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list
On 2018.01.09 21:20, Andreas K. Huettel wrote: [snip] > * Obviously, repeated off-topic posting as well as behaviour against > the > Code of Conduct [2] will lead to revocation of the posting > permission. > [snip] > -- > Andreas K. Hüttel > dilfri...@gentoo.org > Gentoo Linux developer > (council, toolchain, perl, libreoffice, comrel) Andreas, Being somwhat old and cynical, I'm seeing signs of history repeating itself. Does being 'struck off' the list in this way apply to devs, including Council and comrel members? -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods pgpeMAJ1kh9Zo.pgp Description: PGP signature
Re: [gentoo-dev] The problem of unmaintained packages in Gentoo
On 2017.12.21 00:35, William Hubbs wrote: > On Wed, Dec 20, 2017 at 07:12:45PM -0500, Michael Orlitzky wrote: > > On 12/20/2017 06:58 PM, William Hubbs wrote: > > > > > > There already is an overlay for dying packages, it is called > graveyard, > > > but no one is putting things there. > > > > > > This email conflates old dying packages with new versions, which > are a > > > completely separate issue. > > > > > > > Lack of new versions *is* dying. But I can make a package not-dying > in a > > few seconds by merging a PR, so long as you don't expect me to do > the > > (relatively high) level of QA required for ~arch. > > > > > > > If a new version of a package is known to cause wide scale > breakage, it > > > goes in package.mask until the breakage is resolved. Otherwise, > putting > > > it in ~ is fine. I don't see the need for another level of > keywords. > > > > The quality of ~arch is its own worst enemy; these days, stable > packages > > are just old ~arch packages. Users and developers expect ~arch to > work, > > and we have no real policy or documentation stating that it won't. > Many > > people will tell you that ~arch works better than stable, because it > > gets fixed faster. > > ~arch *will* have breakages from time to time, sometimes major > breakages, until they are masked or fixed. We are not supposed to > leave > major breakages there, but ~arch is definitely not for the faint of > heart. If you are using ~arch, you are expected to be a power user at > leasst and be able to recover if your system breaks. Production > servers > should not be running ~arch at all. That's the whole reason ~arch > exists. > > Yes, ~arch gets fixed faster than stable, but that is to be expected. > However, it is definitely not a good reason to put your production > system on > full ~arch. > > So, I guess this means that the quality of the ~arch tree is supposed > to > be somewhat lower than the quality of the stable tree. > > William > > William, I've been running ~arch everywhere since May 2002 and had exactly two major issues. They were :- Xorg going modular ... which I was aware of before it happened and expat which came as a surprise while I was dealing with modular Xorg. There have been some minor inconviences along the way too but problems running ~arch have reduced over the years. Nobody should run Gentoo at all in production unless they build and test packages offline before pushing the binaries to production. Then they can run whatever they want. Every Gentoo install is different and very few possible combinations are actually tested. By all means lower the bar for ~arch. Say, to "builds and works for me, needs more testing". The down side is that it will create more bug reports and more work, so it may only exchange one problem for another. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods pgp1acaAGrvTc.pgp Description: PGP signature
Re: [gentoo-dev] Java 9 on Gentoo
On 2017.11.18 04:16, William L. Thomson Jr. wrote: > On Sat, 18 Nov 2017 02:40:14 + > Peter Stuge <pe...@stuge.se> wrote: > > > William L. Thomson Jr. wrote: > > > > If you have any suggestions as to what I should look at to > better > > > > understand the OpenJDK build system I would very much appreciate > > > > them. > > .. > > > Build OpenJDK stand alone. Get familiar with that. > > > > It used to be that one could not build OpenJDK without already > having > > a working JDK. Has that changed with OpenJDK 9 (IIRC it was planned > > for OpenJDK 7 :) or not yet, and that is a reason for having icedtea > > in the mix? > > Yes you are correct, nothing has changed there to my knowledge. > [snip] > > -- > William L. Thomson Jr. > You can start with gcc-5.4 with the gcj use flag. That will bootstrap icedtea:7 icedtea:7 will bootstrap icedtea:8 Tested on arm64. With icedtea:7 going and gcc-5.4 not having a very long future, building icedtea for a new arch will be painful. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods pgpgyRdsSikdz.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] GLEP 74: Full-tree verification using Manifest files
On 2017.10.26 21:12, Michał Górny wrote: > Hi, everyone. > > After a week of hard work, I'd like to request your comments > on the draft of GLEP 74. This GLEP aims to replace the old > tree-signing > GLEPs 58 and 60 with a superior implementation and more complete > specification. > > The original tree-signing GLEPs were accepted a few years back but > they > have never been implemented. This specification, on the other hand, > comes with a working reference implementation for the verification > algorithm. I expect to finish the update/generation part in a few > days, > then work on additional optimizations (threading, incremental > verification, incremental updates). > > ReST: https://dev.gentoo.org/~mgorny/tmp/glep-0074.rst > HTML: https://dev.gentoo.org/~mgorny/tmp/glep-0074.html > impl: https://github.com/mgorny/gemato/ > > Full text following for inline comments. > [snip lots of hard work] > > -- > Best regards, > Michał Górny > > > Michał, Thank you for the hard work. This GLEP implies that users need to have the entire repository to validate and authenticate, if I understand it correctly. For example PORTAGE_RSYNC_EXTRA_OPTS="--exclude=<list_of_" wil still work but the resulting tree could not be authenticaed. as the top level signature would fail. The manifests would still work correctly because they only apply to the directory containing them. Pruning the repository at rsync time will therefore remove the manifents and the files that they cover. Is that understanding correct? -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods pgp6HmH_FLlOR.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-project] The status of grsecurity upstream and hardened-sources downstream
On 2017.06.23 19:54, Alice Ferrazzi wrote: [snip] > > As we already contribute to grsec in the past, > would be sad to see hardened-sources go away. > What about the possibility of Gentoo forking PaX ? > > -- > Thanks, > Alice Ferrazzi > > Gentoo Kernel Project Leader > Mail: Alice Ferrazzi <ali...@gentoo.org> > PGP: 2E4E 0856 461C 0585 1336 F496 5621 A6B2 8638 781A > > Alice, Forking with what aim? Keeping the existing functionality alive in line with kernel developments or that and adding new features. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods pgpsyL177pvC6.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] Restricted version of gentoo-dev mailing list
On 2017.05.29 11:59, Alexander Berntsen wrote: > On 27/05/17 18:17, Patrick Lauer wrote: > > But you do gentoo wrong, so as a user I'd like you to reconsider > what > > you wrote there and maybe take a long vacation. > I too do not hate our users (in which I include myself). > > Treating users as a worthless nuisance, unless they're writing ebuilds > or managing your precious GitHub crap, is a good way to lose users. > > And even if I did hate our users, I agree with William & Ulrich. > -- > Alexander > berna...@gentoo.org > https://secure.plaimi.net/~alexander > > ... and some of those lost users might have gone on to become devs. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods pgpLoBjumJszq.pgp Description: PGP signature
Re: [gentoo-dev] RFC: Pre-GLEP: Security Project
On 2017.03.11 20:50, Kristian Fiskerstrand wrote: > A draft of a Pre-GLEP for the Security project is available for > reading > at https://wiki.gentoo.org/wiki/User:K_f/GLEP:Security > > The GLEP follows a line of GLEPs for special projects that have > tree-wide access in order to ensure proper accountability (c.f GLEP 48 > for QA and still non-produced GLEP for ComRel (I've started working on > this and will be presenting this one later as current ComRel Lead)) > > Comments, patches, threats, etc welcome > > -- > Kristian Fiskerstrand > OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net > fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 > > Kristian, First of all, thank you. We have needed something like this for several projects, for some time. A few odds and ends. Why do Security Project members need to be ebuild devs? Non ebuild developers can contribute by producing GLSAs, for example. Who manages the Security Project (from outside). It appears from the draft GLEP, nobody. That means that the project could become moribund and nobody would notice. Its not like Gentoo enforces or even checks for leadership elections. That's an anual event anyway, so its not a measure of a projects continued well being. Compare the Security Project to council, that have a monthly showing of project health. Projects tend to be left alone. Gentoo has several projects that appear to be unmanaged but cannot be permitted to die out. This is one. Who takes the Security Projects pulse and how? A periodic automated message to -dev that all Security Project members "reply to list" is both public and mimnimally invasive. Its no more than 'roll call'. Now the hard one, who does what when there is no pulse from the Security Project? This isn't really a Security Project issue. If its ever needed, the Security Project isn't active. It affects other projects too, like comrel, QA and others. Perhaps there is a common solution to taking a proqcts pulse and reacting when there is none. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods pgpQAiSAKWYXf.pgp Description: PGP signature
Re: [gentoo-dev] newsitem: important fstab update
On 2016.10.25 22:52, Ian Stakenvicius wrote: > On 25/10/16 05:12 PM, Michał Górny wrote: > > On Tue, 25 Oct 2016 12:01:06 -0500 > > William Hubbs <willi...@gentoo.org> wrote: > > > >> Title: Inportant fstab update > >> Author: William Hubbs <willi...@gentoo.org> > >> Content-Type: text/plain > >> Posted: 2016-10-28 > >> Revision: 1 > >> News-Item-Format: 1.0 > >> > >> If you are not using /dev/disk/by-* paths in fstab, you do not need > to > >> take any action for this news item. > >> > >> If you are, it is very critical that you update fstab AS SOON AS > >> POSSIBLE. Your system will become unbootable in the future if you > do > >> not do so. > > > > I don't think this is a good way to start any text. You should start > > with a short introduction on what's happening, when and how. > > > > Right now the news item sounds like the world is going to suddenly > fall > > apart for no specific reason. Reading it, I don't know what's > changing, > > and how to check if it impacts me already (i.e. if it's 'do not > > reboot' kind of problem) and if it will impact me at all. > > > >> You need to replace the /dev/disk/by-* paths in your fstab with the > >> equivalent information from the output of the blkid utility. > > > > This is at least unclear, if not misguiding. I read it as 'blkid > will > > give you fs info'. However, you're not telling me which of those > > information I can use and how. I should also point out that blkid > > supports multiple output formats. > > > > I think it would be better if you explicitly listed the thingies > > supported by mount(1). > > > > Reading mgorny's response, I'm wondering if a news item really makes > any sense at all for this. What's being done here is essentially a > warning/recommendation for users to act so they don't run into a > problem that's sort-of already there (at least in ~arch)... > > Personally I'd rather see us go the other way, ensure udev settles > before localmount runs, and maybe ewarn if /dev/disk/by-* is in fstab > or something. Leave the migration away from these paths to general > education of system setup, since they technically are valid, just not > ideal. > > +1 Add udev-settle now. Have an advisory news item that says why its been done and what users can do if they don't like it or don't need it, and what will happen long term. At the same time, depreciate the use of udev symlinks in fstab. Some time later, remove udev-settle and have another news item. By now, users will have reacted to the first news item or sympathy can be minimal. In the interim, nothing should break because a news item was not read and acted on immediately. That's the important bit ... nothing breaks on user systems. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods pgpRXKeMRcwoT.pgp Description: PGP signature
Re: [gentoo-dev] [RFD] Adopt-a-package, proxy-maintenance, and other musings
On 2016.01.21 17:45, Michał Górny wrote: [snip] > > If I see a package that clearly doesn't build or otherwise simply > doesn't work, could not have worked for past 3 years, are you forcing > me to waste a time reporting a bug to no maintainer who could fix it? > [snip] > -- > Best regards, > Michał Górny > <http://dev.gentoo.org/~mgorny/> > Michał Your statement implies that there is an active search process for broken packages. I did not intend to imply that if you happened across a broken package with no bugs, you needed to raise a bug to remove it from the tree. Actively building every package in the tree to discover candidates for removal takes a lot more resources than searching bugs to identify potential candidates. Its the old case of absence of evidence is not evidence of absence. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods trustees pgpFDkyRFS8fc.pgp Description: PGP signature
Re: [gentoo-dev] [RFD] Adopt-a-package, proxy-maintenance, and other musings
On 2016.01.21 16:53, William Hubbs wrote: > On Tue, Jan 19, 2016 at 10:35:15AM -0800, Alec Warner wrote: > > On Mon, Jan 18, 2016 at 9:44 PM, NP-Hardass <np-hard...@gentoo.org> > wrote: > > > > > -BEGIN PGP SIGNED MESSAGE- > > > Hash: SHA256 > > > > > > With all of the unclaimed herds and unclaimed packages within > them, I > > > started to wonder what will happen after the GLEP 67 transition > > > finally comes to fruition. This left me with some concerns and I > was > > > wondering what the community thinks about them, and some possible > > > solutions. > > > > > > There is a large number of packages from unclaimed herds that, at > this > > > time, look like they will not be claimed by developers. This will > > > likely result in a huge increase in maintainer-needed packages > (and > > > subsequent package rot). This isn't to say that some of these > > > packages weren't previously in a "maintainer-needed" like state, > but > > > now, they will explicitly be there. > > > > > > > Speaking as the dude who founded the treecleaners project...all > things die. > > Even software. While some may yearn for a software archive (nee, > > graveyard!), I put forth that the gentoo-x86 tree is not such a > thing. Do > > not weep for the unmaintained packages that will be cleaned![1] > > I couldn't have said this better myself. The gentoo-x86 tree is not a > software archival service. If packages are unmaintained, that is what > the treecleaners project is for is to boot those packages out of the > tree. > > I would like to see a possible timelimit set on how long packages can > stay in maintainer-needed; once a package goes there, if we can't find > someone to maintain it, we should consider booting it after that time > limit passes. > > If someone wants to run the graveyard overlay and keep those old > packages around more power to them, but they definitely do not > belong in the main tree if they are unmaintained for an extended > period > of time. > > William > > There is no point in removing unmaintained but perfectly functional software from the tree. It needs to be both unmaintained and broken. Broken being evidenced by at least one open bug. How would you define unmaintained? Maybe its not changed for a year or two because there is no need for any maintenance? -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods trustees pgpjSgX2JV8mk.pgp Description: PGP signature
Re: [gentoo-dev] Hello Everyone
On 2015.02.22 12:05, Tushar Rajput wrote: I am novice programmer and wants to contribute to gentoo.Can you give me some details? Thanks Tushar, Welcome. Sign up to bugs.gentoo.org Find some bugs in your area of interest, fix them, test the fixes and post patches on the bugs. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods trustees pgpdW2SQKTl3b.pgp Description: PGP signature
Re: [gentoo-dev] ebuild copyright assignment
On 2015.02.18 07:40, Jeroen Roovers wrote: On Mon, 16 Feb 2015 06:39:51 -0500 Mike Frysinger vap...@gentoo.org wrote: the policy is not it must be Gentoo copyright, but it must have a header that says Gentoo copyright even though there's no legal basis for it. Correct, but I have my doubts about the allegedly wobbly legal basis. I do vividly recall reading these: http://www.gentoo.org/proj/en/devrel/copyright/index.xml http://web.archive.org/web/20040604022011/http://www.gentoo.org/doc/ en/policy.xml Copyright in ebuilds (and documentation) should always be assigned to Gentoo Technologies. Developers must never put their own names in copyright lines. For more information, please see http://www.gentoo.org/proj/en/devrel/copyright-assignment.xml http://web.archive.org/web/20040624223240/http://www.gentoo.org/ proj/en/devrel/copyright-assignment.xml (Page moved to http://www.gentoo.org/proj/en/devrel/copyright/index.xml http://web.archive.org/web/20040618235041/http://www.gentoo.org/ proj/en/devrel/copyright/index.xml) [snip] jer Here's some history ... Gentoo Technologies Inc. was interested in using the Gentoo codebase commercially. It was not a financial success and the assets of Gentoo Technologies Inc. were transferred to the Gentoo Foundation Inc. when drobbins left Gentoo. That would be about 2004, when the Foundation was established. Commercial use was easier if Gentoo Technologies Inc. held the copyright. Its unclear if anyone actually completed copyright assignment paperwork at any time. The legal standing of the ebuild header is also unclear as it has never been tested in court. The remaining idea behind it today is that it might ensure that the Foundation is the target of any legal action resulting from an ebuild and conversely can take legal action to defend an ebuild. I say 'might' as international copyright is a minefield. Its wider than just ebuilds, its wherever Foundation copyright is asserted. Both Gentoo Technologies Inc. and Gentoo Foundation Inc. were/are New Mexico legal entities, so are subject to New Mexico law. Of course, if you are not in New Mexico, or even the USA, that law may not apply to you and that's where the minefield starts. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods trustees pgpxPySl2nRlI.pgp Description: PGP signature
Re: [gentoo-dev] PowerPC status
On 2014.09.18 00:31, Jack Morgan wrote: Hello, The PowerPC development team has had our 2nd monthly meeting and I wanted to provide an update on where we are. [snip] I've sent email to the following devs but haven't head back yet so don't know your current status. Mark Loeser (halcy0n) Gysbert Wassenaar (nixnut) Michael Weber (xmw) [snip] Thanks, -- Jack Morgan Pub 4096R/761D8E0A 2010-09-13 Jack Morgan jmor...@gentoo.org Fingerprint = DD42 EA48 D701 D520 C2CD 55BE BF53 C69B 761D 8E0A I'm fairly sure nixnut retired. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods trustees pgpcclsP9iPTv.pgp Description: PGP signature
Re: [gentoo-dev] package.mask vs ~arch
On 2014.06.30 05:01, William Hubbs wrote: All, I am starting a new thread so we don't refer to a specific package, but I am quoting Rich and hasufell from the previous masking thread. On Sun, Jun 29, 2014 at 10:04:54AM -0400, Rich Freeman wrote: On Sun, Jun 29, 2014 at 8:36 AM, hasufell hasuf...@gentoo.org wrote: This is still too vague for me. If it's expected to be short- term, then it can as well just land in ~arch. A package that hasn't been tested AT ALL doesn't belong in ~arch. Suppose the maintainer is unable to test some aspect of the package, or any aspect of the package? Do we want it to break completely for ~arch? In that event, nobody will run ~arch for that package, and then it still isn't getting tested. I'm not saying that we should just randomly throw something into ~arch without testing it, but ~arch users are running ~arch with the understanding that their systems will break from time to time and they are expected to be able to deal with it when/if it happens. ~arch is not a second stable branch. I agree that masking for testing is like having a 3rd branch, but I'm not convinced that this is a bad thing. ~arch should be for packages that have received rudimentary testing and which are ready for testing by a larger population. Masking should be used for packages that haven't received rudimentary testing - they might not have been tested at all. The concern with this argument is the definition of rudimentary testing is subjective, especially when a package supports many possible configurations. I think some packages need wide testing before they go stable, and that is where ~arch can help out. In particular, I would argue that for system-critical packages, users should be very careful about running ~arch unless they know what the fallout can be. *snip* I guess the question is, what exactly are we trying to fix? Even if occasionally a maintainer drops the ball and leaves something masked for a year, how is that different from a maintainer dropping the ball and not adding a new release to the main tree for a year? Would we be better off if Docker 1 wasn't in the tree at all? If it happened to have a known issue would ~arch users be better off if some other dev came along and helpfully added it to the tree unmasked no realizing that somebody else was already working on it? Take a look at profiles/package.mask. You will see many packages in there with the description, masked for testing on their masks, with no bug references, that have been there for multiple years. My view is we should either get those masks resolved or boot the affected packages/versions out of the tree. If they haven't received rudimentary testing by now, it is pretty obvious that no one cares about them. William Once upon a time, not so long ago I don't remember it, there were very few overlays. At that time, there was always a lot of packages in the tree masked for testing. At that time, well before layman, overlays were inconvenient. As overlays have become more widespread and used as a way to lower the barrier to contributing directly to Gentoo, there are fewer packages masked for testing. I like the old way, it avoids installing yet another overlay but clearly others feel differently or there would not be so many overlays to choose from. The reality is, both ways work for me. Pragmatically, its not practical to merge all of the overlays into the tree, then ban overlays. That would be a return to the old way. This just represents a change of workflow with time. The question then is do we need to formalise the changed workflow, or can both be allowed to continue side by side? -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods trustees pgpwJVV2X65ZZ.pgp Description: PGP signature
Re: [gentoo-dev] package.mask vs ~arch
On 2014.06.30 16:40, Ian Stakenvicius wrote: On 30/06/14 11:36 AM, Michał Górny wrote: [snip] But... if you unmask it, someone will test it and report whether it works :P. But... if I unmask it, -everyone- using ~arch will install it and it'll break all the systems that it doesn't work on, which -could- be quite a lot at this point. :D Yep. The good old days ... X11 going modular ... expat-2 and a few others that I've forgotten. There was no news then so if you missed an email to the list you got to pick up the pieces. Those examples may well be me missing emails. I've run ~arch since mid 2002 and until the last few years always had a few builds fail or things build then operate so badly they needed to be p.masked locally. That's what buildpkg is for ... so that after you spend 10 hours building *office and find out its a dud, you can back it out in a few minutes. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods trustees pgpjfKriB3eLY.pgp Description: PGP signature
Re: [gentoo-dev] RFC: using .xz for doc/man/info compression
On 2014.05.12 10:35, Tom Wijsman wrote: On Sun, 11 May 2014 19:46:50 +0200 Michał Górny mgo...@gentoo.org wrote: Rationale: xz-utils is quite widespread nowadays and it is a part of @system set. It can achieve better compression ratio than bzip2, and faster decompression at the same time. Some thoughts: What about putting multiple doc / man / info files in a single .xz file for each package? Would that further improve the situation? (As they can share dictionary, instead of having multiple dictionaries) Some algorithms tend to work better for smaller files, whereas others work better for larger files; might this be the case for bzip2 vs. xz? -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D Some more thoughts ... What about not compressing files smaller than the filesysem block size at all. In my case its 4k. Any file gets allocated 4k on disc anyway, so compression/decompression is just a waste of resource for files =4k. I'm not suggesting dynamically determining the output filesystem block size (unless you really want to), choose a static limit below which compression will not be applied. That eliminates the discussion about small files. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods trustees pgpN77XN8fctg.pgp Description: PGP signature
Re: [gentoo-dev] Possibility of overriding user defined INSTALL_MASK from an ebuild?
On 2014.02.28 14:44, Samuli Suominen wrote: On 28/02/14 16:18, Tom Wijsman wrote: On Fri, 28 Feb 2014 15:28:30 +0200 Samuli Suominen ssuomi...@gentoo.org wrote: It would be very helpful if INSTALL_MASK could be overriden from an ebuild, ... What is the intended goal? Can you give an example? - User has INSTALL_MASK=/lib/systemd - Ebuild has INSTALL_MASK_OVERRIDE=/lib/systemd/systemd-udevd /lib/systemd/network - Portage's default is to respect ebuild first, then users setting, unless he changes INSTALL_MASK_ORDER to respect his I completely agree using INSTALL_MASK is 100% responsibility of the user setting it, it's like blind 'rm -f', but some people don't agree and keep attacking me. I'm using the word attacking because it's constant, relentless, repeating and I don't see an end to it. I believe Poly-C just proofed that point in this thread. Samuli, You can't win this one. Consider ln -s /dev/null /lib/systemd/ or whatever. It achieves the same thing and you can't override it unless you also remove the symlink. INSTALL_MASK means I_KNOW_WHAT_IM_DOING_AND_AM_PREPARED_TO_KEEP_THE_PIECES systemd and the components it has sucked in has become the centre of a religious war with Zelots on both sides. All an INSTALL_MASK_OVERRIDE would do is escalate the war. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods trustees pgpLFfXk4wQ0s.pgp Description: PGP signature
Re: [gentoo-dev] Question, Portage QOS
On 2014.01.10 16:48, Igor wrote: Hello All, Thank you for all our feedback! [snip] -- Best regards, Igor mailto:lanthrus...@gmail.com Igor, You don't need anyones permission to start an OSS project. Just do it. If its useful, it will get used. Here, you will be met with almost total apathy because the reality is that most subscribers to this list won't respond until you have a working demo that they can play with. quote First they ignore you, then they laugh at you, then they fight you, then you win. Mahatma Gandhi /quote Good luck. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods trustees pgpE_PYpv0WRt.pgp Description: PGP signature
Re: [gentoo-dev] RFC: New project: Licenses
On 2013.11.22 09:38, Ulrich Mueller wrote: On Thu, 21 Nov 2013, Roy Bamford wrote: Indeed, that's one of the two TLPs that were suggested. The past QA disliked having Licenses as their subproject, though. It depends on how the role of QA is defined: If it is seen as primarily technical, then Licenses (which is largely non-technical) doesn't fit so well. ... or maybe a sub committee of the Gentoo Foundation Inc? because of the non technical and legal implications of the work. Trustees get involved with licence corner cases anyway, so a team of advisors would be a good fit. I'd rather avoid the term advisors, because we're no lawyers and therefore cannot give any legal advice. Accepted. Licenses already uses the trustees when legal advice is required. It it clear that in some cases the licenses team will escalate issues to the trustees and not to the council. Nevertheless, I see a project (TLP or sub-project) as a good enough fit. So no need to invent new structures for us. The main goal of having a project page is to increase our visibility and to have a convenient starting point for organising our information in the wiki. Ulrich The Foundation bylaws already allow for committees, none have been created yet but it would not be inventing a new structure. None of this has anything to do with Licenses having a project page or not. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods trustees pgp5yUWdCMgGZ.pgp Description: PGP signature
Re: [gentoo-dev] RFC: New project: Licenses
On 2013.11.21 15:21, Ulrich Mueller wrote: On Thu, 21 Nov 2013, hasufell wrote: For the time being, it will be listed as a top-level project. (There were some ideas that Licenses could be a subproject of another TLP, but so far this hasn't worked out.) It should be a subproject of QA. Indeed, that's one of the two TLPs that were suggested. The past QA disliked having Licenses as their subproject, though. It depends on how the role of QA is defined: If it is seen as primarily technical, then Licenses (which is largely non-technical) doesn't fit so well. Ulrich ... or maybe a sub committee of the Gentoo Foundation Inc? because of the non technical and legal implications of the work. Trustees get involved with licence corner cases anyway, so a team of advisors would be a good fit. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods trustees pgpbmaaTdiQIB.pgp Description: PGP signature
Re: [gentoo-dev] keep a gen 2013 snapshot on mirrors
On 2013.11.13 19:12, Rich Freeman wrote: [snip] Going back in time with portage is the easy part - it is in CVS. The real problem is all the distfiles themselves, especially things like out-of-tree patch tarballs hosted by devs. Rich Rich, The GPL obliges us to keep such patches around for three years, iirc. Don't we do that ? -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods trustees pgpWUwOIhL2tc.pgp Description: PGP signature
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
On 2013.08.07 13:45, Michael Weber wrote: Greetings, Gnome Herd decided to target stablilization of 3.8 [1] which requires systemd. [snip] Michael [1] https://bugs.gentoo.org/show_bug.cgi?id=478252 -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber x...@gentoo.org The Gnome team has made their choice. I'm the light of that, users can now make their own choices. That's what Gentoo is about after all ... choice. I fully support the Gnome teams choice ... now I have to make one of my own. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods trustees pgpav7ZqUzrXc.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-dev-announce] OpenRc-0.12 is coming soon
On 2013.08.03 16:28, William Hubbs wrote: [snip] Ok all, I would like to appologise for the harsh wording. Markos, to answer your question, there are folks on the team, and at least one user, using OpenRc from git without issues, so as far as I know there shouldn't be any breakage. I guess I was a little more harsh than I should have been, because I know there are users out here who want ~arch to be rock solid, and I have caught flack before from some of that crowd. William ~arch is not rock solid and isn't supposed to be. I do like Williams approach to posting a warning about the upcoming change so I cam manage it for myself, if I'm feeling nervous. Any notification of key packages changing like this is appreciated. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods trustees pgpdJ1Fe7qHuW.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-dev-announce] Council constituent meeting 30 July 2013 at 19:00 UTC
On 2013.07.22 22:51, Rich Freeman wrote: On Sun, Jul 21, 2013 at 4:20 PM, Roy Bamford neddyseag...@gentoo.org [snip] Please keep voting in public. Its good for accountability. If not in IRC, find a way to publish who voted and now. Council do not get a secret ballot. Agreed. I don't think the intent of that item was ever to REPLACE in-person voting with email. I think the intent was to allow for it so that when a critical issue comes up a week after the agenda is already set that everybody doesn't have to wait 5 weeks for the following council meeting. It seems really odd to have a 100-post flamewar with no immediate action, and then to dredge up the topic a month later and vote, and then have another 100-post flameware to talk about the outcome. I don't think we need off-the-cuff decisions, but if a topic is ripe for a decision we should have a way to actually take care of it. Public debate and votes only make sense. Bugs might be a useful way to record this (much as is done with the trustees). Rich Rich, I'm fine with voting via email when its needed, or even all the time as long as the votes are published. You have addressed my concern. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods trustees pgpX4NSfPCVC0.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-dev-announce] Council constituent meeting 30 July 2013 at 19:00 UTC
On 2013.07.23 01:57, Rick Zero_Chaos Farina wrote: [snip] I think the real difference [between the foundation and council] is that most of the devs don't care what the foundation does as long as it keeps the lights on around here. Most of us, on the other hand, seem to care greatly about the development process and key decisions around that. If the trustees need to take emergency action to keep the lights on I trust them to do the right thing. If the council has to take emergency action to allow systemd units to be added without maintainer approval well, you see how stupid that sounds? -Zero [snip] Rick, The council should not be denied the ability to reach decisions between meetings for the few times it will actually be needed. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods trustees pgpkeMSUUdHPC.pgp Description: PGP signature
[gentoo-dev] Re: [gentoo-dev-announce] Council constituent meeting 30 July 2013 at 19:00 UTC
On 2013.07.21 15:30, Andreas K. Huettel wrote: Hello everybody, [snip] - vote for holding meetings every 2nd Tuesday of the month at 2000 UTC (or 1900 UTC depending on daylight savings) In any timezone in particular? [snip] 1: the open floor is the mailing list discussion, i.e. no open floor during the meeting anymore The open floor is a part of the openness and approachability of the council. Its 60 seconds well spent, even if nobody says anything. - vote on meeting format 2: shift council votes to mail instead of IRC Please keep voting in public. Its good for accountability. If not in IRC, find a way to publish who voted and now. Council do not get a secret ballot. [snip] - general discussion on the introduction of a Bikeshed of the month (basically the plan to tidy off one unresolved mailing list discussion each month) Ok, so what colour should it be? [with apologies to Douglas Adams] [snip] Best, Andreas -- Andreas K. Huettel Gentoo Linux developer (council, kde) dilfri...@gentoo.org http://www.akhuettel.de/ -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods trustees pgpOBoQV65j2k.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo Hangouts
On 2013.06.23 22:30, Pavlos Ratis wrote: Hello all, Everyday we talk to each other about different kind of things related to Gentoo. IRC and MLs are the primary way of our communication, but this is only a text-based communication. I think sometimes it would be better to escape from that. [snip] Pavlos I think audio might be useful but video won't add very much and for some topics, will just be a distraction. Having used both video and audio conferencing to span the world since ISDN was new, once you get more than about three or four participating nodes, control becomes difficult ... that's not changed over the years. Accents are a problem even among native English speakers and by that I mean British English from England, not even the entire UK. Heres a test for you ... http://linuxcrazy.com/?q=node/26 I have a South West England accent ... can you understand me? -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods trustees pgpbYloqrAwkT.pgp Description: PGP signature
Re: [gentoo-dev] Temporary DevRel actions for CoC violations
On 06/19/13 18:35:49, Markos Chandras wrote: Hi, It is unfortunate to observe constant bullying, insults and trolling across our public media. Developers have been warned over and over that such behaviour is not acceptable and they should try to behave properly. However, people have ignored such warnings for a very long time. This ends today. [snip] -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang This has my support. I would like to see council voice their complete support publically too, as thats one of the reasons proctors failed. -- Regards, Roy Bamford (Neddyseagoon) an member of gentoo-ops forum-mods trustees
Re: [gentoo-dev] news item -- baselayout-1.x deprecation final warning
On 2013.04.07 20:36, William Hubbs wrote: All, We have continued support for baselayout-1 to baselayout-2/OpenRc migration for almost two years now, so I think it is about time we kill this off. Here is the news item I want to send out on 10 Apr. Let me know what you think. Thanks, William quote If you do not upgrade your systems to openrc-0.11.8 before it leaves the tree, you may need to reinstall them. /quote I think you mean If you do not upgrade your systems to baselayout-2 and openrc-0.11.8 before openrc-0.11.8 leaves the tree, you may need to reinstall them. The problem is with baselayout-1 and that's what needs to be updated. The you may need to reinstall them is a bit over the top. You can always pick up the pieces with a liveCD. Do you need to point out that the old ( ... ) syntax will no longer be supported, or do you intend to tolerate the baselayout-1 syntax in /etc/conf.d/net and friends a while longer. A friendly link to the update guide http://www.gentoo.org/doc/en/openrc-migration.xml may be in order too. I've seen many users on baselayout-2 with baselayout-1 net files. This news item will bypass them. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods trustees pgpUphhQvpZpg.pgp Description: PGP signature
Re: [gentoo-dev] Re: Gentoo Bugday
On 2013.02.28 02:14, Pavlos Ratis wrote: @neddyseagoon: Yeah it would be great to have it back, I think the day should remain as is. Every first Saturday of every month. Thanks. [snip] Pavlos, https://forums.gentoo.org/viewtopic-t-952608.html Poke me the weekend before bugday and I'll do the forums announce. Eventually, it will be a habit. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods trustees pgppEk_DtZefo.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo Bugday
On 2013.02.27 00:39, Pavlos Ratis wrote: Hello everyone, I would like to announce you a new try to 'revive' the Bugday event. As most of the open source projects have their own bugday, I thought it would be great to have this event back. For those who don't know, its a monthly 24h event that takes place in #gentoo-bugs. Its goal is to close as many bugs as possible . You don't have to be a Gentoo expert to participate. Those days are a great way to start joining the Gentoo community, improving Bugzilla's and Wiki's quality and looking for a mentor to begin the recruitment process. The upcoming bugday event is this Saturday and I hope this event will continue in the next months. I have created a wiki page for the event[1] and I added some guidelines. I have also created a related blog post about the event[2]. I have listed some maintainer-wanted and maintainer-need bugs and Bugzilla admins also re-enabled the bugday flag. I would like to ask the Gentoo project teams to start using this flag to their bugs that think that are good to start and enable the flag at them. It would be great to a have a really big list with 'good to start' bugs. It's the first time after a long time that this event will take place, so I am looking forward to your participation both users and developers and your feedback. [1] http://wiki.gentoo.org/wiki/Bugday [2] http://blog.dastergon.gr/gentoo-bugday/ Thanks, Pavlos Pavlos, I used to do a forums announce for the old bugday. That can be revived too if you want. The old bugday ran to a calender, so the announces went up a week beforehand. Are you goings to stick to the first Saturday in the month ? Good luck with the revived bugday. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods trustees pgpkDEzO0Yr7K.pgp Description: PGP signature
Re: [gentoo-dev] Re: linux-firmware
On 2013.02.21 23:18, Rich Freeman wrote: On Thu, Feb 21, 2013 at 5:44 PM, Greg KH gre...@gentoo.org wrote: This should be a cross-distro issue/solution, so I suggest working with the Linux Foundation on this. Anyone object to me doing that? Go for it (speaking only for myself, but I can't imagine the other Trustees would be opposed)! Rich Works for me too, so thats a majority vote of Trustees. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods trustees pgpJWmB3h542p.pgp Description: PGP signature
Re: [gentoo-dev] Attracting developers (Re: Packages up for grabs...)
On 2013.01.05 05:47, Donnie Berkholz wrote: On 10:43 Mon 17 Dec , Markos Chandras wrote: On 16 December 2012 18:53, Andreas K. Huettel dilfri...@gentoo.org wrote: How to do this, however, and what software to target should probably be decided by people who know more than me... and in the end it all boils down to who has the time and motivation. Outsource it to someone who has the knowledge and interest in doing this. The foundation has the funds to support it, and none of us actually have the time to invest in a complete webpage redesign. I did much of the design work nearly 2 years ago: http://dev.gentoo.org/~dberkholz/gentoo_website/ gentoo_landing_black.png http://dev.gentoo.org/~dberkholz/gentoo_website/ gentoo_landing_install.png http://dev.gentoo.org/~dberkholz/gentoo_website/ gentoo_landing_handbook.png http://dev.gentoo.org/~dberkholz/gentoo_website/ gentoo_landing_handbook2.png Some early work on it using Bootstrap: http://a3li.li/~alex/g.o/ That said, why the hell are we wasting time implementing our own website backend when we should be using a CMS? We're here to make a distro, not a website framework. No reason we should care, day to day, about anything but frontend theming and content. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com Analyst, RedMonk http://redmonk.com/dberkholz/ Donnie. We make our own website framework for the same reason that everything else happens in Gentoo. Someone is interested in doing it. I agree its not 'core business' but Gentoo isn't a business. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods trustees pgpdIQacGgwHH.pgp Description: PGP signature
Re: [gentoo-dev] What did we achieve in 2012? What are our resolutions for 2013?
On 2012.12.31 14:17, Ben de Groot wrote: Happy New Year to all of you! Looking back at 2012, I wonder what we consider our achievements for this past year. What is the state of Gentoo? How have we brought it forward and improved it this past year? And what do we want to see in the coming year? How can we make Gentoo more awesome in 2013? I will add my own thoughts later. I first would like to hear from you. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin Ben, I'm older and more cynical than most on this list. In my mind, improvement means change but change is not always improvement. I'll summarise it in a post French revolution saying ... Plus ça change, plus c'est la même chose. What would make Gentoo more awsome next year? Getting more devs on board so existing things can move faster. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods trustees pgpZ5eIcZFAXC.pgp Description: PGP signature
Re: [gentoo-dev] gen_usr_ldscript --libdir=/lib
On 2012.12.27 22:13, William Hubbs wrote: On Thu, Dec 27, 2012 at 03:14:37PM -0500, Rich Freeman wrote: Something I don't like about this whole debate is that it tends to come off as I've never run an initramfs and darn it I want to keep it that way. Gentoo has always been a cutting-edge/innovative distro. We have prefix, hardened, x32, and we were among the first to support amd64. Sure, that flexibility also lets you get away without an initramfs where other distros simply cannot. However, the lack of an initramfs should not be a crutch. Rich, you just hit my concern about this debate right on the head. I feel like the nay-sayers are opposed to it because of the FHS, and the idea of critical software going in / and everything else in /usr. The attitude seems to be that has always worked, so it must continue to work into the future, with no regard to the advantages that moving everything to /usr would give us. Another concern I've heard says that we shouldn't do this on linux because gentoo *bsd doesn't do it. I don't see that as relevant because ebuilds can be smart enough to test whether they are being emerged on Linux or *BSD. William I don't think the 'luddites' have quite so black and white a view as that but if I expand on it much more, I'll reignite a flamewar we have already had. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods trustees pgpM7U4Uf69D8.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-dev-announce] Soliciting Feedback: Gentoo Copyright Assignments / Licensing
On 2012.12.21 23:57, Greg KH wrote: On Fri, Dec 21, 2012 at 12:01:00AM -0500, Rich Freeman wrote: On Thu, Dec 20, 2012 at 11:08 PM, Greg KH gre...@gentoo.org wrote: On Fri, Dec 21, 2012 at 02:32:25AM +, Robin H. Johnson wrote: 1. Are you party to any *copyright assignment* (eg FSF copyright assignment)? You need to rephrase this to be (in order for it to make any sense): Are you party to any *copyright assignment* that is not part of your employment agreement? Otherwise, everyone in the US, and most other countries, would almost always have to just say yes to this, as their employer owns the copyright for their work no matter what it is done on (open source or not.) Work done for hire is certainly owned by the employer, unless an agreement to the contrary is explicitly documented, but employment agreements that purport to assign copyright for works unrelated to employment to the employer are rare. Maybe they're not as rare in the software industry, but most people aren't employed in the software industry (even if most Gentoo developers might be - though perhaps not as a big a majority as you might expect). Certainly I haven't signed any kind of document that assigns ownership of works created on my own time to my employer, and the legality of any contract I did sign to that effect would be dubious. That's not true in the US, in fact, it's the exact opposite. Your employer has ownership of all of your work, even done on your own time, unless you explicitly have permission otherwise, if it is done in an industry that is related to your employer. Read the traditional US employment agreement for details about this. Yes, some states allow for exceptions to this rule, but those are the exceptions (California has some unique changes here). You might have signed these types of agreements when you were hired by a company, and didn't realize it, it's usually quite well hidden in the agreement. Now this is all for the US, Europe has other types of laws, but they still assign ownership/copyright of what you do while being paid by those companies, to the company, and not to you. Again, there are exceptions, but traditionally that is how they work. Remember, in the US, individuals who actually own the copyright on the work they do is quite rare once they get out of college, and even then, while in college, the school does have the right to assert copyright ownership of the work, depending on what it was done on/for (who provided the equipment, tasks, etc.) [snip] This is typical for the UK too. My present employer regards my role in the Gentoo Foundation as 'employment'. I had to show that there was no conflict of interests before I took up my paid job. General UK employment contracts go much further than copyright and normally extend to any and all inventions created by the employee, including inventions made in their own time with their own resources. thanks, greg k-h -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods trustees pgpom4yRBTmZ3.pgp Description: PGP signature
Re: [gentoo-dev] College Course in Gentoo Development
On 2012.12.17 16:02, Rick Zero_Chaos Farina wrote: On 12/17/2012 10:32 AM, Anthony G. Basile wrote: Hi everyone, Give the talk on the list about attracting devs, I've should probably mention that I'm teaching a College Course on Gentoo Development [snip] Can I take this course online? Will the lectures be recorded? -ZC I would be interested in an online version too. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods trustees pgpNo4gexStsn.pgp Description: PGP signature
Re: [gentoo-dev] Attracting developers (Re: Packages up for grabs...)
On 2012.12.17 15:15, Markos Chandras wrote: On 17 December 2012 12:31, Dirkjan Ochtman d...@gentoo.org wrote: On Mon, Dec 17, 2012 at 11:43 AM, Markos Chandras hwoar...@gentoo.org wrote: Outsource it to someone who has the knowledge and interest in doing this. The foundation has the funds to support it, and none of us actually have the time to invest in a complete webpage redesign. If we have funds for this kind of thing, the PSF process is a good example: http://pythonorg-redesign.readthedocs.org/en/latest/ (And I think that would be a great idea.) Cheers, Dirkjan I believe this is something that this[1] project needs to decide and set it in motion. [1]http://www.gentoo.org/proj/en/pr/website.xml -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 To make this project a suitable project for Foundation funding, it needs a clearly defined specification that can be circulated for interested parties to provide fixed price quotations against. The specification provides several things:- 1. the scope of work (out of scope work is extra cost) 2. the basis to judge completion (so we pay the fee) 3. some guidance as to implementation details I know that 3. is unusual in a requirement specification but in this case it is unlikely that the Foundation would fund ongoing mainatainace, so we would need to dictate a few implementation details. e.g. no Flash, Gentoo colours, Its worth contrasting this sort of thing with a bug bounty. The requirement is easy - fix the bug. Judging completion is fairly straight forward too. The patch is accepted by $UPSTREAM. The requirement specification for a website is a lot of work by comparison. Suppose the team in [1] above wrote the specification, who needs to agree it? The council, the trustees, the body of devs ... some combination of that list. All in all, producing an agreed specification for a website it probably as much work as actually building the site. It could easily be as much work as the PMS. Anyway, I'm rambling a little. In summary, if we decide to outsource the website project, it needs to be carefully controlled. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods trustees pgpTJWDmoCdNZ.pgp Description: PGP signature
Re: [gentoo-dev] eudev project announcement
On 2012.12.15 03:52, Richard Yao wrote: Dear Everyone, I am pleased to announce the Gentoo eudev project. [snip] Yours truly, Richard Yao [snip] I welcome the choice that this new project brings, that's what Gentoo is about - choice. I wish eudev both good luck and success. Success comes in many forms, so I won't try to predict exactly what that means. Suffice to say, we will all recognise it when we see it. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods trustees pgpXmthqMgHAa.pgp Description: PGP signature
Re: [gentoo-dev] fixing LICENSE issues without reporting bugs
On 2012.11.25 13:44, Ulrich Mueller wrote: On Sun, 25 Nov 2012, hasufell wrote: License issues seem trivial enough (at least regarding the functionality of an ebuild) to be fixed without permission of the actual maintainer. Certainly there are trivial license issues, but not all of them are. See bugs 436452 and 441734 for trivial examples, and bugs 440938 and 12 for non-trivial ones. I think that it's better if bugs are filed for the second category, so that the change will be traceable. Also the maintainer should at least be informed in case the LICENSE change would remove the package from the @FREE license group. Even if the fix is wrong the ebuild remains intact. If someone feels uncomfortable about this proposal we could limit this permission to the license herd. Less bugs, quicker fixes. For the remaining trivial cases I'm fine with it either way. And there's no reason to limit the permission to the licenses team. Ulrich From the point of view of the licencor, the licence is just as important as the code, so there are no trivial licence issues. As a trustee, I am unhappy with losing the traceability at all. Other trustees may have different opinions. What seems trivial today, may not be trivial tomorrow if a licencor gets upset. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods trustees pgpnkQh05fT1u.pgp Description: PGP signature
Re: [gentoo-dev] fixing LICENSE issues without reporting bugs
On 2012.11.25 14:42, Rich Freeman wrote: On Sun, Nov 25, 2012 at 9:30 AM, Roy Bamford neddyseag...@gentoo.org wrote: From the point of view of the licencor, the licence is just as important as the code, so there are no trivial licence issues. As a trustee, I am unhappy with losing the traceability at all. Other trustees may have different opinions. Not this one. License issues can vary in severity, and there may be nuances that an outsider might not appreciate. [snip] Rich Rich, That's my point - something serious may slip by without a bug. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods trustees pgpDPB0T8VgC0.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: virtual/libudev
On 2012.07.27 03:37, Duncan wrote: [snip] Not that such promises hold much credibility anyway... see the kde promise (from Aaron S when he was president of KDE e.v. so as credible a spokesperson as it gets) continued kde3 support as long as there were users. (AFAIK, at least gnome didn't make /that/ sort of promise in the leadup to gnome3. And no, AS cannot be properly argued to have been referring to others, like debian with its slow release cycles, as he was president of kde ev, not president of debian, or of the trinity project, which AFAIK didn't even exist at the time, and didn't specify support from OTHERS, not kde, so he was clearly speaking for kde, not for other entities.) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman Duncan, You don't want to listen to Presidents too much. Look at other real life examples. Would you claim that the President of the Gentoo Foundation speaks for Gentoo? -- Regards, Roy Bamford (Neddyseagoon) Gentoo Foundation Inc. (President)
Re: [gentoo-dev] Re: Killing UEFI Secure Boot
On 2012.06.21 16:05, Richard Yao wrote: On 06/21/2012 11:00 AM, Ian Stakenvicius wrote: A firmware replacement for the BIOS does not need to worry about floppy drives, hard drives, optical drives, usb devices, isa devices, pci devices and pci express drives, etcetera, because those live on buses, which the kernel can detect. It would need a device tree to inform the kernel of what buses are available, but that would be specific to a given board, rather than what is attached to it. If the end user makes hardware changes, the kernel should be able to handle that, with the exception of changes involving RAM, which I believe go into the device tree. I take it the above statement is based on the kernel being directly placed within the BIOS/firmware/nvram on the board, such that you couldn't boot anything else but that kernel? That is correct. [snip] So when you build a dud kernel and flash your BIOS with it, and we all build the odd dud, your motherboard is bricked. Now what? Get out your JTAG adaptor and another PC I suppose. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods trustees pgp8XbNre5giw.pgp Description: PGP signature
Re: [gentoo-dev] Re: New license: yEd Software License Agreement
On 2012.04.27 18:38, Rich Freeman wrote: [snip] Do we as a matter of policy want to respect broken click-through download implementations? Rich Yes we do. Intent it what counts in the eyes of the law in most places. Sites with broken click-throughs intend for them to be used. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods trustees
Re: [gentoo-dev] rfc: location of portage tree
On 2012.03.28 08:46, Alex Alexander wrote: On Tue, Mar 27, 2012 at 02:05:54PM -0500, William Hubbs wrote: All, I know this has come up before, but I don't really recall what the specific objections were. IMO the portage directory doesn't belong under /usr at all. [snip] William If/when this happens, we should also consider improving the internal structure of the portage folder. At the moment we just throw everything in it, which is not very user friendly. I recommend creating a subfolder for the actual tree, keeping distfiles and packages out. For example, my /usr/portage/ on this system looks like this: portage/ tree/ profiles/ - tree/profiles/ distfiles/ packages/ layman/ it is a big improvement over the current distfiles-and-packages-mixed-with-tree-while-layman-wanders state :) -- Alex Alexander | wired + Gentoo Linux Developer ++ www.linuxized.com Lets move packages/ out of there. I share /usr/portage over NFS to several different arches. Sharing /usr/portage/packages is a really bad idea in that set up. As they all run ~arch, they all build packages so I can downgrade quickly. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods trustees
Re: [gentoo-dev] rfc: location of portage tree
On 2012.03.28 20:04, Rich Freeman wrote: On Wed, Mar 28, 2012 at 2:53 PM, Christoph Mende ange...@gentoo.org wrote: I believe it's /var/lib/name. Here's what FHS says: /var/cache is intended for cached data from applications. Such data is locally generated as a result of time-consuming I/O or calculation. The application must be able to regenerate or restore the data. Unlike /var/spool, the cached files can be deleted without data loss. I can do rm -rf /usr/portage ; mkdir /usr/portage ; emerge --sync and it will work just fine, I think. That's pretty much what happened in a stage1 or stage2 install. Its not cache though as you don't get back the same data as was deleted. Think 6 month old install. That really does point to cache. The only thing different from a browser cache is that portage doesn't automatically refresh it. distfiles and packages are the same (well, depending on where you get your binpackages from, that might or might not be a cache per-se - if you're just using FEATURES=buildpkg then you can do an emerge -e world and get it back). Nope. If you have just done rm -rf /usr/portage ; mkdir /usr/portage ; emerge --sync, then emerge -e world gets you the equivelent of emerge --sync emerge world -uDN Even if you haven't fetched a new tree, you have lost all your old binary packages, which you were keeping in case of a broken ~arch upgrade that needs to be reverted in a hurry. e.g. one of the nice big shiny packages that emerge -e world just updated for you. [snip] Rich -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods trustees
Re: [gentoo-dev] License for Google Chrome
On 2011.08.26 23:06, Mike Gilbert wrote: I have been maintaining an ebuild for Google Chrome in an overlay. It basically extracts a deb file to /opt. This serves as an easy alternative for people who do not have the patience to compile Chromium. Now that I have developer access, I would like to move this to the tree. Before doing so, I need some advice on how to deal with the EULA[1]. I think clause 2.2 (B) allows me to avoid a fetch restriction. I think clause 5.3 prohibits mirroring. Do I need to worry about anything else here? [1] http://www.google.com/chrome/intl/en/eula_text.html Mike, You will need to add the licence to the tree as its a EULA. The package will need to be masked by the licence. If Google provide a click through licence agreement, complying with clause 2 is out of our hands. If not, licence masking should ensure that users read the licence before they install and subsequently use the package. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods trustees pgppbhFEDuhtW.pgp Description: PGP signature
