Re: [gentoo-dev] Repo mirror & CI project news: 'stable' gentoo branch, new repo stats, faster CI

On 6 June 2016 at 04:49, rindeal wrote: > I'd like to see the master branch free of commits which do not pass > CI, instead of having broken commits and holding master back until > revert commits are introduced. Just pretend "stable" is called "master" and pretend "master" is called "devel" ->

Re: [gentoo-dev] Repo mirror & CI project news: 'stable' gentoo branch, new repo stats, faster CI

On 6 June 2016 at 05:09, rindeal wrote: > It is not, unless CI filters the broken commits in some miraculous > way. With the current approach, both stable and master branch will > contain the pollution of broken commits + their fixes, instead of > having good commits only. Doing that is of cours

Re: [gentoo-dev] Repo mirror & CI project news: 'stable' gentoo branch, new repo stats, faster CI

On 6 June 2016 at 05:34, rindeal wrote: > efore merging to master they do a rebase+force push, > let the CI check it, and if it passes they're allowed to merge it. No > cherry-picking involved. Master is then always clean and happy. I'm > not sure how well it scales, but for the 100-150 commits/da

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

On 17 June 2016 at 00:51, Michał Górny wrote: > We could also use plain 'OPEN' ;-). +1. I was going to suggest the same. -- Kent KENTNL - https://metacpan.org/author/KENTNL

Re: [gentoo-dev] [RFC] 'Gentoo Linux' bugzilla component reorganization

On 17 June 2016 at 00:04, Michał Górny wrote: > Revision two: > > - Current packages [bug-wranglers@], > - Eclasses [bug-wranglers@], > - Hardened [hardened@], > - New packages [bug-wranglers@], > - Overlays [overlays@], > - Profiles [bug-wranglers@], > - SELinux [selinux@]. "Overlays" seems a l

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

On 17 June 2016 at 01:52, Joshua Kinard wrote: > because > sometimes, issues can get reported that are really obscure and, for example, > tied to a particular hardware configuration, thus cannot be easily and > independently confirmed Isn't that why "RESOLVED: Need Info" exists? Or is "CONFIRME

Re: [gentoo-dev] [RFC] bugs.g.o: Killing VERIFIED state, possibly introducing STABILIZED

On 17 June 2016 at 01:02, Michał Górny wrote: > VERIFIED is used scarcely, and not really consistently. It can only be > used on RESOLVED bugs, and sometimes users use it to confirm that > the bug is resolved. Its also worth pointing out VERIFIED status annoyingly restricts a package, and so any

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

On 17 June 2016 at 06:05, Marc Schiffbauer wrote: > How about "ON HOLD: Need Info" instead? "STALLED" is better for me than "ON HOLD". But I can't really see much value in such a breakdown unless we can find at *least* 2 sub-categories of "STALLED" -- Kent KENTNL - https://metacpan.org/auth

[gentoo-dev] Last rites: dev-perl/Test-use-ok

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 # Kent Fredric (17 Jul 2016) # Contents superseded by virtual/perl-Test-Simple >=1.1.10 # and now only creates depdendency resolution headaches. # # Please migrate overlay dependencies to an exclusive # >=virtual/perl-Test-Simple-1.1.10 # # R

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

On Mon, 18 Jul 2016 22:21:22 -0400 waltd...@waltdnes.org wrote: > I'm amazed that "robust linux servers" are deathly afraid of simply > setting the time, and being done with it. There's problems at the software level everywhere that are not so simply solved. A more obvious example is in the ev

Re: [gentoo-dev] [PATCH] versionator.eclass: Add tests for parameter counts

On Sun, 24 Jul 2016 12:17:56 +0200 Michał Górny wrote: > So what's the alternative? Design another eclass where ebuilds will > fail just the same because people will ignore the more explicit > requirement just the same as they do ignore the API? Sometimes you don't need a "new path", you just ne

[gentoo-dev] Last rites: dev-perl/Test-Tester

# Kent Fredric (3 Aug 2016) # Contents superseded by virtual/perl-Test-Simple >=1.1.10 # and now only creates depdendency resolution headaches. # # Please migrate overlay dependencies to an exclusive # >=virtual/perl-Test-Simple-1.1.10 # # Removal in 30 days. Bug 584238 dev-perl/Test-

[gentoo-dev] Last Rites: dev-perl/cdk-perl

# Kent Fredric (3 Aug 2016) # No reverse dependencies, was never clear why it was in tree, # upstream stagnant, dev-libs/cdk is mostly unmaintained. # # Please voice concerns on bug 575036 if you still need this. # Removal in 30 days. dev-perl/cdk-perl pgpWMkH4XTW08.pgp Description: OpenPGP

