Dnia 2014-01-18, o godz. 10:08:13
hero...@gentoo.org napisał(a):
Michał Górny mgo...@gentoo.org writes:
However, it may be actually beneficial to provide other durations, like
weekly deltas. In my tests, the daily updates for this week summed up
to almost 50M while the weekly was barely
Dnia 2014-01-18, o godz. 02:28:52
Thomas D. whi...@whissi.de napisał(a):
Hi,
Michał Górny wrote:
Now, does anyone have an old portage-YYZZ.tar.{bz2,xz} snapshot? I
need the official one from our mirrors, preferably 3-4 months old.
On 18/01/2014 09:49, Alec Warner wrote:
On Fri, Jan 17, 2014 at 11:10 PM, Alan McKinnon alan.mckin...@gmail.com
mailto:alan.mckin...@gmail.com wrote:
On 18/01/2014 09:04, Patrick Lauer wrote:
which could link to the
infra page would be good here perhaps, so when an outage
Robin H. Johnson robb...@gentoo.org wrote:
FYI: The following repos contained dangling commits/tags/blobs
[...] you are encouraged to push again [...]
user/mv.git (+blobs)
I cannot imagine that the suggested git push removed orphaned blobs:
AFAIK it is not possible to execute commands like
On Sat, Jan 18, 2014 at 12:56:36AM +0100, Tom Wijsman wrote:
On Fri, 17 Jan 2014 18:28:41 +
Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:
On Fri, 17 Jan 2014 17:47:58 +0100
Tom Wijsman tom...@gentoo.org wrote:
Maybe we can let the package managers only perceive it as
On 18.01.2014 06:23, Kent Fredric wrote:
On 18 January 2014 18:02, Robin H. Johnson robb...@gentoo.org
mailto:robb...@gentoo.org wrote:
- More people need to use the infra-status page to learn about the state
of Gentoo services.
A service middle layer like fastly or
On 01/18/2014 12:59 PM, Alex Legler wrote:
On 18.01.2014 06:23, Kent Fredric wrote:
On 18 January 2014 18:02, Robin H. Johnson robb...@gentoo.org
mailto:robb...@gentoo.org wrote:
- More people need to use the infra-status page to learn about the state
of Gentoo services.
A
On 18/01/14 05:57 AM, Martin Vaeth wrote:
Robin H. Johnson robb...@gentoo.org wrote:
FYI: The following repos contained dangling commits/tags/blobs
[...] you are encouraged to push again [...]
user/mv.git (+blobs)
I cannot imagine that the suggested git push removed orphaned blobs:
AFAIK
On Sat, 18 Jan 2014 05:02:56 +
Robin H. Johnson robb...@gentoo.org wrote:
FYI: The following repos appeared to be empty:
...
dev/tomwij.git
...
Not empty, has app-office/taskjuggler and dev-java/jetty-*; did a check
against my local clone, and `git ls-tree --full-tree -r HEAD | sha1sum`
Was looking to existing gedit bug reports and I found:
https://bugs.gentoo.org/show_bug.cgi?id=257004
That is only one more example of a really old bug report still opened
and waiting for a GLSA. Was wondering what really causes this long
delays, can't GLSA be done automatically? Would a GLSA
On 18.01.2014 16:34, Pacho Ramos wrote:
Was looking to existing gedit bug reports and I found:
https://bugs.gentoo.org/show_bug.cgi?id=257004
That is only one more example of a really old bug report still opened
and waiting for a GLSA. Was wondering what really causes this long
delays,
Oops, didn't send to @-dev.
On Jan 18, 2014 10:58 AM, creff...@gentoo.org wrote:
Short version since I'm on my phone: we're working on reducing the number of
fields, can't really auto generate, current blocker is getting two additional
devs (beyond the author) to sign off on the GLSA. We
El sáb, 18-01-2014 a las 17:02 +0100, Alex Legler escribió:
On 18.01.2014 16:34, Pacho Ramos wrote:
Was looking to existing gedit bug reports and I found:
https://bugs.gentoo.org/show_bug.cgi?id=257004
That is only one more example of a really old bug report still opened
and waiting
On Sat, Jan 18, 2014 at 5:30 PM, Pacho Ramos pa...@gentoo.org wrote:
What I want to achieve is to try to get this problem solved, I don't
think has any sense to have pending GLSA bugs waiting for ages (yes,
ages), I see this for really a lot of packages, the pointed one was only
one example,
El sáb, 18-01-2014 a las 17:30 +0100, Pacho Ramos escribió:
[..]
The issue is still present even if we don't talk about it and keep
simply ignoring all bug reports assigned to security and accumulating
for years.
[Bah, the touchpad]
I was referring the, until know, I was simply ignoring that
On 18.01.2014 17:30, Pacho Ramos wrote:
[…]
What I want to achieve is to try to get this problem solved, I don't
think has any sense to have pending GLSA bugs waiting for ages (yes,
ages), I see this for really a lot of packages, the pointed one was only
one example, but there are many more
El sáb, 18-01-2014 a las 18:26 +0100, Alex Legler escribió:
On 18.01.2014 17:30, Pacho Ramos wrote:
[…]
What I want to achieve is to try to get this problem solved, I don't
think has any sense to have pending GLSA bugs waiting for ages (yes,
ages), I see this for really a lot of
On 18.01.2014 18:38, Pacho Ramos wrote:
[…]
Then, how are you finally going to fix this?
Thank you for finally showing interest in anything we do. Here is how we
are 'finally' going to fix this.
Only for knowing, I still
was seeing some delays and, then, I though situation was not
El sáb, 18-01-2014 a las 19:19 +0100, Alex Legler escribió:
[...]
So you observed correctly there's still plenty of delays. There are
three parts to an advisory that take time:
- Drafting: Collecting information, linking references, getting package
versions done right (slots are a huge pain
Alex Legler posted on Sat, 18 Jan 2014 13:59:56 +0100 as excerpted:
Ironically, the only site that was already using the Tyrian theme (i.e.
the one with a top-right menu) was infra-status.
Now with overlays using the new theme too, I've updated the list.
(NB: During the outage, I added a
On Jan 18, 2014 1:35 PM, Pacho Ramos pa...@gentoo.org wrote:
El sáb, 18-01-2014 a las 19:19 +0100, Alex Legler escribió:
[...]
So you observed correctly there's still plenty of delays. There are
three parts to an advisory that take time:
- Drafting: Collecting information, linking
El sáb, 18-01-2014 a las 19:35 +0100, Pacho Ramos escribió:
[...]
They helped for sure :) and I appreciate them, I simply thought nothing
was being worked out as I explained in previous mail (I was still saying
long delays)
- seeing (not sure why I type so wrongly :S)
El sáb, 18-01-2014 a las 13:57 -0500, Chris Reffett escribió:
[...]
We prefer that the maintainers do the drop in case there's some
dependency situation we're not aware of, but we will drop if
maintainers are unresponsive.
[...]
By all means, maintainer should be the one to call for the
Dirkjan Ochtman posted on Sat, 18 Jan 2014 17:33:36 +0100 as excerpted:
On Sat, Jan 18, 2014 at 5:30 PM, Pacho Ramos pa...@gentoo.org wrote:
What I want to achieve is to try to get this problem solved, I don't
think has any sense to have pending GLSA bugs waiting for ages (yes,
ages), I see
# Dion Moult mo...@gentoo.org (19 Jan 2014)
# Mask for removal in 30 days. Flyte service discontinued so package is useless.
# (bug #495138)
app-misc/flyte-download-manager
# Dion Moult mo...@gentoo.org (19 Jan 2014)
# Mask for removal in 30 days. usleep is actually provided part of
# app-admin/killproc (bug #467212)
sys-apps/usleep
# Dion Moult mo...@gentoo.org (19 Jan 2014)
# Mask for removal in 30 days. Packages now depend on dev-lang/mono directly and
# not on virtual/monodoc (bug #471180)
virtual/monodoc
All,
I would like to bring back for discussion an old patch to glep 48 [1]
which was suggested by Jorge [2].
That patch evolved into this one [3], and in the council meeting back
then [4], parts of it made their way into glep 48, but the rest seemed to
be forgotten.
Attached you will find an
All,
I put this on the wrong list, so please disregard this here and reply
on -project instead; I forwarded this msg over there.
Thanks,
William
signature.asc
Description: Digital signature
On Sat, Jan 18, 2014 at 11:02:24PM -0600, William Hubbs wrote:
+* In case a particular developer persistently causes breakage, the QA lead
may request commit rights of that developer to be suspended by the Infra
team. Comrel should then proceed to evaluate the situation, by finding a
On Sat, 18 Jan 2014 08:43:12 -0800
W. Trevor King wk...@tremily.us wrote:
On Sat, Jan 18, 2014 at 04:02:02PM +0100, Tom Wijsman wrote:
I think the idea is that you shouldn't need to refer to an external
resource like the mailing list to understand the idea behind the
patch,
Either someone
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 18/01/14 22:52, Robin H. Johnson wrote:
You mean like... https://github.com/gentoo/portage
This didn't exist back when. I should have done more research though.
Thanks.
- --
Alexander
alexan...@plaimi.net
http://plaimi.net/~alexander
---
man/emerge.1| 9 +
pym/_emerge/depgraph.py | 5 +++--
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/man/emerge.1 b/man/emerge.1
index e23d1b4..52f8ed7 100644
--- a/man/emerge.1
+++ b/man/emerge.1
@@ -331,10 +331,11 @@ Write required unmask changes to the
Rename --autounmask-write to --autounmask. Please note that removing the
option does not mean that the variable used for keeping track of
autounmask writing is not removed from depgraph.py.
---
man/emerge.1| 19 +++
pym/_emerge/depgraph.py | 4 ++--
On Sat, 18 Jan 2014 15:24:59 -0800
W. Trevor King wk...@tremily.us wrote:
If it doesn't need to get updated, then it probably already started
out explaining the consensus ;).
That is a guess, you can look this up in past patches.
You spend time if you want to spend time and add whoever you
v2: Reformat, add a function to return an appropriate read-only checker
for the operating system, so that this can be extended to other OSes.
v3: minor formatting tweaks from bernalex, including use os.path.join()
instead of string concatenation
---
pym/portage/dbapi/vartree.py | 32
On Sat, Jan 18, 2014 at 7:21 PM, Alexander Berntsen
alexan...@plaimi.net wrote:
Rename --autounmask-write to --autounmask. Please note that removing the
option does not mean that the variable used for keeping track of
autounmask writing is not removed from depgraph.py.
Ok, so how do I tell
The current fetch() function is quite long, which makes it hard to
know what I can change without adverse side effects. By pulling this
logic out of the main function, we get clearer logic in fetch() and
more explicit input for the config extraction.
---
pym/portage/package/ebuild/fetch.py | 50
I felt like I should actually make a useful contribution to balance
the less useful commit-message discussion ;). Browsing through the
open Portage bugs, #175612 looked interesting. After I looked at
pym/portage/package/ebuild/fetch.py, I decided to take a step back and
just try and refactor
The current fetch() function is quite long, which makes it hard to
know what I can change without adverse side effects. By pulling this
logic out of the main function, we get clearer logic in fetch() and
more explicit input for the config extraction.
This block was especially complicated, so I
On Sun, Jan 19, 2014 at 02:33:06AM +0100, Tom Wijsman wrote:
On Sat, 18 Jan 2014 15:24:59 -0800
W. Trevor King wk...@tremily.us wrote:
If it doesn't need to get updated, then it probably already
started out explaining the consensus ;).
That is a guess, you can look this up in past
41 matches
Mail list logo
