J. Roeleveld wrote:
I, as a user, prefer not to have to hunt for firmware for devices
supported vy the kernel. I would either install all of them or
filter out the firmwares for devices I am unlikely to get.
I, as another user, prefer not to have a whole bunch of firmware
installed if I only
!!! 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 the death penalty on
the first offense?
Oh I am sorry. I didn't realize you like spammers on this
Rich Freeman wrote:
any tag in Github can be downloaded as a tarball with a constant md5
Note that gitweb also offers snapshot links. Many upstream gitwebs
have that feature enabled, saving even the work of mirroring to github.
//Peter
Tomáš Chvátal wrote:
we as gentoo will provide both while preffered default will be what
major distros use.
What kind of careless mainstream attitude is that? Really?
I mean: You are saying that given two options, Gentoo will do
whatever major distros are doing.
(Never mind that Gentoo *is* a
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 savedconfig for busybox, and add
shortcuts for common options.
That way, the same mechanism can be
Alec Warner wrote:
[..removed 25 lines of quoted text which I had already read..]
The primary complaint was the fact that there is too much email.
Many emails are not neccessarily a problem if only they have high
signal-to-noise ratio.
I have *never* seen so competent people output so
Panagiotis Christopoulos wrote:
I don't build server machines every day, others do and it would be
much appreciated if they could respond here.
I build catalyst stage4s. Any default profiles are kindof pointless
for me; I have USE=-* and the flags that I want.
Anything else seems a bit too
Doug Goldstein wrote:
sys-firmware/ipxe, sys-firmware/seabios, sys-firmware/sgabios,
sys-firmware/vgabios
..
So basically, how important is it to keep supporting these separately
buildable blobs knowing that it might slow the release of QEMU within
our own tree.
Each of those sys-firmware/
Doug Goldstein wrote:
we go through the effort to ALLOW users to build their own binary
blobs but is it really necessary as part of our culture?
I don't think that question can be answered?
The way I see it either someone maintains those packages, or not.
I'd be sad to see them go, but am not
Samuli Suominen wrote:
I almost changed it back myself already but to avoid stupid commit
wars didn't.
Interesting comment considering how blazing fast you were to commit
a change of the default for another forked project.
It's just another fork, not an upgrade.
Interesting comment indeed.
Rich Freeman wrote:
I'd just stick with a simple parameter like --upgrade
Yes please!
or an alternative command name like emerge-update.
Please no!
Oh, here's another crazy thought. How about some directory in /etc
that sets rules for emerge-update (or whatever we call it)? You might
Tobias Klausmann wrote:
It has been rather nifty that if I walk up to a random machine
with exactly one NIC (that I've been asked to examine/fix), I
_know_ that there will be eth0 and only that.
Only as long as that system hasn't seen *another* NIC first, if it
has persistent interface name
Paul Arthur wrote:
On 2013-01-17, Maxim Kammerer m...@dee.su wrote:
All in all, secure-delete has its uses. What are people supposed to
use instead, dd if=/dev/zero of=/media/sdcard/naked_gf_0001.jpg?
Perhaps 'shred', which is part of coreutils?
From man shred:
CAUTION: Note
Rich Freeman wrote:
Anybody who runs debian knows that the only two commands you really
need to know are apt-get --update and apt-get --upgrade. We really
need to keep things just that simple.
We're halfway there;
emerge --sync
So how about adding:
emerge --upgrade
?
//Peter
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?
//Peter
Steven J. Long wrote:
What I'm not in favour of is making the simple cases more
difficult, to deal with the complex ones. It's completely
brain-dead thinking.
This is exactly what some people think or say when they learn that I
use Gentoo.
I appreciate Gentoo because I am able and willing to
William Hubbs wrote:
I have a bug opened with the docs team and release engineering
to discuss whether we want the new names for new installs.
IMO yes we do.
What's that bug - or what is the good way to thumbs up/down?
//Peter
pgpswXbIiseJI.pgp
Description: PGP signature
Ben de Groot wrote:
Is it really newsworthy to say that the Gentoo developer community
thinks we haven't accomplished much?
Spin it: Write that you asked developers but only got very little
feedback (literally only a handful of people replied), summarize the
replies, and then ask for a dialogue
Maxim Kammerer wrote:
Also, how widespread is client DNSSEC support? E.g., I enabled
DNSSEC for my domain, but not sure yet whether DNS resolution
anywhere will fail in case DNS responses are spoofed.
There is a gap between applications asking resolvers to do lookups
and resolvers which can do
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. :\
dev-libs/libusb is the default implementation from libusb.org, yet
you are astonishingly eager to *avoid* that it is the
Rich Freeman 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 implementation is
what matters, so much as what works best for our
Alexis Ballier wrote:
- I have package foo and package bar, both depending on ffmpeg and
canditates for a multilib build. However, package foo does not link to
ffmpeg but simply spawns the 'ffmpeg' binary to process some files,
package bar links to libavcodec. You need ffmpeg[multilib] for a
Jeroen Roovers wrote:
For once someone suggests a single good case where git beats CVS for
portage tree changes: easily checking suggested changes ...
Did you look at Gerrit one of the many times I mentioned it already?
That is what it is for, and it is pretty great.
A shiny new workflow
Michael Hampicke wrote:
can binpackages easily be regenerated locally if their ebuilds are
not in portage anymore?
If the package is still installed it is very easy with quickpkg.
//Peter
Markos Chandras wrote:
I'm really just trying to understand the sense in this.
--
Doug Goldstein
Your tone is not appropriate for discussion.
Sorry Markos, I disagree with you. Doug makes it abundantly clear
that he wants to understand. I think we can all recognize that, in
particular
Markos,
Markos Chandras wrote:
I totally disagree with the way Doug started this thread.
That's of course completely fair, but try to look beyond that, and
let's focus on how we can make things better for everyone.
Calling us brain dead ?
Please read email even more carefully, especially
Rich Freeman wrote:
I think the bar for keeping access should be kept low - they
shouldn't be forced to go find some trivial change to make just
to get their name in the logs.
When I first started looking into becoming a Gentoo developer I got a
very strong and very clear impression that this
Peter Stuge wrote:
I think the bar for keeping access should be kept low - they
shouldn't be forced to go find some trivial change to make just
to get their name in the logs.
When I first started looking into becoming a Gentoo developer I got a
very strong and very clear impression
Duncan wrote:
Apparently, IRC is a hard requirement. At least the one final
evaluation must be done on IRC.
I understand why online communication is not everyone's prefered format.
I guess that the IRC part of the recruitment is not very formal, I
don't know as I haven't seen one, but in
Richard Yao wrote:
Where is development now?
We have rewritten the build system and restored support for older
kernels and verified compatibility as far back as Linux 2.6.31. We have
tagged 1_beta1 and eudev is in the portage tree. A few lingering
dependency issues exist, but we
Brian Dolbec wrote:
remove entries in profiles/updates for tree-cleaned packages...
What's the advantage of doing that?
None
..
FYI... Currently there are updates files in profiles/updates/
dating back to 2004
Do they take up significant storage space or transfer time, compared
to
Chí-Thanh Christopher Nguyễn wrote:
# isohybrid image.ISO
Please send a patch to the gentoo-catalyst@ list which adds this as
an optional step in the catalyst livecd2 target in a nice way, and
file a bug with updated ebuilds for catalyst which add the dependency.
Bug was already
Matt Turner wrote:
I think we should consider things that break release media serious
regressions.
I think we should consider things that break anything serious
regressions.
Why should release media be more special than anything else?
My email and bugzilla sweep a few days ago was during a
Fernando Reyes wrote:
iirc the minimal install CD ISO is capable of booting from a USB device or
any removable media by just running the following commands.
# isohybrid image.ISO
Please send a patch to the gentoo-catalyst@ list which adds this as
an optional step in the catalyst livecd2
Markos Chandras wrote:
This policy is for the bug-wranglers project, which someone must
read before he attempts to do any bug-wrangling.
I see no reason to move this to devmanual.
The reason is that I as a developer (whenever I become one) want to
be able to fix stuff right now that is broken
Ian Stakenvicius wrote:
Essentially, if the problem is with the ebuild or the way the package
is integrated into gentoo, then fixing it immediately is fine. If the
problem is with the software itself, then usually upstream needs to be
involved before the fix will occur in gentoo.
Yes that's
Alec Warner wrote:
Testing all the updates is basically not possible. Understanding
the updates is basically not possible.
I think it's very possible to understand updates which are important
for the system.
Of course it is a lot of work if it is to be done every day. I would
not update
Pacho Ramos wrote:
Looks like cman stabilization (that is needed to stabilize newer lvm2,
that is needed to stabilize newer udev...) is blocked by its init.d
script wanting to load modules even on kernels without modules:
https://bugs.gentoo.org/show_bug.cgi?id=442512#c5
Arch team people
Michael Orlitzky wrote:
I just get annoyed with the don't use Gentoo unless you like your
stuff broken attitude.
Don't confuse stuff changing with stuff breaking - they are very
different things.
In Gentoo stuff changes every single day. I heard that gentoo-x86
gets some number of commits per
Ole Markus With wrote:
Maybe I could change the currently masked php5-5 slot to php5_5 instead
and then eventually phase our the hyphen based slots. This would mean
inconsistency between the php slots for some time, but eventual
consistency with Python, which I do see as a good thing.
I think
Diego Elio Pettenò wrote:
On 24/11/2012 07:46, Brian Dolbec wrote:
For ruby19, split in the middle to get 1.9, but what about 110, is it
11.0 or 1.10.
Okay stop.
There's no 1.10.
There's 2.0 that's being developed for a long time.
And we're not going to change our scheme just
Jauhien Piatlicki wrote:
PHP_TARGETS=5.3 5.4
RUBY_TARGETS=1.9
PYTHON_TARGETS=2.7
But maybe it would be too problematic?
What will you do with PYTHON_TARGETS=python2_7 python3_2 pypy1_9
jython2_5 then?
That's an excellent point. Thanks!
Thinking out loud another round: _TARGETS is
Peter Stuge wrote:
Thinking out loud another round: _TARGETS is an interface by Gentoo,
so maybe it would not be such a bad idea to use existing Gentoo
identifiers there, ie. (a subset of?) PMS version specifications.
Including the package name. This would also make the UX change
smaller
Anthony G. Basile wrote:
The answer appears to be that a file is the unit
I personally consider it to be smaller; a number of lines within
a file, or even a single line, all depending on things.
//Peter
Greg KH wrote:
this isn't obvious at first glance, go consult a copyright lawyer
for the specific details if you are curious about it.
Which, again, I strongly feel that the Foundation needs to do
+1
before anymore Copyright Gentoo Foundation marks get added to
_any_ files in our tree.
Steven J. Long wrote:
Nor should Gentoo projects suddenly change what they are because
the internet doesn't understand them. That's a ridiculous basis
for any change.
If a friend whom I care about and respect tells me that they don't
understand something I do then I try to consider if maybe I
Rich Freeman wrote:
Nor should Gentoo projects suddenly change what they are because
the internet doesn't understand them. That's a ridiculous basis
for any change.
It doesn't always matter what others think, but it is always worth
considering. It matters a lot for how one is
Ciaran McCreesh wrote:
a quick consultation with a copyright lawyer can provide us with
a very good set of rules and boundry conditions
The last time someone from Gentoo spoke to a copyright lawyer, it
resulted in a year-or-so-long ban on recruiting anyone, and everyone
was supposed to
Duncan wrote:
kmod itself is trivial in size time and space requirements, but it's
the principle as much as anything, and in the case of an unneeded
module loader there's an additional security concern as well
I'm afraid this is flawed. If you want to hinder modules from being
loaded then you
Rich Freeman wrote:
I think that there's a big difference about any developer
being allowed to create a project under the gentoo umbrella and
create a project and claim it as Gentoo sponsored without any
review of the council. I agree that it can exists in the Github
account, or even in
Samuli Suominen wrote:
I'm just afraid our XFCE port gets lagged behind because of this as
compared to other distros ...
I am, as you know, a strong proponent of doing things right, rather
than doing them fast.
In this case that means that it is not the end of the world if Gentoo
ebuilds do
Samuli Suominen wrote:
so unless you are willing to go that far as introducing yourself at the
xfce devel mailing list and accepting the mantle of upstream of them, we
are really stuck at this distribution level patching just like others
That makes no sense to me. If you (not you
Diego Elio Pettenò wrote:
One of major problems with this tinderbox is that it cannot be
used to test packages against newer versions of packages present
in overlays [1]
Which is not a problem since we're _not_ talking about packages
in overlays but of a bump in the main tree which is
Graham Murray wrote:
Christ on a $#@%! crutch. You can NOT auto-enable C++11 in your library
based
on a configure test and then stuff flags that are not supported by previous
compiler versions into pkg-config for library consumers. Somebody sane
please fix this.
Though is it not
Ryan Hill wrote:
You can NOT
I am not saying that it is a good idea, but of course you can. It has
pretty sucky effects on how your library can be used, disabling
various smart stuff that modern systems do, but I guess the upstream
practises may be from a different time.
Somebody sane please
Diego Elio Pettenò wrote:
Um, so how come an overlay isn't the obvious method for testing,
before putting things in the main tree? What other method is *more*
convenient for testing?
package.mask
Can you clarify? Do you propose that developers carry out wild
experiments by committing
Diego Elio Pettenò wrote:
the understanding of you're responsible for whatever you commit.
A load of bull IMO. Is this rooted in some stupid US law thing (via
the foundation) or merely in some cowardly individual disconnected
from the real world, phrasing stupid blanket rules? Or something else?
Pacho Ramos wrote:
So, rephrasing the example Alexandre pasted, consider:
x11-libs/qt-core - The Qt toolkit is a comprehensive C++ application
development framework.
vs.
x11-libs/qt-core - A comprehensive C++ application development framework
Which one is
Pacho Ramos wrote:
Seriously, what people is still having problems with handling eapi4?
Seriously, what people are still having problems with trimming quotes?
Pacho, I wrote a sarcastic manual for you about how to trim quotes in
your replies on the mailing list, but you are still not doing it.
Alec Warner wrote:
All services except packages.gentoo.org and bouncer.gentoo.org should
be functional again (we are waiting on an ACL changes for p.g.o.)
According to icinga, the outage was approximately 20h (packages
continues to be down.)
Probably nobody even noticed. I sure didn't.
Ben Kohler wrote:
In my ideal world (if I were king), today I would delist them
from profiles.desc, and send out a news item warning of their
immediate deprecation and planned removal 3 months from now.
I'm strongly in favor of this, but of course I am no developer.
//Peter
Rich Freeman wrote:
PKI becomes a nightmare if anybody but devs sign, and when we move to
git it won't really be possible to have anybody else sign anyway
unless we allow merge commits, which is just a whole different mess.
I'm not sure? Signatures can be made on anything by anyone and stored
Ben Kohler wrote:
Thoughts?
+1 for removing noise.
Ben de Groot wrote:
The -commits ML is okay (tho I don't want to subscribe to such a
high-volume ML), but we miss an IRC interface. The website and
statistics of cia.vc were nice too.
What is the source data, and what does the desired output look like?
(I mean what should the messages in
Ben de Groot wrote:
What is the source data,
Still unanswered. I'll ask something which would be equally helpful:
Where is the software that currently sends out emails to the -commits list?
and what does the desired output look like?
CIA-5 tetromino *
Rich Freeman wrote:
I doubt everybody is going to be happy if somebody convinces infra
to shut down cvs without any discussion first.
I would do exactly that, actually.
There's been years of discussion. There's even a mailing list for
discussion.
//Peter
Gregory M. Turner wrote:
fuck everyone, we are doing this, here is the changeover date.
Well put. When is the date? I suggest October 5th, 18:00 UTC.
//Peter
Diego Elio Pettenò wrote:
Honestly, this whole thread, with the exception of Rafael, makes me
facepalm incredibly, because everybody is saying it's easy!
without asking the people who have done the work up to now and will
have to manage it.
Noone said it's easy.
Please don't put words in my
Diego Elio Pettenò wrote:
With all due respect,
..
you calling for shutdown dates
..
is obnoxious.
I don't know about respectful, but oh well..
Another idea I have, besides the go-ahead+fix what breaks, is that
after everything has broken, Gentoo developers will not be spamming
this mailing
Diego Elio Pettenò wrote:
Another idea I have, besides the go-ahead+fix what breaks, is that
after everything has broken, Gentoo developers will not be spamming
this mailing list like three-year-olds screaming rude complaints
about how things do not work and calling infra bad names, but
Michał, Pacho, and everyone else who suck epically at this:
CAN YOU FFS START TO TRIM QUOTES IN YOUR EMAILS!
Thank you
//Peter
pgpJmV3IkjFsp.pgp
Description: PGP signature
Ben de Groot wrote:
I kinda like jabberd.
So step up and take on maintainership of that package.
I would have, had I been a developer.
You don't have to be a developer:
http://www.gentoo.org/proj/en/qa/proxy-maintainers/
And still be dependent on someone else?
No, that's not the
Pacho Ramos wrote:
# Pacho Ramos pa...@gentoo.org (16 Sep 2012)
# Upstream keeps inactive for ages and, then, it has broke again
# now with gnutls-3 (#421385). Removal in a month.
net-im/jabberd
What about the 1.4 version? It depends on openssl, so maybe it
doesn't have
Rich Freeman wrote:
Well, as a user there are only two ways to get or keep your
favorite package in the tree:
..
If your favorite package isn't in the tree you can:
..
I know all this, and I have my own overlay because I'm not a developer.
I was just saying that proxy-maintaining isn't
Gregory M. Turner wrote:
Please see https://bugs.gentoo.org/show_bug.cgi?id=430722, especially
the final two posts.
I think the problem is that upstream isn't multilib-aware.
I also think that it would be awesome if Gentoo could handle such
situations for us. The brute force method would be to
Pacho Ramos wrote:
# Pacho Ramos pa...@gentoo.org (16 Sep 2012)
# Upstream keeps inactive for ages and, then, it has broke again
# now with gnutls-3 (#421385). Removal in a month.
net-im/jabberd
What about the 1.4 version? It depends on openssl, so maybe it
doesn't have the gnutls issue.
I
Brian Harring wrote:
Comments?
: is used for namespaces elsewhere too. The familiarity is good.
//Peter
Ben de Groot wrote:
On 16 September 2012 23:40, Peter Stuge pe...@stuge.se wrote:
Pacho Ramos wrote:
# Pacho Ramos pa...@gentoo.org (16 Sep 2012)
# Upstream keeps inactive for ages and, then, it has broke again
# now with gnutls-3 (#421385). Removal in a month.
net-im/jabberd
What
Canek Peláez Valdés wrote:
You can get as much vertical integration with Gentoo as with any other
distro. The problem (and I think this is the point Greg is trying to
make) is that it will be harder (not impossible, just harder) if most
of Gentoo developers really believe that every single
viv...@gmail.com wrote:
First problem udev/SD has is that it can't see all the file system labels,
for some reason it only see sda and sdb so it's able to partly proceed in
the boot sequence, mount / (root) but can't mount anything else.
What software parses the filesystem labels when you
Duncan wrote:
given that a number of gentoo devs support larger installations of
gentoo and aren't likely to be wanting to switch servers, etc, to
systemd just because it's there
I think that once they've learned systemd, they will want to switch
those servers fast.
I use it on one sort-of
Luca Barbato wrote:
Repeat after me: having your first process require anything more
than libc is stupid and dangerous.
Why do you say?
And why is libc different from other libraries, say libuuid or
libext2fs? I mean: Why allow pid 1 to require libc, it could
just be statically linked.
Rich Freeman wrote:
Systemd is a bit more like a shepherd, looking after things for
their entire lifecycle.
This is a big part of why it is so useful.
I threw out init scripts because it was retarded to not monitor
long-running processes on servers.
Those processes shouldn't fail, but
Canek Peláez Valdés wrote:
So let people make their OpenRC+mdev systems without systemd, and let
people make their systemd+udev systems without OpenRC. Everybody wins.
I for one expect nothing less of Gentoo.
//Peter
Kent Fredric wrote:
(While the link I had saved was stale it did mean I still remembered
enough about it to plug the idea into google and successfully find it.
Link updated. =:^)
https://duckduckgo.com/?q=reverse+hgual%20doog%20a%20ekil%20sdnuos%20taht
Google not required ;D
Internet
Duncan wrote:
I believe there's quite a few list readers who have a similar respect
for his efforts.
I believe so too!
I think it's a great effort. It may not fit my use cases, but I don't
care about that - even if it is *only* Walter scratching his own itch
I agree that it's important to show
Walter Dnes wrote:
I remember when xpdf was removed, epdfview was recommended as a
lightweight alternative. How about this time?
Try apvlv. Note, you *MUST* first build poppler with the
xpdf-headers USE flag. Only then will apvlv build properly. I've
reported this bug, and I assume
Samuli Suominen wrote:
our mupdf package sucks wrt bugs 407805 and 407807
It's pretty clear that the latter is an upstream problem. Will you
fix it?
//Peter
Kent Fredric wrote:
I suggest, that due to the volatility of such actions, a user should
have to approve each bulk move before it is done, to avoid breaking
things.
Further thoughts about this:
* The move is needed for some reason.
* The person running emerge will in the common case not know
Rich Freeman wrote:
In the future it might be much harder to run Gnome on Gentoo on an OSX
kernel, etc.
Yes, but if the upstream that is Gnome decides to start depending on
systemd features then that's their decision, and the place to discuss
if it's good or bad (more important, the place to
Rich Freeman wrote:
I suspect upstream would say that if you want a smooth desktop
experience you shouldn't be running Gentoo. To some degree they
probably even have a valid point.
Yes and no.. I think it will always be possible to use Gentoo to
create as smooth a desktop experience as any
Marc Schiffbauer wrote:
+ if [ -d ${ROOT}/lib/udev ]
If you don't use double [[ then ${ROOT} will need quoting
This was only true if ${ROOT} stood there on its own. IMO if you have
${ROOT}/foo you do not need quoting because even if $ROOT is empty
you will not get a syntaxt error.
I
Walter Dnes wrote:
The fact that other distros do it does not constitute
justification for us to do it.
Unfortunately that exact reason, along with Fedora is doing it, was
cited by a very active developer as reason to reject technical points
which I tried to make a few times.
But that is
Duncan wrote:
the responsibility of whatever organization to either follow
thru or repudiate, as it's the reputation and credibility of
that organization on the line if they don't.
I think it's unreasonable to expect any third party to accept
responsibility for a receiver which is
Pacho Ramos wrote:
Help is needed
I'd actually just run bird instead.
fails to build: https://bugs.gentoo.org/show_bug.cgi?id=421861
Did anyone report it upstream?
//Peter
pgp7wB8cqKxOl.pgp
Description: PGP signature
Rick Zero_Chaos Farina wrote:
sys-bios?
Whatever you (Gentoo developers) do, do not use bios for the
category -- well not for anything really.
BIOS is merely one specific type of (shitty beyond belief) firmware
on one specific type of (shitty beyond belief) hardware. (Well, I've
seen the odd
William Hubbs wrote:
/etc/init.d/foo stop start
would no longer work the way you might expect because there would be no
way to tell whether start is a command or an argument to stop.
What are your thoughts about this change?
/etc/init.d/foo stop start
along with all other commands can
Rich Freeman wrote:
5. When something goes wrong you can get a dash/bash shell
..
useful even if you don't have firefox+X11 in your initramfs.
This is one of the first videographed use cases for coreboot.
The initramfs in the video[1] admittedly does not have a browser.
Those days, boot
William Hubbs wrote:
let's move all of the discussion of this to the bug if possible so
that it is all in one place.
That's fine and probably good.
Note that you were the one inviting email discussion about the
change. I guess you wanted rather to focus on the question if
breaking
Duncan wrote:
Alternatively, I could reconfigure inittab to start my script first
..
that actually sounds more complex
Use init. It would be a sensitive script. If it fails the kernel is sad.
//Peter
401 - 500 of 528 matches
Mail list logo
