Alexis Ballier wrote:
its kind of common sense IMHO
Unfortunately what makes sense to people is never common. :\
there shouldn't be any time limit
..
in short: if a package requires version X then the ebuild should
require version X; it can be forgotten but it's a bug.
+1
//Peter
Duncan wrote:
I believe the reason it wasn't done is because the default options
setting was added instead. Well that and the fact that (as covered
below), I guess most users setup their own scripts/aliases at some point,
at which point the existence of something that general-purpose
Tom Wijsman wrote:
For really severe bugs I think that pinging just anyone who is around
will do, alternatively you could ping the proxy maintainers herd. In
both cases there is most of the time someone available; so, it would be
a matter of minutes to have the patch applied.
You're changing
Peter Stuge wrote:
It matters a whole lot if I have to wait for someone else to
unblock me, in practice that completely demotivates me to
contribute back, and I would simply work around the block.
To clarify this point; contributing fixes back must always be the
least effort of all ways
Alon Bar-Lev wrote:
It matters a whole lot if I have to wait for someone else to
unblock me, in practice that completely demotivates me to
contribute back, and I would simply work around the block.
To clarify this point; contributing fixes back must always be the
least effort of all
Rich Freeman wrote:
If a package has a responsive maintainer, then pinging them isn't
really much of a hurdle.
I'm not so sure. Waiting for a human round trip which due merely to
time zones might occupy my attention for 24 hours (even if I
obviously do other things meanwhile) is IMO quite
Markos,
Markos Chandras wrote:
This is not a great way to invite more users to participate. If you
intend to make the game overlay and team a developer-only thing you
are doing a great work.
Everything in the Gentoo project is per definition strictly
developer-only. I suppose that it's a
Tom Wijsman wrote:
There is an alternative solution here; and that is to bring reviewed
versions of them to the Portage tree or official games repository, and
honor their contributions. That is a win-win situation for both of you.
I'm afraid that's too naive. :\
I have significant experience
Rich Freeman wrote:
This is not a great way to invite more users to participate. If you
intend to make the game overlay and team a developer-only thing you
are doing a great work.
Everything in the Gentoo project is per definition strictly
developer-only. I suppose that it's a function
Michał Górny wrote:
My laptop is broken and I no longer have any hardware that would use
this. It fails to compile with the current kernel [1] and upstream is
not really active.
I forward-ported the driver in 2011 but probably that's obsolete too.
http://git.stuge.se/stk11-driver.git
hasufell wrote:
No bump is better than a shitty bump imo.
I agree, but I think the problem is basically that many people
consider it impossible for newer to ever be shitty.
Even if they are intimately familiar with the details of a package
upstream they may still not be capable of determining
Paweł Hajdan, Jr. wrote:
compiling with versions of v8 other than what is included is not
currently supported.
..
For now V8 upstream gives no guarantees about API/ABI stability and
actually breaks it very often
I agree that it isn't worth the effort to try to offer V8 as a
library then.
As
Michał Górny wrote:
Putting another includedir is even worse kind of band-aid.
By using the expression band-aid I wasn't commenting on the virtues
of having the include file in /usr/include.
The expression rip off the band-aid is an idiom in english which
refers to minimizing the duration of
Paweł Hajdan, Jr. wrote:
Also, it may be easier to change now when we only have two headers,
than later. And you may even add compatibility symlinks or copies in
/usr/include to give people more time to update.
I think you should rip off the band-aid quickly.
Move the files and update the .pc
Michał Górny wrote:
the whole eclass is inside the if [[ ! ${_GIT_R3} ]] block.
Rather than putting the whole eclass inside a block like that maybe
it's possible to test for that condition and exit early?
exiting ebuild process in middle of inheritance chain is *not* a good idea
I
Ryan Hill wrote:
I don't like creating more work for people, so I want to be sure
there is consensus on this first. So far it sounds like there is.
I think there will come enough objections, but only down the road,
and only from people who don't want to care about quality.
Don't let that stop
Markos Chandras wrote:
the whole eclass is inside the if [[ ! ${_GIT_R3} ]] block.
Rather than putting the whole eclass inside a block like that maybe
it's possible to test for that condition and exit early?
//Peter
Luca Barbato wrote:
[3] https://wiki.documentfoundation.org/Development/gerrit
And all boils down to the fact gerrit needs to be fixed to take
patches from a mailing list
Usually Gerrit just needs an OpenID in order to accept git push via SSH.
That seems significantly better to me than
Samuli Suominen wrote:
+++ b/Makefile.am2013-08-11 23:31:55.429404471 +0200
[ ... ]
if UDEV_RULES
-udevrulesdir=$(sysconfdir)/udev/rules.d
+udevrulesdir=$(shell pkg-config --variable=udevdir udev)/rules.d
Calling `pkg-config` directly from Makefile.am doesn't work for cross
Greg KH wrote:
See above for why it is not easy at all, and, why even if we do know
some fixes are security ones, we would not tag them as such anyway.
I think this supports the argument that the better kernel is always
the one with the most fixes.
That's what us kernel developers
Tom Wijsman wrote:
what if hell breaks loose next time?
We fix it.
//Peter
pgpoxOD8NPi7O.pgp
Description: PGP signature
Tom Wijsman wrote:
Besides, who does an emerge -u world without first checking to see
what will be updated?
Some people do
They deserve a broken system.
//Peter
pgp8bIGEpU77h.pgp
Description: PGP signature
Greg KH wrote:
See above for why it is not easy at all, and, why even if we do know
some fixes are security ones, we would not tag them as such anyway.
I think this supports the argument that the better kernel is always
the one with the most fixes.
Rather than separating bug fixes from
Mike Pagano wrote:
Team members working alongside upstream (and downstream) developer Greg k-h
have decided to no longer request stabilization of the vanilla sources
kernel.
Team members and arch teams (understandably) are unable to keep up with the
1-2 weekly kernel releases, and
Alex Xu wrote:
Maybe it would make sense to automatically stabilize every v-s kernel
right away?
As has been stated, this implies that Gentoo QA has tested the packages
and found them to be reasonably safe for use.
..
Although stable kernels *have* been tested by many people before use,
Rich Freeman wrote:
As has been stated, this implies that Gentoo QA has tested the packages
and found them to be reasonably safe for use.
++
While good in theory, it seems that newer v-s are actually more
reasonably safe than any g-s.
Stable should mean something
For users, stable
Alex Xu wrote:
Maybe it would make sense to automatically stabilize every v-s kernel
right away?
As has been stated, this implies that Gentoo QA has tested the packages
and found them to be reasonably safe for use.
..
Although stable kernels *have* been tested by many people before
Rich Freeman wrote:
Stable should mean something
For users, stable means older in practice. Always did, always will.
Don't change the meaning of stable, however, for those who find it useful.
This is a good point, but the original post suggested to me that
actually every new release of
Ben Kohler wrote:
I am suggesting that the latest available upstream kernel should
perhaps be the default for Gentoo users.
You seem to be ignoring the regressions that often come with new kernel
releases, the very common breakage caused in stable genkernel all, and
other various
Diego,
hasufell wrote:
I would object... 10 games are wa too few for a new category and
especially pkg moves..
1 app-antivirus/
3 net-zope/
5 x11-base/
7 gpe-utils/
8 app-officeext/
11net-voip/
12games-kids/
12gnustep-libs/
13mail-mta/
13
Rich Freeman wrote:
Just what do wumpus (talk about a blast from the past), a game in the
spirit of nethack, and a Leisure Suit Larry spinoff have in common?
I'd say it's that they focus on exploration.
I imagine most games have some kind of adventure sense to them.
Puzzles and 52-card
Matt Turner wrote:
And? Two wrongs don't make a right.
What do you mean by And? - it doesn't make much sense as a reply. :\
He means that none of those provide justification.
It seemed that the main argument was that there are too few packages
and then then I do think that other
Diego Elio Pettenò wrote:
I don't think anyone can dispute that there exists a genre called
adventure games..
How comes scummvm is not in the list then? Just saying.
Yep, it could also be included! OTOH the VM itself isn't technically
a game.
Seriously, a category for 10 games is *not*
Diego Elio Pettenò wrote:
I bet you a tasty beverage that it will grow over time! :)
I don't believe in the future until I can see it.
Huh - what does that mean?
Obviously neither of us can say with certainty what will happen in
the future and that's also not the point - making a friendly
Diego Elio Pettenò wrote:
just opening a webcam and talking is just going to give an amateurish feeling
..as opposed to the very professional mailing list.
//Peter
Pavlos Ratis wrote:
On Mon, Jun 24, 2013 at 1:04 AM, Diego Elio Pettenò flamee...@flameeyes.eu
wrote:
Please, let's not try to make this something either mandated or recommended.
It is absolutely optional and it's just a proposal.
However, I think it's worth a try.
I think it would be a
Luca Barbato wrote:
- init gets effectively switched only at boot/reboot
Please not on reboot, because an unclean shutdown shouldn't leave the
system in limbo.
On boot could work, except that it does add more steps (= more
fragility) to the boot process, which I think everyone wants to
avoid.
Tom Wijsman wrote:
I would actually expect the change to take effect immediately.
Then how would you be able to shutdown / reboot your system in a clean
way? The premise here is that when you boot with an init system you
must shutdown with that same init system, you can't just start one
J. Roeleveld wrote:
I don't see how this will avoid the issue of a limited amount of
inodes.
That is what I usually run out of before the disk is full when
storing lots of smaller files.
I guess the number of unit files is on the order of hundreds, as long
as you haven't configured an
Rich Freeman wrote:
Gerrit also requires letting the public push, but those pushes go
to a contained area and each commit is isolated.
Hm, how do you mean isolated?
Gerrit introduces the convention to create a unique identifier for a
change the first time a commit is created. If later
Rich Freeman wrote:
The devmanual git repository[1] moved to github[2].
The only thing that isn't FOSS is github itself. Not sure if
others feel strongly about it.
I feel strongly against github.
Making something like github the primary point of contact
communicates many negative things
Markos Chandras wrote:
The repository is still accessible in http://git.overlays.gentoo.org
and read-only access is still available. However, the write access
removed because of potential conflicts between g.o.g.o and github.
If you can guarantee me that people will not mess things up and not
Rich Freeman wrote:
Gerrit
..
I've never used it myself but I'm tempted to install it just to
start messing with it personally.
Go for it! It's a few steps to set up, but it's not too bad.
Michael Palimaka wrote:
I believe Gerrit has been suggested before and rejected because it
relies on
Theo Chatzimichos wrote:
Another option that looks nice is GitLab.
How does it work? The screenshots look exactly like github.
Don't ask, just go for it!
That's not very helpful?
I'm happy to expand on my experience with Gerrit, and I'll gladly
answer specific questions if I can.
Michael Palimaka wrote:
I agree that Java is sucky, but I don't think that rejecting Gerrit
for that reason alone makes sense. Look at what the application does
and how it works, to determine if it fits the project or not.
I agree, but if infra is not willing to maintain something java-based
Alexander Berntsen wrote:
[GitHub] enforces some particular workflow
You keep saying this. What do you mean?
I'll clarify!
A lot of projects (including Linux) just use GitHub for hosting and
nothing else. I don't see the problem.
There is no problem if github is only used for hosting,
Alexander Berntsen wrote:
There is no problem if github is only used for hosting, but if it
is the primary point of contact, or if pull requests are accepted,
then github is also writing to repositories, and merge commits are
enforced for all external contributions. That does not scale at
Michael Mol wrote:
obviously you have an interesting position as a dev in a distribution,
and you might make your change there, but that certainly shouldn't be
your default course of action.
+1 and not just for unit files.
//Peter
pgpQGx9XaD1PC.pgp
Description: PGP signature
Ryan Hill wrote:
If you're fixing one of these bugs by silencing the warning be sure
to remove the flag also.
How about sending the fix upstream instead?
Thanks, from an upstream
//Peter
pgpHGm3ZpE6z3.pgp
Description: PGP signature
Jörg Schaible wrote:
icu. The ebuild happily removes any trace of the old shared libs
with the result that half of the stuff that is *required* to build
kdelibs is now broken. The build aborts and leaves behind a broken
system. And this happened now not for the first time!
Tom Wijsman wrote:
Peter Stuge wrote:
Jörg Schaible wrote:
icu. The ebuild happily removes any trace of the old shared libs
with the result that half of the stuff that is *required* to build
kdelibs is now broken. The build aborts and leaves behind a broken
system. And this happened now not for the first
Fabio, I think you're doing awesome work!
Steven, I think you can behave a lot better on the internet. kthx.
Steven J. Long wrote:
It looks like there is some consensus on the effort of making systemd
more accessible,
Sure there is: there's also consensus that this approach is wrong for
Jeroen Roovers wrote:
Er, you can't be seriously suggesting we will drop repoman checks
with the migration to git? I don't see how that would benefit anyone.
I would argue that repoman and/or corresponding checks should be run
by a CI system hooked up to the Gerrit instance that developers push
Samuli Suominen wrote:
imho,
..
we should stick to the latest stable is the stable mantra
(i'm not sure if this is even documented anywhere? and propably
should not be? keep it as maintainer specific decision like it's now?)
If it's the agreen-upon way then why not document it?
//Peter
Nuno Silva wrote:
mplayer *can* play it, but tuning is a different story.
mplayer is not really an alternative. tvtime looks and feels
significantly better.
A lot like saying that Fiat is an alternative to Ferrari.
I'm also curious if there are more known bugs than those noted in the
mask. I
Alec Warner wrote:
MC The package is going away unless someone fixes the bugs and
MC properly maintains the package
Again, that is an irresponsible mistake. It is better to just leave it
as is than to kick it. Dropping important packages can only harm the
community and is never
Markos Chandras wrote:
The masks are sort of announcements as you have 30 days to revert that
decision.
You don't seem to recognize the quite significant psychological
impact of you having already made the decision, compared to, say,
having an actually inclusive package removal process.
Rich Freeman wrote:
something is bound to break for good sooner or later if things don't change.
Certainly.
But consider the chain of events:
* user is happily using outdated, but working, software without
knowing how behind the times upstream really is, because it works
* gentoo masks and
Rich Freeman wrote:
A per-ebuild bug metric would be cool. A kind of health indicator
for individual ebuilds, alerting users when some of our installed
ebuilds go yellow, so that we have perhaps on the order of six
months before the package goes red, at which point it would be fine
to
Alan McKinnon wrote:
Masking already accomplishes everything you propose, which is to
communicate there is something wrong with this package and it is in
danger of leaving the tree. To get it out of this state, you need to
take action.
I disagree strongly that this is what masking
Markos Chandras wrote:
You keep complaining about everything
I keep complaining about things that I think can be improved, while
I don't generally praise things that I think are already good enough.
There are so many problems to fix that I basically feel that time is
better spent on problems
Markos Chandras wrote:
A per-ebuild bug metric would be cool. A kind of health indicator
for individual ebuilds, alerting users when some of our installed
ebuilds go yellow, so that we have perhaps on the order of six
months before the package goes red, at which point it would be
fine
Ulrich Mueller wrote:
Should we make it a global flag?
Sure.
What description is better:
inotify - Enable inotify filesystem monitoring support
inotify - Enable inotify file change notification support
The former is more correct, because inotify provides notifications
for more than
Samuli Suominen wrote:
Samuli Suominen wrote:
it should always be enabled with 'kernel_linux' and let the
application itself do a runtime check if inotify is available or not
I think it's great if you are working on such patches for upstreams!
no, i'm talking from experience -- every
Samuli Suominen wrote:
i'm referring to the mistakes done by maintainers by adding
unnecessarily the flag
That was not at all clear, but that's great! Then you could fix those
ebuilds.
Yes, I could, or I could just let other maintainers know about it, like
on the ML, wait... that's what I
Carlos Silva wrote:
If one wants to create a key himself, it's also possible to use this
key, he just has to name it signing_key.priv and siging_key.x509 and
put it under /usr/src/linux.
Do you know if this is a sane default?
Where do most users of signed modules store keys so far?
//Peter
Carlos Silva wrote:
If one wants to create a key himself, it's also possible to use this
key, he just has to name it signing_key.priv and siging_key.x509 and
put it under /usr/src/linux.
Do you know if this is a sane default?
Where do most users of signed modules store keys so
Andreas K. Huettel wrote:
Starting as a developer or aspiring to become one with that
attitude is not acceptable.
That doesn't make sense to me.
If the reason is good, surely it does not matter who is doing the breaking?
//Peter
pgpvkacjjiVYz.pgp
Description: PGP signature
Markos Chandras wrote:
it just feels strange
I hear they call it getting stuff done..
good thing you are not a dev then.
Thanks for the heads up in case you ever want to become one
I explain to you what happened and you, a recruiter, proceed to
threaten me in case I want to become a
Markos Chandras wrote:
I explain to you what happened
getting stuff done is not an answer. I still don't understand why
stable keywords had to be added directly. Do you understand why Mike
did that or just playing smart here?
To me it's obvious that he did it because it made something
Markos Chandras wrote:
getting stuff done is not an answer.
it made something easier for him
I asked why he did it, and you keep telling me because he had to.
I'm guessing that it didn't have much to do with Gentoo. Maybe he'll
fill in.
I am reviewing commits from time to time
Markos Chandras wrote:
it just feels strange
I hear they call it getting stuff done..
//Peter
Alexander Berntsen wrote:
I would like to announce you a new try to 'revive' the Bugday
event.
I don't have anything to add. I just wanted to express my support.
Yeah! Me too! :)
//Peter
Ryan Hill wrote:
I think I see a lot of our upstream bug reports being closed as
invalid/unsupported. I think that if upstreams wanted to use
jemalloc they would just do so. If they don't then obviously
what they have is working fine for them.
It can make sense to try further discussion,
Pavlos Ratis wrote:
Unfortunately I didn't have much time to 'refresh' the website. As
Theo said, he gave me the code of the site but I think it would be
great to have something new. If anyone wants to join, ping me on irc.
We could create a new repo at our Github and start developing.
Don't
Tom Wijsman wrote:
We could create a new repo at our Github and start developing.
Don't start developing, plz work on bugs instead.
Then who will develop useful tools to handle bugs more efficiently?
Don't get me wrong: I am not hating on useful tools!
I am saying that working on
Tom Wijsman wrote:
I am saying that working on tools that help you work on open bugs is
not orthogonal to fixing open bugs, it helps you fix them efficiently.
Sure, but on the bugday itself it sounds on the name like the idea is
to work on bugs with currently available tools, rather than work
Duncan wrote:
Is it possible to tell git to only clone/pull specific files in a repo?
No.
//Peter
Diego Elio Pettenò wrote:
The policy is also because any ebuild relying on a network service
to work cannot be assured to work at any point in time
While noble, I think it is a bit naïve. Reality is that many if not
most ebuilds *anyway* rely on temporal things - such as a current
enough
Greg KH wrote:
If there really are firmware blobs that are only available via git and
which cannot be redistributed we might consider whether it makes sense
to not support them entirely, or to force them to be masked.
Did anyone actually consider the fact that there should not be
Leho Kraav wrote:
I'm taking a look at etherpad-lite ebuild at
https://bugs.gentoo.org/show_bug.cgi?id=328897
It's a pretty big of a mess, but as I'm searching around, I can't really
find any guidelines on how nodejs / npm stuff is supposed fit in with
Portage. dev-nodejs/ doesn't even
Diego Elio Pettenò wrote:
sys-firmware/iwl3945-ucode
I want this installed on my system.
sys-firmware/iwl4965-ucode
But not this.
could we just remove them
Please don't. I think it would suck to lose the higher resolution.
On the plus side it seems that these particular packages would
Diego Elio Pettenò wrote:
Please don't. I think it would suck to lose the higher resolution.
Use savedconfig
linux-firmware is okey but not great. The high resolution is there,
which was my main concern, but it's not so easy to know how to create
a savedconfig without installing the package.
Diego Elio Pettenò wrote:
So because we did things badly in the past, that is an excuse to
do things badly in the future? :)
No. I still argue that this is NOT doing things badly.
Masking a package will NOT cause it to get unmerged by default.
Hm, can you expand on by default ?
When will
Diego Elio Pettenò wrote:
Ah, I always thought of overlays as places where apps tend to reside,
but of course you could have glibc in there for all we know... Good
point...
Welcome to the life of your average Gentoo ebuild maintainer.
Stop complaining (and with foul language! come on,
Diego Elio Pettenò wrote:
Stop complaining (and with foul language! come on, you sound like
an idiot, which seems unneccessary) and let's think about solutions.
Your laziness makes you sound like an idiot too, thank you very much.
Send me constructive criticism in an email and I'll of
Diego Elio Pettenò wrote:
People who don't need the firmware can deal with disabling it themselves.
I don't like the binary distribution argument of include everything
to cover as many possible use cases as possible in one go.
I very much like the high resolution of Gentoo packages. I'd hate to
Diego Elio Pettenò wrote:
I don't like the binary distribution argument of include everything
to cover as many possible use cases as possible in one go.
I very much like the high resolution of Gentoo packages. I'd hate to
enter a slippery slope toward lower resolution.
Are you really
Agostino Sarubbo wrote:
I'm using ssh -A to forward the key and I'm interested to find a
way to do it for the gpg key.
I found an how-to that uses socat ( http://superuser.com/questions/161973/how-
can-i-forward-a-gpg-key-via-ssh-agent ) but does not work as expected.
Did you debug?
Rather
Michael Weber wrote:
Rather than creating a TCP socket I would look into using the ssh -W
option.
gpg agent works with unix domain sockets.
I know. It would look something like socat + ssh -W socat
//Peter
Maxim Kammerer wrote:
* These packages depend on libusb:
One stands out:
app-crypt/ccid-1.4.8 (usb ? virtual/libusb:1)
app-crypt/gnupg-2.0.19 (usb ? virtual/libusb:0)
dev-libs/openobex-1.5 (usb ? virtual/libusb:0)
media-libs/libmtp-1.1.5 (virtual/libusb:1)
net-libs/libpcap-1.3.0-r1
Diego Elio Pettenò wrote:
Can you try swapping the two in the virtual?
Or not.
I guess that you assumed that I suggested to test this in-tree, so
I guess I should clarify that I would expect it to be tested in
PORTDIR_OVERLAY.
If my guess is correct then you are really way too eager to
Diego Elio Pettenò wrote:
it's because of what Maxim already said: it's not an LTR/RTL issue.
Do you have an idea about what the issue is?
//Peter
Zac Medico wrote:
My guess is that there were one or more ebuilds that inappropriately
specified dev-libs/libusb:0 instead of virtual/libusb:0, and they have
since been fixed.
I believe they were all changed some months ago, but it's of course still
possible if either the snapshot was old or
Alexis - thanks a lot for the awesome response!
Alexis Ballier wrote:
'those who are right'
(Just a note that I am in no way invested in libav/ffmpeg, I merely
speak from experience with another fork.)
However, as I said, maybe with an incorrect tone, I do not think
libav ignoring what
Luca Barbato wrote:
May I point you that ~10 people were the majority of what was FFmpeg,
thus 10 people were enough to demote democratically the so called Leader
and that guy got the name from Fabrice as his personal decision?
There was probably a reason for Fabrice to do that, and majority
Luca Barbato wrote:
Users will never be satisfied. But I guess you agree that API
compatibility will certainly avoid extra problems for users.
It is not related to users,
I was trying to come back on topic. :)
is related to me being called as swine a traitor and having death
threats.
Tomáš Chvátal wrote:
Having nice mailinglist where users can contribute simple patches
would be briliant thing to use :-)
That's still a waste of time compared to gerrit. You should look at
it if you don't know it already.
//Peter
hasufell wrote:
there should only be two reasons to have ebuilds in a seperate
overlay: they depend on dropped packages or they are unsupportable
(e.g. because they are in early alpha stage or broken in some ways).
Keep in mind that there may be lots of other cases which you have not
and can
Alec Warner wrote:
Having nice mailinglist where users can contribute simple patches
would be briliant thing to use :-)
That's still a waste of time compared to gerrit. You should look at
it if you don't know it already.
I'll take patchwork over gerrit, honestly ;)
Did you use
301 - 400 of 528 matches
Mail list logo