Re: [gentoo-dev] Re: Packages up for grabs

On Sat, 6 Aug 2016 19:28:19 + Peter Stuge wrote: > Michał Górny wrote: > > Or file a pull request @ https://github.com/gentoo/gentoo/pulls. > > That's the most convenient solution for most of proxy-maint team > > members. > > How can I help improve that problematic situation? > > It's not

Re: [gentoo-dev] Re: Packages up for grabs

On Sun, 7 Aug 2016 08:24:51 -0500 james wrote: > > As a team, we could have a simple default program for a simple default > disk format, and a variety of 'stage-4' images, maybe updated every 3 > months, to get a gentoo system up, quickly. Not an anything you want > it to be, but a few, common

Easy Installs / Stage 4 ( Was: Re: [gentoo-dev] Re: Packages up for grabs )

Moving this to a higher visibility thread because I don't know how many people think such an intense discussion is happening in the tail of a package assignment . :P Most of my negativity/limitations are more about making sure we define where we aught to go. They're less "Limits", more "guide

Re: [gentoo-dev] Re: Packages up for grabs

On Sun, 7 Aug 2016 16:49:01 -0500 james wrote: > After that feat is accomplished, then a similar deployment of a > gentoo cluster on a those just installed gentoo minimal images, via a > few keystrokes (I am flexible on the cluster codes that comprise the > cluster). Then (only after those 2 th

Re: [gentoo-dev] Re: Packages up for grabs

On Mon, 8 Aug 2016 00:26:01 -0500 james wrote: > so it is paused for a licensed > download, as necessary, is not a show stopper The problem is that download requires a Browser with JavaScript support, because it requires JavaScript to set a cookie, and that cookie activates the download workin

Re: [gentoo-dev] Re: Packages up for grabs

On Mon, 8 Aug 2016 16:33:15 +1200 Kent Fredric wrote: > > so it is paused for a licensed > > download, as necessary, is not a show stopper > > The problem is that download requires a Browser with JavaScript > support, because it requires JavaScript to set a cook

Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian

On Thu, 11 Aug 2016 00:10:53 +0100 James Le Cuirot wrote: > Hello all, > > We, like almost everyone else and presumably upstream, install PCRE 8 > as libpcre.so.1. Debian, for reasons best known to themselves, install > it as libpcre.so.3. With Ubuntu still being the most widely accepted > "stan

Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian

On Thu, 11 Aug 2016 16:07:27 -0400 Ian Stakenvicius wrote: > but realistically this should be > installed to /usr/$(get_libdir)/debiancompat/ or similar, and if you > still don't want to wrap the apps that need it then also install an > /etc/env.d/ file to add this dir to the LDPATH. +1 to this.

Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian

On Thu, 11 Aug 2016 17:27:14 -0700 Patrick McLean wrote: > It's not like there is a shortage of > packages that install crappy crap on your system... In this instance I agree that we're kinda stressing about the wrong thing. But I can't support that reasoning. "There is bad stuff in tree so w

Re: [gentoo-dev] libfm requires dbus-glib to build, but it is not listed as a dependency.

On Fri, 12 Aug 2016 10:57:53 +0100 malc wrote: > You will want to report that on bugs.gentoo.org, providing the > suggested emerge info etc. please :) > The reference at [1] is your friend. > > Cheers, > malc. > I agree, a bugzilla bug is usaully better. Though I am somewhat of the opinion th

Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian

