On Sat, Dec 29, 2012 at 11:13 AM, Brian Dolbec wrote:
>
> Not to sidetrack the topic farther, but isn't this best done in our
> github/gentoo account. It is one of the main reasons we have it, to
> easily accept pull requests from users. It would also make it easier
> for more devs to participat
On Mon, Dec 31, 2012 at 9:42 AM, Tobias Klausmann wrote:
> Now before you reply, RTFA. Also note that while my own opinion
> on the matter is irrelevant, I _do_ think that his concerns need
> to be addressed, particularly the second half of his statement.
SSL Certificate Authorities are a mess.
On Tue, Jan 1, 2013 at 5:51 AM, Dirkjan Ochtman wrote:
> On Tue, Jan 1, 2013 at 1:44 AM, Rich Freeman wrote:
>> The certificates that Gentoo distributes have at least been vouched
>> for by somebody who is a part of our community, which is more than can
>> be said for
On Tue, Jan 1, 2013 at 9:49 PM, Michael Mol wrote:
> On Tue, Jan 1, 2013 at 9:37 PM, Benjamin Peterson wrote:
>> Michael Mol gmail.com> writes:
>>> On Tue, Jan 1, 2013 at 5:51 AM, Dirkjan Ochtman gentoo.org> wrote:
>>> > Speaking of which, say what you will about Mozilla's broken criteria
>>> >
On Wed, Jan 2, 2013 at 10:44 AM, Peter Stuge wrote:
> Samuli Suominen wrote:
>> i'd say never. there is no benefit in switching. pkg-config is the
>> default implementation from freedesktop.org.
>
> That's one awful double standard. :\
Double-standards aside, I don't think the "original" implemen
On Thu, Jan 3, 2013 at 9:39 AM, Ulrich Mueller wrote:
> We could easily solve this by adding a "binary-only" or
> "no-source-code" tag to such packages. It would be included in the
> @BINARY-REDISTRIBUTABLE license group, but not in @FREE. So such
> packages would be excluded for users with ACCEPT
On Sat, Jan 5, 2013 at 1:55 PM, Alec Warner wrote:
> On Sat, Jan 5, 2013 at 9:03 AM, Andreas K. Huettel
> wrote:
>> Even if you're not a business you should care about maintainable solutions.
>
> I'm sure at the time it was created (12+ years ago) the website looked
> pretty maintainable :)
Hen
On Wed, Jan 9, 2013 at 7:20 AM, Duncan <1i5t5.dun...@cox.net> wrote:
> Zac Medico posted on Tue, 08 Jan 2013 23:42:39 -0800 as excerpted:
>
>> Weren't we planning to drop the CVS keywords for the git migration,
>> anyway?
>
> Are the git migration blockers at such a point that we can get an ETA
> y
On Wed, Jan 9, 2013 at 7:42 AM, Diego Elio Pettenò
wrote:
> On 09/01/2013 13:37, Ciaran McCreesh wrote:
>> Translation: "We all know that there are lots of things that would be a
>> hell of a lot easier if we weren't the only project in the world still
>> using CVS, but the Git migration is never
On Wed, Jan 9, 2013 at 12:02 PM, Jeroen Roovers wrote:
> A lot clearer than a single text field littered with keywords would be some
> tick boxes, indeed. In fact, it makes me wonder why we use a half-obscured
> list
> in a select field for adding/removing arch teams now.
Agree - mostly legacy (
On Wed, Jan 9, 2013 at 11:21 PM, Daniel Campbell wrote:
> So long as users retain the choice of keeping eth* or wlan*, no
> complaints from me. I (and others) came to Gentoo to get away from
> systemd, and this smells of a systemd-ism. Will eudev be pursuing this
> as well?
Keep in mind that this
On Mon, Jan 14, 2013 at 1:21 PM, Diego Elio Pettenò
wrote:
> I don't want systemd and I don't want eudev. And I'm not alone I'm sure.
++
If it costs me 1200 seconds of CPU time and 40 millicents in
electricity twice I year I can live with that...
Rich
On Mon, Jan 14, 2013 at 2:28 PM, William Hubbs wrote:
> The only time I see eudev replacing udev as our default is if the
> systemd guys actually kill udev on non-systemd systems.
>
Seems likely to me, but anticipating about 300 replies to your post, I
think we're all agreed that we'll do what ma
On Tue, Jan 15, 2013 at 5:25 AM, Kevin Chadwick wrote:
>
> I still ascert that apps adding groups with NOPASSWD sudoers lines
> perhaps even commented out by default in all or some cases is far
> better than polkit for many reasons. Any counter argument can apply
> to sudo too and rather easily.
>
On Tue, Jan 15, 2013 at 8:44 AM, Ian Stakenvicius wrote:
> I wonder if it might be pertinent for future portage's to install an
> alias command, "emerge-system-update" or similar, that would wrap the
> standardly accepted emerge update command more or less everyone
> already runs.. easier end-use
On Tue, Jan 15, 2013 at 9:39 AM, Dirkjan Ochtman wrote:
> On Tue, Jan 15, 2013 at 3:27 PM, Ian Stakenvicius wrote:
>> Bikeshedding, but I'm thinking that it would be better to provide a
>> whole separate command for this rather than a quicker convenience
>> option -- the command would, for instan
On Tue, Jan 15, 2013 at 1:58 PM, Greg KH wrote:
> And it's not udev that could rename the interface (hint, it wouldn't),
> it's the kernel, it _never_ guarantees the same interface "name" every
> time you boot. You might just be getting lucky, but really, PCI busses
> can be enumerated in differe
On Tue, Jan 15, 2013 at 10:42 PM, Peter Stuge wrote:
> Rich Freeman wrote:
>> Not that anybody is taking requests, but it would be really handy
>> if serial ports were deterministically labeled.
>
> Does /dev/serial/* solve the problem?
I don't see this directory at all on my system.
Rich
On Wed, Jan 16, 2013 at 6:54 AM, Alexis Ballier wrote:
> On Tue, 15 Jan 2013 21:10:12 -0800
> ""Paweł Hajdan, Jr."" wrote:
>>
>> What when chromium upstream uses code more recent than latest ffmpeg
>> release and it doesn't compile against latest release?
>
> Blame them, it's stupid to break supp
On Wed, Jan 16, 2013 at 3:43 PM, Paul Varner wrote:
> 2. What behavior do we want? append to EMERGE_DEFAULT_OPTS or replace
> EMERGE_DEFAULT_OPTS
Replace is probably better. You can always manually append if you
want to, but it is much harder to remove unless portage has logic to
handle a invers
On Wed, Jan 16, 2013 at 3:01 PM, Mike Gilbert wrote:
> As has been pointed out previously, the "base" profile does not set
> USE="perl python", so negating those flags in the server profile does
> basically nothing. If certain packages have IUSE="+perl +python" it
> might make a difference, but I
On Wed, Jan 16, 2013 at 9:49 PM, Greg KH wrote:
> On Wed, Jan 16, 2013 at 06:36:59AM -0500, Rich Freeman wrote:
>> On Tue, Jan 15, 2013 at 10:42 PM, Peter Stuge wrote:
>> > Rich Freeman wrote:
>> >> Not that anybody is taking requests, but it would be really ha
On Wed, Jan 16, 2013 at 5:53 PM, Panagiotis Christopoulos
wrote:
> Err, ok, so now guys, we 're offering a base profile* with dri, cups, gmp,
> fortran and pppd(?) enabled, at the same time openmp enabled but threads
> disabled, no sockets, no caps no apache2 or mysql that I would probably
> want
On Wed, Jan 16, 2013 at 7:00 PM, Michael Weber wrote:
> how does portage @preserved-libs work? maybe we could emerge
> @update[s] and @glsa.
@glsa actually makes a lot of sense. I'm not convinced we want
@updates as a shortcut for a bunch of settings though. Sets are just
about picking which pa
On Thu, Jan 17, 2013 at 12:14 PM, Ciaran McCreesh
wrote:
> On Thu, 17 Jan 2013 12:03:36 -0500
> James Cloos wrote:
>> Every current category matches /^[a-z]+-[a-z]+$/. With the possible
>> exception of adding moving from [a-z]+ to [a-z0-9]+, that shoud
>> remain.
>
> Untrue. 'virtual' doesn't. I
On Thu, Jan 17, 2013 at 2:27 PM, Christopher Head wrote:
> On Wed, 16 Jan 2013 22:17:26 -0500
> Rich Freeman wrote:
>
>> Oh, and keep in mind that flags really only have an effect if the
>> corresponding packages are actually installed. For example, the cups
>>
On Thu, Jan 17, 2013 at 2:56 PM, Christopher Head wrote:
> On Thu, 17 Jan 2013 14:32:01 -0500
> Rich Freeman wrote:
>
>> Sure, I can think of reasons why I would want chromium with -cups, but
>> the whole point is to target the TYPICAL user. And the context here
>> is
On Thu, Jan 17, 2013 at 10:58 PM, Peter Stuge wrote:
>CAUTION: Note that shred relies on a very important assumption: that
>the file system overwrites data in place. This is the traditional way
>to do things, but many modern file system designs do not satisfy this
>
On Sat, Jan 19, 2013 at 3:26 AM, Ben de Groot wrote:
>
> People who do have printers can always enable it themselves. I don't
> see any reason for cups to be enabled by default, especially not on a
> minimal profile, and that includes the simple desktop profile. The kde
> and gnome profiles are ex
On Sat, Jan 19, 2013 at 3:18 AM, Ben de Groot wrote:
> I'm not sure whether we need to keep cups at all. I haven't printed
> anything from my personal PC or laptop in years. And I'm sure I'm not
> the only one.
Won't repeat my previous email, but this is the kind of situation
where a "popularity
On Sat, Jan 19, 2013 at 7:43 AM, Diego Elio Pettenò
wrote:
> Some of us, including me, are also wondering why a separate category
> is needed — while you might be over the median, it doesn't mean it's
> that much more compelling — indeed my feeling is that it would be an
> useless small category,
On Sat, Jan 19, 2013 at 8:46 AM, Patrick Lauer wrote:
> Maybe lib-qt ? dev-qt sounds confusing to me too, what's "dev" about it?
I was thinking about that. A lib-misc, lib-x11, lib-qt, and so on
organization actually makes more sense to me than what we're doing
with libs in general right now. B
On Sun, Jan 20, 2013 at 10:22 AM, Chí-Thanh Christopher Nguyễn
wrote:
> Andreas K. Huettel schrieb:
>>
>> Summarizing this thread:
>>
>>> * move setting USE=dri from default/linux/make.defaults to
>>> targets/desktop/make.defaults
>>
>> +1 by dilfridge, djc, kensington, vapier, pesa, hwoarang
>> c
On Sun, Jan 20, 2013 at 10:20 AM, Andreas K. Huettel
wrote:
> So, a thread like "Should we enable useflag Z by default" would then include
> "Please discuss here, vote on ..." with a link to the count page (updated via
> cron every 1h). On login to ..., a message similar to the "open elections
> m
On Sun, Jan 20, 2013 at 4:59 PM, Rick "Zero_Chaos" Farina
wrote:
>> If we have it as IUSE default, it can be removed from the profiles
>> entirely. Having it only in the desktop profile is not good in any
>> scenario I can think of.
>
> chithanh, maybe you can explain to everyone why USE=dri is ne
On Thu, Jan 17, 2013 at 9:51 AM, Ian Stakenvicius wrote:
> On 16/01/13 09:55 PM, Rich Freeman wrote:
>> SUBSYSTEM=="tty", DRIVERS=="pl2303", KERNELS=="4-1:1.0",
>> KERNEL=="ttyUSB*", SYMLINK="mythser/rca1"
>>
>> I'
On Mon, Jan 21, 2013 at 2:46 AM, Hans de Graaff wrote:
> Setting the option in the profile tells me: "Here's this option you can
> play with, and we think you might need it. Or not."
>
> Setting the option in the ebuild tells me: "You know, we are nice and
> give you this option, but really you sh
On Mon, Jan 21, 2013 at 12:51 PM, Dustin C. Hatch wrote:
> The package defaults have gotten out of hand, in my opinion. I use
> default/linux/amd64/10.0 on all my machines and my /etc/portage/package.use
> directories have dozens of -flag entries for packages with ridiculous
> defaults, and almost
On Tue, Jan 22, 2013 at 6:11 AM, viv...@gmail.com wrote:
> IMHO the number of cases where CONFIG_CHECK is reliable is so small that
> making it fatal will only bloat make.conf and env with a new var for most
> users.
Tend to agree. I just got an elog out of udisks complaining about
USB_SUSPEND n
On Tue, Jan 22, 2013 at 2:22 AM, Ben de Groot wrote:
> On 22 January 2013 03:28, Rich Freeman wrote:
>> On Mon, Jan 21, 2013 at 12:51 PM, Dustin C. Hatch
>> wrote:
>>> The package defaults have gotten out of hand, in my opinion. I use
>>> default/linux/amd64/10
On Tue, Jan 22, 2013 at 3:03 AM, Alexander Berntsen
wrote:
>
> While I tend towards the cleaner design, not the "don't fix what isn't
> *broken*" approach -- I'm fine either way. But I think the handbook or
> some tool should obnoxiously spit the flags (and a minor
> "justification" for each flag
On Wed, Jan 23, 2013 at 7:32 AM, Fabio Erculiani wrote:
> I hope this is going to be binary package manager friendly.
> In Sabayon for instance, kernel sources are not even installed and at
> the same time, /proc/config.gz may not even be available.
> There were some corner cases in where pkg_setu
On Wed, Jan 23, 2013 at 8:41 AM, Samuli Suominen wrote:
> not for everyone, not everyone upgrades this often, and it's usually the
> servers that get updated last
Agreed, but best to get this out ASAP.
Only question - display-if-installed is set to <. Would it make
sense to make it <198 ins
On Wed, Jan 23, 2013 at 9:05 AM, Diego Elio Pettenò
wrote:
>
> None are involved. The second column would read /dev if it was involved.
The news item doesn't mention what to do if there is no line to mount
/dev. I don't see one in my fstab, and I simply followed the handbook
(as it was written ~
On Wed, Jan 23, 2013 at 1:42 PM, Mike Gilbert wrote:
> fstab is not consulted for mounting the root filesystem, so it doesn't
> really matter what you have in there. Either the kernel mounts it
> based on the kernel command line, or your initramfs mounts it based on
> whatever your /init programs
On Wed, Jan 23, 2013 at 1:56 PM, Mike Gilbert wrote:
>
> Ah, good to know. I'm used to dealing with my little homegrown
> initramfs, where I parse root from the kernel command line in /init.
> genkernel does the same thing.
Yeah, dracut generally "does the right thing" but that generally
assumes
On Thu, Jan 24, 2013 at 5:02 AM, Michael Haubenwallner wrote:
>
> The only way I've found to keep the system bootable with both kernels
> (for the upgrade process until the new kernel config was good enough)
> was to replace /dev/cciss/c0d0p1 by /dev/root in /etc/fstab.
>
> How would this be done
On Thu, Jan 24, 2013 at 12:49 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> That said, presumably udisks would choose not to make its check fatal,
> altho changing the default to fatal could complicate things for existing
> ebuilds until they're fixed.
That was basically my whole point - it can't be
On Thu, Jan 24, 2013 at 1:18 PM, Ian Stakenvicius wrote:
> a fatal die in pkg_pretend could be circumvented by an environment
> variable such as ${PN}_I_KNOW_WHAT_IM_DOING being set. Just a thought.
If we're going to do this I'd definitely have the ${PN} bit as you
suggested. Otherwise everybod
On Thu, Jan 24, 2013 at 1:58 PM, Ian Stakenvicius wrote:
> How about, you know what you're doing and are going to build a new
> kernel as soon as the emerge finishes (since the emerge is also
> bringing in a new gentoo-sources)??
Or my earlier example - USB_SUSPEND and such. If there end up bein
On Thu, Jan 24, 2013 at 2:21 PM, Michael Orlitzky wrote:
> On 01/24/13 13:58, Ian Stakenvicius wrote:
>>
>>
>> How about, you know what you're doing and are going to build a new
>> kernel as soon as the emerge finishes (since the emerge is also
>> bringing in a new gentoo-sources)??
>>
>
> If you'
On Thu, Jan 24, 2013 at 9:22 PM, Michael Orlitzky wrote:
> Using package.env is preferable, since it basically exists in lieu of
> prefixing every environment variable with $PN. But I don't particularly
> care about the details. I was just curious if there are real cases where
> the config check w
On Fri, Jan 25, 2013 at 4:19 AM, Dirkjan Ochtman wrote:
> On Wed, Jan 23, 2013 at 2:14 PM, Samuli Suominen wrote:
>> please review this news item, seems we need one after all
>
> Here's a crazy idea: can we patch our kernel to let "make oldconfig"
> default CONFIG_DEVTMPFS to true? Or better yet,
On Fri, Jan 25, 2013 at 1:24 PM, Nuno J. Silva wrote:
> Is there any syntax to check if something is either disabled or built as
> a module?
Very problematic. What is built in for the currently running kernel
can be fairly reliably determined by grepping /proc/config.gz - IF
support for that was
On Fri, Jan 25, 2013 at 2:05 PM, Pacho Ramos wrote:
> Does it apply to /dev/shm? That is the line I have in my fstab:
> shm /dev/shmtmpfs
> nodev,nosuid,noexec 0 0
No. It applies ONLY to /dev - if you even have a /dev line, and if
you don't that is OK.
Rich
On Fri, Jan 25, 2013 at 2:19 PM, Christopher Head wrote:
> Surely even that isn’t good enough, since the user could have built an
> option as a module, tested it out, discovered it worked fine, and then
> rebuilt the kernel with the option set to Y, but the .ko file would
> still be left lying aro
On Fri, Jan 25, 2013 at 2:47 PM, Nuno J. Silva wrote:
>
> Sorry, what's the difference between cheching =y and =m? I thought those
> were both part of the kernel config...
I'm talking about /proc/config.gz, which only reflects .config at the
time that the kernel was built. So, build with config=
On Fri, Jan 25, 2013 at 3:06 PM, Nuno J. Silva wrote:
> Well, we could also get rid of issues with clashing USE flags by getting
> rid of USE flags and offering monolithic binary packages with almost
> every compatible feature enabled by default.
I'm not suggesting that we get rid of options - on
On Sat, Jan 26, 2013 at 11:01 AM, Diego Elio Pettenò
wrote:
>
> There's also a different kind of capabilities, in theory, relating to
> users instead and using PAM — but I never got to get it working :(
I naively assumed that if you edit /etc/security/capability.conf this
would set the per-user c
On Sat, Jan 26, 2013 at 5:30 PM, Fabio Erculiani wrote:
> What I always wondered is why we have ebuilds for every kind of binary
> except for kernels, yet we build official kernels with official
> configs for our livecds.
Yup. I don't think the solution is to have a USE flag for every
kernel par
On Sat, Jan 26, 2013 at 7:31 PM, Peter Stuge wrote:
> Rich Freeman wrote:
>> having a standardized kernel with a few flags probably isn't a bad idea.
>
> That doesn't scale at all. Suggest instead take a .config as input to
> the emerge, maybe something like save
On Sun, Jan 27, 2013 at 10:08 AM, Samuli Suominen wrote:
> I see a lot of packages installing /etc/modprobe.d when it should be treated
> like /etc/udev, so only generated files and users own files
On a related note, I just noticed that /etc/udev is loaded with
orphans in my case, and I can't ima
On Fri, Feb 1, 2013 at 3:21 AM, Alec Warner wrote:
> On Thu, Jan 31, 2013 at 11:36 PM, Vaeth
> wrote:
>> Please, please, stop removing packages for no reason!
>> This happens now way too often:
>>
>
> If folks do not want to maintain it anymore, then it will be removed.
> Feel free to contribute
On Fri, Feb 1, 2013 at 12:37 AM, Ryan Hill wrote:
>>
>> If we added a "Keyword/Stable Request" component to the "Gentoo Linux"
>> product we could also have it dependent on that, so only bugs in that
>> component would display the flags.
You'd need to include security bugs as well at the very lea
On Fri, Feb 1, 2013 at 6:20 AM, Diego Elio Pettenò
wrote:
> On 01/02/2013 12:11, Rich Freeman wrote:
>> I do think it is a loss for Gentoo if we start removing packages
>> simply because they don't change (which is all a dead upstream means -
>> it isn't always a
On Fri, Feb 1, 2013 at 7:53 AM, Diego Elio Pettenò
wrote:
> I'm not saying that we should remove a package because it has one
> trivial bug not fixed in three months. But when upstream is dead, and
> nobody in Gentoo is caring for it, has half a dozen open bug (trivial or
> not), unsolved or unsol
On Fri, Feb 1, 2013 at 8:36 AM, Wulf C. Krueger wrote:
>
> And how will you get to know about current or future security issues if
> nobody (in Gentoo) cares about the package?
The same way that you know about security issues in Firefox or
Chromium - somebody reports them. Security bugs still go
On Fri, Feb 1, 2013 at 9:08 AM, Wulf C. Krueger wrote:
>
> In the "dead upstream" case it's unlikely anyone is checking the
> package for security issues in the first place. So neither the Gentoo
> security people will get notice via the usual sources nor will any
> upstream be informed.
That see
On Fri, Feb 1, 2013 at 8:53 AM, Tomáš Chvátal wrote:
> If you as developers and users find some package useful you can retake
> the maintainership (or became proxy-maint) which also expects you to
> take care of the bugs (QA can prune it even if you take the
> maintainership but ignore failures [e
On Fri, Feb 1, 2013 at 10:51 AM, Richard Yao wrote:
> I suspect that the removal message is inaccurate. The actual reason for
> removal is the following:
>
> https://bugs.gentoo.org/show_bug.cgi?id=425298
>
> If you were to make a webpage for it and host the tarball for people, it
> should be poss
On Fri, Feb 1, 2013 at 5:54 PM, Diego Elio Pettenò
wrote:
> On 01/02/2013 23:52, Rich Freeman wrote:
>>
>> For those who are doing the treecleaning, please do yourself a favor
>> and point out the actual show-stoppers so that you don't have a war on
>> your ha
On Sat, Feb 2, 2013 at 6:44 AM, Vaeth wrote:
> I just ask that Gentoo should not *hinder* the user in installing/
> maintaining a package later by removing the tarballs (and possibly
> patches) which once were available.
So, I can see the validity of this argument insofar as it applies to
Gentoo-
On Sun, Feb 3, 2013 at 7:46 AM, Pacho Ramos wrote:
> Due matsuu lack of time the following packages are up for grabs:
> app-backup/dar
I'll take this one. Looks like most of the open bugs should be trivial to fix.
Rich
On Sun, Feb 3, 2013 at 12:07 AM, Vaeth
wrote:
> Yep! That's the right attitude: Give the people 30 days (even those
> people who are currently not at Gentoo for whatever reason) to know
> years in advance all the software they might ever need and tell them,
> if in doubt, just to maintain hundred
On Tue, Feb 5, 2013 at 11:59 AM, Dirkjan Ochtman wrote:
> I think it's really quite silly that we keep inconveniencing ourselves
> and our user by not having proper certificates that get recognized by
> all the major browsers, preferably wildcard variants (particularly for
> Bugzilla attachments).
On Tue, Feb 5, 2013 at 1:48 PM, Alec Warner wrote:
> Doesn't work on my non-gentoo OS..Perhaps we should provide debs and rpms? :)
That sounds like a separate bug. We provide handbooks for that one. :)
Rich
(And yes, as I noted in my original post I realize that certs from a
"real" CA would b
On Thu, Feb 7, 2013 at 12:53 PM, Markos Chandras wrote:
> On 02/07/2013 05:00 PM, Ian Whyman wrote:
>>> !!! ERROR !!! SYSTEM ERROR !!! SYSTEM FAIL !!!
>>
>> Yikes. I didn't touch anything, honest!
>>
>
> lets hope infra will ban him from the list
What's with all the leniency? I thought we used t
On Fri, Feb 8, 2013 at 7:10 AM, Kfir Lavi wrote:
> How people serve binaries (tar.gz source files) to complement the
> repository?
> Github doesn't seem to have a way to have a binary repository and serve
> single files.
> Heroku maybe?
Single files - not sure (maybe a raw URL?).
However, any ta
On Sat, Feb 9, 2013 at 9:12 AM, Luca Barbato wrote:
> I hope somebody not Libav nor FFmpeg committer could come up with a
> pros-cons list.
++, but frankly the committers are probably in the best place to do
any evaluation even if they likely have some bias. If you wanted to
delve into the merit
On Sun, Feb 10, 2013 at 6:48 AM, Michał Górny wrote:
>
> +1. If you can't manage moving/updating your packages properly
> and on-time from the sci overlay, please get rid of it.
Seems like the alternative solution is to just not have these ebuilds
in the main tree.
There is nothing wrong with ha
On Sun, Feb 10, 2013 at 7:51 AM, Alexander Berntsen
wrote:
>
> On 10/02/13 13:11, Rich Freeman wrote:
>> - just look up your average non-core piece of FOSS software and the
>> first thing their Ubuntu install instructions will tell you to do
>> is to add some repository
On Sun, Feb 10, 2013 at 9:37 AM, Tomáš Chvátal wrote:
> no matter what are Richs opinions he is not the one crating global policies
> for this, so the defaults still are that we encourage adding all stuff to main
> tree where possible.
Relax, and don't make it personal.
The bottom line is that s
On Sun, Feb 10, 2013 at 10:10 AM, Ben de Groot wrote:
> On 10 February 2013 20:11, Rich Freeman wrote:
>> Otherwise, purpose-driven overlays just make sense - they allow a
>> different set of contributors who are more familiar/interested in a
>> set of packages to mainta
On Tue, Feb 12, 2013 at 2:21 AM, Ian Whyman wrote:
>
> Can we not just have a developer wide vote or something? This instance
> clearly not going to resole itself.
I don't think the average developer is really in a good position to
resolve this - it will just create a whole lot of fuss and who kn
On Thu, Feb 14, 2013 at 2:12 AM, Michał Górny wrote:
> Or N^4 people downloading ebuilds which serve no purpose whatever. That
> stacks faster than you think.
>
That seems more like an argument for not having non-free (as in beer)
proprietary software in the tree at all.
I have mixed feelings on
On Thu, Feb 14, 2013 at 7:06 PM, Diego Elio Pettenò
wrote:
>
> The presence of "dozens of overlays" _is_ hurting triaging and other
> issues. Things like proaudio overlay should die in a fire, and stop
> bothering us to begin with.
How? We don't support overlays in the main tree. I could see a
On Thu, Feb 14, 2013 at 7:19 PM, Diego Elio Pettenò
wrote:
> The problem is when you have to triple-check that the user hasn't
> enabled some random fucked up overlay and you have to guess whether that
> might be the cause of the problem. Yes it happens, not so rarely.
Ah, I always thought of ove
On Sun, Feb 17, 2013 at 12:45 PM, Andreas K. Huettel
wrote:
> Joking aside, I can imagine architectures where it's preferable to set up a
> stage directly from a running maintenance system (maybs s390???). Also, none
> of my arm gadgets comes with a CD drive, so I had to e.g. prepare the stage on
On Tue, Feb 19, 2013 at 11:43 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> If all upstream has is a git tarball, what about git-snapshot builds?
> Use the git2 eclass and set a commit number, thus allowing testing and
> stabilization of a specific commit, but the checkout would be directly
> from ups
On Wed, Feb 20, 2013 at 8:17 AM, Diego Elio Pettenò
wrote:
> On 20/02/2013 13:02, Rich Freeman wrote:
>> I'm actually wondering if that makes sense with git when a specific
>> commit is referenced, since everything is content-hashed anyway.
>> Perhaps we just need to
On Wed, Feb 20, 2013 at 11:45 AM, Alec Warner wrote:
> On Wed, Feb 20, 2013 at 8:28 AM, Peter Stuge wrote:
>>
>> It makes no sense to make that unneccessarily difficult for users.
>
> I don't think fetch restriction is that annoying. You could argue that
> we do it debian / ubuntu style where the
On Wed, Feb 20, 2013 at 12:25 PM, Alec Warner wrote:
> A live SCM ebuild
> is not the only way to deploy something. If the user has to go
> download a blob out of linux-firmware's gitweb because we feel we
> cannot legally distribute the firmware, then that is what they have to
> do. If the user h
On Wed, Feb 20, 2013 at 12:32 PM, Diego Elio Pettenò
wrote:
> That being the case, splitting them in multiple packages might indeed be
> a better option. Yes I know I'm the one pushing for using a single
> package — as long as it doesn't have licensing issues of course.
Yup, a combined package th
On Wed, Feb 20, 2013 at 2:20 PM, Chí-Thanh Christopher Nguyễn
wrote:
> Rich Freeman schrieb:
>> 4. Non-fetchable - do not combine.
>
> I don't see a reason for fetch restriction, as long as a direct download
> link from upstream exists (via gitweb).
Agreed. You would onl
On Thu, Feb 21, 2013 at 3:44 PM, Ulrich Mueller wrote:
>> On Thu, 21 Feb 2013, Greg KH wrote:
>> I think this is something that the Board needs to decide, after
>> discussing it with our lawyers, it's not something that non-legal
>> people (like myself) should be saying is the definitive answe
On Thu, Feb 21, 2013 at 5:44 PM, Greg KH 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
On Fri, Feb 22, 2013 at 9:00 AM, Michał Górny wrote:
>
> You can also use git-2 eclass-specific variables to switch the repo.
> The only difference is that you need to specify the full repo URI
> rather than just the author.
The full repo URI is actually copy-pastable from github, while
breaking
On Sun, Feb 24, 2013 at 9:23 AM, Pacho Ramos wrote:
> I would like to ask about adding "systemd" USE flag to use.stable.mask
> to let us stop needing to revbump packages with optional systemd support
> when stabilizing them.
>
> Are you ok with that?
Am I interpreting the impacts of this correctl
On Sun, Feb 24, 2013 at 9:43 AM, Pacho Ramos wrote:
>
> Isn't there any way to unmask systemd USE flag on your local setup
> (running testing systemd)?
>
Wasn't aware that could be done. That makes sense all-around - it
even allows you to run the stable packages with the unstable flag
(which wou
On Mon, Feb 25, 2013 at 9:33 AM, Alan McKinnon wrote:
> Linux client invariably whinge at length about how the performance of
> samba sucks.
I suspect there is more at issue than just performance.
I run both samba and nfs (though without kerberos), and have the
windows issues you mentioned, and
801 - 900 of 2196 matches
Mail list logo