On Fri, 12 Aug 2016 09:12:22 -0500 james wrote: > (also, I'm not hung up on 'Jentoo' as a name; perhaps 'Gintoo'? > > (peace && hth), > James Way outside the scope needed here. However we pull off Zhenchoo, its going to be built on top of portage and our package management with extra bling. Th

Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian

On Fri, 12 Aug 2016 12:40:38 -0500 james wrote: > Ok, show us a solution based on your dashed items That's not what were doing here. We have a bunch of different solutions with different trade-offs, and whatever happens has to live with everything else. And so we're discussing them, working ou

Re: [gentoo-dev] New Working Group established to evaluate the stable tree

On Sun, 14 Aug 2016 22:45:07 +0100 Ciaran McCreesh wrote: > What's a Working Group, and how is it related to a Project? Shouldn't > there be a GLEP to define what a Working Group is first? So if a group of people wanted to write such a GLEP ... would they have to be part of a defined Project fir

Re: [gentoo-dev] New Working Group established to evaluate the stable tree

On Sun, 14 Aug 2016 22:57:31 +0100 Ciaran McCreesh wrote: > I'm not sure what a group is. Is it anything like a herd? Its a thing you get when more than one person does a thing. pgpMXkRM4x5eF.pgp Description: OpenPGP digital signature

Re: [gentoo-dev] New Working Group established to evaluate the stable tree

On Mon, 15 Aug 2016 11:45:22 +0800 Jason Zaman wrote: > IN_PROGRESS == we've put the fix in the git repo > RESO/TESTREQ == new release and in ~arch TESTREQ was incidentally my first thought. Only needs me to study how much that's already used and whether or not existing bugs with that flag meet

#wg-stable: Reservations about a "STABLE" & "NeedsStable" bugzilla keywords (re: [gentoo-dev] New Working Group established to evaluate the stable tree)

On Sun, 14 Aug 2016 23:35:58 +0200 Kristian Fiskerstrand wrote: > * The b.g.o workflow, bugs should not be considered fixed until the >fix has reached the stable tree. Today the InVCS keyword exists for >this purpose, but it is used to varying degree amongst developers. >Will a workf

Re: #wg-stable: Reservations about a "STABLE" & "NeedsStable" bugzilla keywords (re: [gentoo-dev] New Working Group established to evaluate the stable tree)

On Mon, 15 Aug 2016 16:29:43 +1200 Kent Fredric wrote: > > * The b.g.o workflow, bugs should not be considered fixed until the > >fix has reached the stable tree. Today the InVCS keyword exists for > >this purpose, but it is used to varying degree amongst develop

Re: [gentoo-dev] New Working Group established to evaluate the stable tree

On Mon, 15 Aug 2016 00:55:50 -0700 Brian Dolbec wrote: > For me IN_PROGRESS means the problem is being worked on, not that a fix > has been posted/committed anywhere. INVCS is once the fix has been > committed to the source repo and not anything to do with an ebuild from > the coders perspective

Re: #wg-stable: Reservations about a "STABLE" & "NeedsStable" bugzilla keywords (re: [gentoo-dev] New Working Group established to evaluate the stable tree)

On Mon, 15 Aug 2016 15:03:08 +0200 Kristian Fiskerstrand wrote: > Could you please elaborate a bit? In particular from perspective of (i) > integration into current workflow, (ii) complexity in application > maintenance/hosting (iii) cost/benefit considerations Biggest irritation is that "bugs t

Re: #wg-stable: Reservations about a "STABLE" & "NeedsStable" bugzilla keywords (re: [gentoo-dev] New Working Group established to evaluate the stable tree)

On Mon, 15 Aug 2016 21:30:04 +0200 "Andreas K. Hüttel" wrote: > 2) *If* we introduce a "Fixed-in" and maybe an "Introduced-in" field in > Bugzilla, which gives a precise $CATEGORY/$PVR where a problem is resolved or > introduced, the extraction of fixed or non-fixed bugs might even be > automa

Re: [gentoo-dev] New Working Group established to evaluate the stable tree

On Mon, 15 Aug 2016 09:37:33 -0400 Rich Freeman wrote: > > Today developers tend to use views that exclude resolved bugs. > Perhaps tomorrow they'll tend to use views that exclude bugs that are > resolved or waiting for stabilization. Perhaps these views will > become the defaults. Can bugzill

Re: [gentoo-dev] newsitem: openrc runscript transition (draft 3)

On Mon, 22 Aug 2016 17:57:43 -0500 William Hubbs wrote: > I thought about dropping the version number from the > display-if-installed line, but that doesn't make sense because it means > that everyone, including all new installs of OpenRC after this version, > would have to read the newsitem. >

Re: [gentoo-dev] newsitem: openrc runscript transition (draft 3)

On Wed, 24 Aug 2016 10:59:21 -0400 waltd...@waltdnes.org wrote: > These things get left in forever. I once filed a bug report > https://bugs.gentoo.org/show_bug.cgi?id=569056 because the warning that > English word lists in vim had been removed was still present *TWO YEARS* > after the fact. >

Re: [gentoo-dev] chromium-54 needs ffmpeg-3.0.1

On Sun, 28 Aug 2016 19:28:48 +0200 "Paweł Hajdan, Jr." wrote: > C. Mask chromium's system-ffmpeg flag when the dependency on > ffmpeg-3.0.1 can't be satisfied I'd pick this option, mostly because this is the path that introduces the least amount of space for breaking users setups. We've establi

Re: [gentoo-dev] chromium-54 needs ffmpeg-3.0.1

On Tue, 30 Aug 2016 09:37:51 +0200 Alexis Ballier wrote: > Most are fixed, but for me this implies that the space for breaking > users setup is much wider with bundled ffmpeg... But that fallout is limited to firefox. As opposed to "roll out ffmpeg 3 prematurely" which will break *more* than ju

Re: [gentoo-dev] Re: chromium-54 needs ffmpeg-3.0.1

On Wed, 31 Aug 2016 03:46:38 + (UTC) Duncan <1i5t5.dun...@cox.net> wrote: > Umm... you mean chromium, not firefox, correct? > Correct, mental bozo bits flipped temporarily ;) > Either way, having to stick with an old and likely vulnerable browser > because the new one won't build isn't a b

Re: [gentoo-dev] chromium-54 needs ffmpeg-3.0.1

On Wed, 31 Aug 2016 09:43:08 +0200 Alexis Ballier wrote: > nobody is talking about a premature unmask and even less about > firefox :) Right. My bad on the FF :) ( ffmpeg having FF in it is clearly perturbing my brain ) But my point really is that *chromium* has end users desiring latest-and

Re: [gentoo-dev] Firefox bloat Was: chromium ...

On Thu, 1 Sep 2016 02:36:27 + (UTC) Duncan <1i5t5.dun...@cox.net> wrote: > FWIW, the australis thing never really affected me much. I had some > extensions (and configuration mania guified native options) changing > the look somewhat before, and have some extensions (and config mania > optio

Re: [gentoo-dev] Re: chromium-54 needs ffmpeg-3.0.1

On Wed, 31 Aug 2016 21:03:34 -0500 »Q« wrote: > says it's in Gentoo overlays, but I don't > know which ones. Tar.bz2's from http://linux.palemoon.org/download/mainline/ are working nicely for me as a straight download/unpack/run-in-$HOME Much so ( and more securely

Re: [gentoo-dev] Re: chromium-54 needs ffmpeg-3.0.1

On Thu, 01 Sep 2016 22:03:37 +0100 "M. J. Everitt" wrote: > [and No, I'm > not volunteering at this point!!!] Well volunteered [future] you. pgpKawF6IrKFy.pgp Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: Eclasses and EAPI

On Mon, 5 Sep 2016 15:03:36 +0200 Michał Górny wrote: > On Fri, 2 Sep 2016 18:13:20 +0200 > Kristian Fiskerstrand wrote: > > > I'm wondering whether it wouldn't make sense to require eclasses (or > > strongly encourage) to include an explicit list of EAPIs it has been > > tested for in order to

Re: [gentoo-dev] Last rites: app-misc/subsurface

On Fri, 9 Sep 2016 21:59:10 -0700 Raymond Jennings wrote: > +1. Any package whose upstream says "don't build this yourself" is hostile > to open source principles. That's also an open invitation to fork ;) pgpVU5RCL7Jc6.pgp Description: OpenPGP digital signature

Re: [gentoo-dev] questions about small fixes/cleanups

On Tue, 13 Sep 2016 19:49:22 -0400 Michael Orlitzky wrote: > > Patches: > > * Wildcard patching: Usually i use my "patchtest" script for finding > > obsolete patches and while it still finds lots of false > > positives i also saw a rather odd patching style: Patching via > > wildcards

Re: [gentoo-dev] questions about small fixes/cleanups

On Wed, 14 Sep 2016 14:55:06 +0100 James Le Cuirot wrote: > On Wed, 14 Sep 2016 14:53:18 +0100 > James Le Cuirot wrote: > > > On Wed, 14 Sep 2016 15:50:28 +0200 > > Alexis Ballier wrote: > > > [...] > [...] > > > > You can't. > > Sorry, let me correct that, you can't by date but y

Re: [gentoo-dev] questions about small fixes/cleanups

On Wed, 14 Sep 2016 16:41:54 +0200 Alexis Ballier wrote: > > So, to sum it up, I have to: > - Open a browser, go to github (*) > - Find out latest commit hash, copy it > - (*) Copy the ebuild, setting a 8 digit version representing the date > - Open an editor > - Edit COMMIT='...' variable by pa

[gentoo-dev] Proposed future EAPI feature: FILES whitelist

Just an idea that seemed obvious enough and obviously missing. 1. Have, in a future EAPI, a variable (I'm going to call it "FILES" as a stand-in for now ). 2. FILES contains an array (or perhaps whitespace delimited string) of entries (or perhaps expressions) relative to ${repository_location}/${

[gentoo-dev] Arch testers need themselves an IRC channel so I can love them more

If you're an arch tester reading this, I love you. Your job is mostly thankless and how important it is seems relatively un-reflected in our regular conversations, and this needs to be rectified. Often, I see a stable request get done, and I know what got stabilized was a monumental amount of wor

Re: [gentoo-dev] Proposed future EAPI feature: FILES whitelist

On Fri, 16 Sep 2016 17:20:28 +0200 Ulrich Mueller wrote: > > 3. Each entry in FILES dictates that the given file is "Used by" the > > ebuild. > > Do you mean "file" in its Unix meaning here, i.e. including > directories? Or only regular files? I'd say regular files for now. Mostly because I t

Re: [gentoo-dev] Proposed future EAPI feature: FILES whitelist

On Fri, 16 Sep 2016 20:34:49 +0200 Ulrich Mueller wrote: > That is, similar syntax as for SRC_URI? That would make parsing of the > FILES variable by ebuilds practically impossible. So presumably, one > would need another variable similar to A then, containing the files > from FILES but without t

Re: [gentoo-dev] Proposed future EAPI feature: FILES whitelist

On Tue, 20 Sep 2016 09:02:41 +0200 Michał Górny wrote: > Finally, the same though occurred to me as to ulm. People will forget > to update the variable. They will forget to update it when adding, > and they will waste their time on build that is going to fail somewhere > at doinit in the end -- h

Re: [gentoo-dev] Proposed future EAPI feature: FILES whitelist

On Tue, 20 Sep 2016 18:14:58 +0200 Ulrich Mueller wrote: > Under that new scheme, how would I apply patches unpacked into > WORKDIR? In EAPI 6, I can put them into the PATCHES variable and use > the default src_prepare to process it. Can you give me a clearer example of what you mean? pgpPMY7

Re: [gentoo-dev] Proposed future EAPI feature: FILES whitelist

On Tue, 20 Sep 2016 18:14:58 +0200 Ulrich Mueller wrote: > Under that new scheme, how would I apply patches unpacked into > WORKDIR? In EAPI 6, I can put them into the PATCHES variable and use > the default src_prepare to process it. oh. Right. Huh, I had somehow overlooked there was already a P

Re: [gentoo-dev] Re: Package up for grabs: skencil

On Tue, 20 Sep 2016 12:45:06 -0400 Rich Freeman wrote: > It > just seems silly, and it might actually reduce the incentive for > somebody else to step up and actually maintain it because it doesn't > go on list of maintainer-needed packages. In this way the rush to > treeclean stuff that works

Re: [gentoo-dev] Proposed future EAPI feature: FILES whitelist

On Wed, 21 Sep 2016 08:44:33 +0200 Ulrich Mueller wrote: > Obviously they could be identified by their explicit ${FILESDIR}. My question is because I've had a difficulty understanding how repoman "sees" the ebuild. I was under the impression repoman would either have to rely on people to be go

Re: [gentoo-dev] newsitem: OpenRC 0.22 updates

On Fri, 23 Sep 2016 14:39:50 -0500 William Hubbs wrote: > The swapfiles service, which was basically a copy of the swap service, > has been removed. If you are only using swap partitions, this change > will not affect you. If you are using swap files, please adjust the > dependencies of the swap

Re: [gentoo-dev] The future of elibtoolize

On Tue, 27 Sep 2016 11:24:19 +0200 Alexis Ballier wrote: > Also, keep in mind that with an external utility you have far less > control on what is executed than with something in $PORTDIR: people may > use an older buggy version of the utility, while when shipping it in > $PORTDIR you are sure th

Re: [gentoo-dev] bash-4.4 - call for testers

On Thu, 29 Sep 2016 23:56:34 +0200 Andy Mender wrote: > I believe the main problem comes from /bin/bash and potential symlinks that > would need to be introduced as part of the slotting. In a pinch you could probably get away with calling :1 /usr/bin/bash-4.4 instead of /usr/bin/bash, and then

Re: [gentoo-dev] bash-4.4 - call for testers

On Sat, 1 Oct 2016 01:49:56 +0800 konsolebox wrote: > It would be nice to have some eselect command to > easily switch from one version of Bash to another; probably something > close to how it's done in dev-lang/ruby. Its just eselect itself is bash. So if bash is broken . switching out bec

Re: [gentoo-dev] bash-4.4 - call for testers

On Sun, 2 Oct 2016 13:28:04 +0800 konsolebox wrote: > I guess that's another good way to solve the readline issue (when it > comes to bash). But I'd prefer that it's not done automatically. > Instead we should add a formal use flag like 'installed-readline'. We > can add it to release versions

Re: [gentoo-dev] bash-4.4 - call for testers

On Sun, 2 Oct 2016 16:03:11 +0800 konsolebox wrote: > I actually don't like the idea of enabling or disabling > "installed-readline" based on the `${PV} != *_rc*` condition. If a > user would want to explicitly enable "installed-readline" globally, > how would he make sure that it only affects t

Re: [gentoo-dev] bash-4.4 - call for testers

On Sun, 2 Oct 2016 18:18:17 +0800 konsolebox wrote: > I should also add that a dynamic "default" that varies depending on > the version doesn't sound good to me. For one at least, it confuses > the user. I agree that its a bit unintuitive. However, the alternatives are: - A useflag that entir

Re: [gentoo-dev] depend.apache.eclass and EAPI=6

On Sat, 1 Oct 2016 00:48:52 +0200 Kristian Fiskerstrand wrote: > > However I *want* the message to be loud and obnoxious. > > We need eblinkwarn ... :o) > > > > I don't see why users should be bothered with maintainer mistakes that > doesn't affect them (in this particular circumstance) Soun

Re: [gentoo-dev] bash-4.4 - call for testers

On Mon, 3 Oct 2016 13:32:34 +0800 konsolebox wrote: > "A useflag that entirely goes away depending on the version" (or a > flag that is implemented in one ebuild but is not on another) is > pretty common among packages and I see that as totally valid, and is > way better than a solution that uses

Re: [gentoo-dev] bash-4.4 - call for testers

On Mon, 3 Oct 2016 14:37:15 +0800 konsolebox wrote: > But anyway, what do you think about just enabling > IUSE="+system-readline" by default to any version, and just rely on > KEYWORDS="" to prevent the user from misusing it with a pre-release > version of bash? I believe we can both agree on th

Re: [gentoo-dev] rfc: the demise of grub:0

On Tue, 4 Oct 2016 17:28:55 -0500 William Hubbs wrote: > If you know grub well, you can hand write a grub.cfg without > using grub-mkconfig at all. There is a perception that you need > grub-mkconfig, but this is not true. I guess the problem is neither knowing "grub well" or liking mkconfig.

Re: [gentoo-dev] rfc: the demise of grub:0

On Tue, 4 Oct 2016 22:22:12 -0400 Rich Freeman wrote: > How do you generate your grub-0 config files? I didn't, it came as a stock example file with comments which I edited in a minimal fashion until it worked. > > You can just use the same method to generate the grub-2 ones... No, I regenera

Re: [gentoo-dev] grub-2 configuration

On Tue, 4 Oct 2016 22:34:11 -0500 William Hubbs wrote: > You don't have to use grub-mkconfig. You can write /boot/grub/grub.cfg > by hand if you want, and it appears that the syntax is documented in the > grub info pages. > > William Just saying, it would be really nice to have some documented

Re: [gentoo-dev] grub-2 configuration

On Wed, 5 Oct 2016 17:46:29 +1300 Kent Fredric wrote: > On Tue, 4 Oct 2016 22:34:11 -0500 > William Hubbs wrote: > > > You don't have to use grub-mkconfig. You can write /boot/grub/grub.cfg > > by hand if you want, and it appears that the syntax is documented

Re: [gentoo-dev] rfc: the demise of grub:0

On Wed, 5 Oct 2016 06:04:38 -0500 Rich Freeman wrote: > What you really want is another template file. I'd be happy with that. See the other thread with "grub-2" In the title. > I'm happy with mkconfig, but I did hand-roll my config files before > that. The docs are out there. However, for wh

Re: [gentoo-dev] Package file name requirement for binary ebuilds

On Fri, 14 Oct 2016 13:05:43 -0400 "William L. Thomson Jr." wrote: > It is some what a moot problem, but I think it would be good to adopt such or > similar requirement, maybe in the PMS. Many already follow the -bin suffix > now. > I just do not believe it is a requirement anywhere. Which if

Re: [gentoo-dev] Package file name requirement for binary ebuilds

On Sun, 16 Oct 2016 18:20:42 -0400 "William L. Thomson Jr." wrote: > Part of the idea everyone is missing is time... It takes time to go look at > information a package metadata.xml If the package is coming in as a > dependency. Instead of just being able to visually look at the package name >

Re: [gentoo-dev] Package file name requirement for binary ebuilds

On Sun, 16 Oct 2016 18:30:44 -0400 "William L. Thomson Jr." wrote: > You actually came up with one I was not considering at first but provides a > direct technical benefit you cannot achieve with a USE flag. > > > If anything, I'd imagine if that case arose, it would manifest itself more > > a

Re: [gentoo-dev] Package file name requirement for binary ebuilds

On Mon, 17 Oct 2016 03:41:13 -0400 "William L. Thomson Jr." wrote: > To be clear I would suggest at MOST 3, -bin, -ebin, and -sbin. NO more. It would be far better to simply have a PROPERTIES field in ebuilds or somesuch: PROPERTIES="binary:upstream" or PROPERTIES="binary:gentoo" Assuming th

Re: [gentoo-dev] Local workarounds with no reported bugs

On Mon, 17 Oct 2016 09:23:09 +0200 Michał Górny wrote: > Therefore, I'd like to request establishing an official policy against > workarounds with no associated bug reports. > > Your thoughts? Obviously I assume this is still a "to taste" thing, because when you're packaging something, and you

Re: [gentoo-dev] Package file name requirement for binary ebuilds

On Mon, 17 Oct 2016 09:39:25 -0400 "William L. Thomson Jr." wrote: > > > PROPERTIES="binary:upstream" > > > > or > > > > PROPERTIES="binary:gentoo" > > > > Assuming the right tooling, this allows a way to "canonically" define > > what the type of binary is, and allow people to make whatever ch

Re: [gentoo-dev] Package file name requirement for binary ebuilds

On Mon, 17 Oct 2016 09:32:30 -0400 "William L. Thomson Jr." wrote: > > You know you can make that argument about *every* useflag right? Being > > unable to test with one and the other co-installed? > > Did you see the comment where portage has this function now? I don't actually know what he'

Re: [gentoo-dev] Package file name requirement for binary ebuilds

On Mon, 17 Oct 2016 13:09:52 -0400 Michael Mol wrote: > does that even make sense when the blob or helper utility is only used by > that package? Makes it more useful in vetting and deploying security concerns. pgpWmx3Rs8P_O.pgp Description: OpenPGP digital signature

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

On Tue, 18 Oct 2016 21:45:05 -0500 Matthew Thode wrote: > Does pram allow you to pass options to git > am (signedoffby for instance)? It doesn't presently allow arbitrary arguments, and it would probably be wise to avoid need for such arguments and prefer convention over configuration, given w

Re: [gentoo-dev] x11-misc/bumblebee and x11-misc/virtualgl up for grabs

On Wed, 19 Oct 2016 18:45:00 +0700 "Vadim A. Misbakh-Soloviov" wrote: > By the way, as I was co-maintainerwith Pacho, and now my primary laptop is > alo > missing optimus (although, I still own few optimus-powered laptops, which I > gave away to family members). So, not that I totally not inte

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

On Wed, 19 Oct 2016 14:15:11 +0200 Kristian Fiskerstrand wrote: > > > > Personally I use it as 'I sign off on the Author's work'. I suppose the > > commit itself is good enough for this but I personally prefer verbosity. > > It also calls out that it wasn't my work. > > > > This sounds mor

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

On Mon, 24 Oct 2016 08:29:49 +0200 Michał Górny wrote: > How about Gentoo developers stopping to reuse things that have well-defined > meaning for something completely different? Patching the git tools to have a simple-to-use way to indicate the equivalent metadata welcome ... But like, you'r

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

On Mon, 24 Oct 2016 07:45:56 -0400 Rich Freeman wrote: > I don't think we need a git header for the purpose of saying that > something looks good to somebody else. If you commit something and it > doesn't work, we'll ask you to stop doing it. If you keep doing it > we'll take away your commit a

Re: [gentoo-dev] Are "Copyright 1999-20xx Gentoo Foundation" headers bogus?

On Tue, 25 Oct 2016 09:25:52 +0200 Ulrich Mueller wrote: > And I guess that even most ebuilds for new > packages aren't written from scratch, but will be based on an existing > ebuild or on some template like skel.ebuild. You could probably argue that subsequently, every ebuild is essentially a

Re: [gentoo-dev] Commented packages in the @system set

On Thu, 27 Oct 2016 09:21:06 -0400 Rich Freeman wrote: > I'm not saying you can completely avoid the need for having some kind > of bootstrapping stage1. I'm just saying we should separate that need > from the issue of fully specifying dependencies, at least in an ideal > world where we're uncon

Re: [gentoo-dev] rsync.gentoo.org rsync modules: gentoo-repo-changelog added, gentoo-x86-portage & gentoo-sec discontinued.

On Sun, 30 Oct 2016 02:54:17 + "Robin H. Johnson" wrote: > They may or may not still be referenced > by the thick Manifests. Surely they should not continue to be referenced, as being referenced but not present would cause the entire package to be deemed invalid due to failing integrity chec

Re: [gentoo-dev] Revisiting version-related tree policies

On Thu, 3 Nov 2016 17:11:22 +0100 Michał Górny wrote: > 1. Revision number must be no longer than : > 1a. to make <=X-r reliable, > 1b. to prevent pathological uses of revision as date. I think most the arguments you've made for this stem from subjective and social problems, not technica

Re: [gentoo-dev] Revisiting version-related tree policies

On Fri, 4 Nov 2016 10:24:28 +0100 Ulrich Mueller wrote: > I would assume to be high enough, even if you use multiples of > 100 to label the slot. Or do you expect having more than 100 slots for > Perl? Well, the desire is for the -r (or similar) part correspond to something representative o

Re: [gentoo-dev] Google Code shutdown requires 524 ebuilds to be fixed before end of 2016

On Fri, 4 Nov 2016 23:09:07 -0400 Mike Gilbert wrote: > On Fri, Nov 4, 2016 at 9:36 PM, Jonas Stein wrote: > [...] > > > [...] > > > > Yes, that is a good idea. > > > > cat googlecode-shutdown.txt | cut -f1 -d":" | xargs equery meta -mH | > > grep "\@" | sort | uniq | sed "s/@/__/g" > >

Re: [gentoo-dev] Revisiting version-related tree policies

On Sat, 5 Nov 2016 11:13:35 +0100 Ulrich Mueller wrote: > revision component must not be used for upstream versions: The problem is we have *2* upstream versions. virtual/perl-Foo-N Maps to perl-core/Foo-N And dev-lang/perl-Y ( for possibly more than one value of Y ) And Y does not eq

Re: [gentoo-dev] Revisiting version-related tree policies

On Sat, 5 Nov 2016 12:43:31 +0100 Ulrich Mueller wrote: > I still don't see why you must (ab)use the revision for that. With > virtuals, the whole PV is at your disposal, so you could append .5.22 > to it, or even use a suffix like _p522. Incidentally, I did use _p522 for the one case we had pre

Re: [gentoo-dev] [RFC] New version constraints: variant one

On Thu, 10 Nov 2016 23:53:40 +0100 Michał Górny wrote: > dev-foo/bar[>=3][foo]# version + USE I kinda find this asking for problems with visual ambiguity. Use different grouping symbols or supercede the USE syntax entirely. dev-foo/bar[foo]#(>=3) Or something. I'm also suggesting

Re: [gentoo-dev] rsync.gentoo.org rsync modules: ChangeLogs dropped from gentoo-portage

On Tue, 15 Nov 2016 01:11:48 + "Robin H. Johnson" wrote: > They will continue to be included in the Manifest until the next phase > of the change. > > rsync.gentoo.org::gentoo-portage > - tree without ChangeLogs > > rsync.gentoo.org::gentoo-repo > - same as gentoo-portage, new name for co

Re: [gentoo-dev] rsync.gentoo.org rsync modules: ChangeLogs dropped from gentoo-portage

On Thu, 17 Nov 2016 20:57:26 + "Robin H. Johnson" wrote: > - eg metadata.xml (nothing for user systems is impacted by it, other >than to give output about packages). Idle thought: Given there are classes of vulnerabilities related to XML parsing and decoding, any systems that attemp

Re: [gentoo-dev] Re: Stabilisation procedure

On Fri, 18 Nov 2016 00:13:35 +1100 Michael Palimaka wrote: > What is the *real* risk that kde-apps/kcalc builds against stable > dev-libs/gmp but then starts producing funny numbers at runtime? > > Let's put it another way - assume we're stabilising a new version of > dev-libs/gmp instead. Shoul

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

On Wed, 23 Nov 2016 09:44:33 +0100 Manuel Rüger wrote: > What happens if the ebuild wants to create multiple users/group? > Currently, I want to ignore that case and focus on the 80% ebuilds that > can profit from such an eclass. You can solve that part quite easily really. Just deem USERKIT_US

Re: [gentoo-dev] Improving the stabilisation process - part 1

On Fri, 25 Nov 2016 06:41:20 +1100 Michael Palimaka wrote: > Example atom list from a bug with amd64, arm, and x86 in CC: > > =app-foo/bar-1.2.3 # will be stabilised on amd64, arm, and x86 > =app-foo/baz-2.3.4 amd64 x86 # will be stabilised on only amd64 and x86 I was doing this in th

Re: [gentoo-dev] Improving the stabilisation process - part 1

On Fri, 25 Nov 2016 17:54:41 +1300 Kent Fredric wrote: > Content-Transfer-Encoding: quoted-printable Ugh. I attached that so wrong and it is unreadable. How does one "reply to X" and "attach other email Y" in claws without cocking it up entirely. "message/rfc82

<    1   2   3   4   5   6   7   8   9   >