Re: [gentoo-dev] bug queue size over time

[Paweł Hajdan , Jr .]

On 19/03/2018 21:33, Alec Warner wrote:
> I'd avoid the REST API here. If you want this data; I'd consider filing a
> bug. Infra can do stuff like run nightly reports for this information and
> hang them off of endpoints you can access.
> This works well for public bugs; and not well for private ones.

Luckily, I'm not that concerned with private bugs.

Would it only collect data going forward, or does this method also
support historical backfill?

>> I've done something like this before with Perl bugs[1], but again, very
>> painful, slow and time consuming.

Ah, that looks like lots of stats.

I'm mostly interested in how many bugs were open for given assignee for
each point in time.

If you still have scripts that generated these reports and they could be
useful to compute the above, I could be interested.

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] bug queue size over time

[Matthew Thode]

On 18-03-19 19:33:11, Paweł Hajdan, Jr. wrote:
> Is it possible to get graphs of bugs.g.o bug queue size for certain
> query (e.g. by assignee) over time?
> 

I suspect it's up and to the right.

-- 
Matthew Thode (prometheanfire)


signature.asc
Description: PGP signature

Re: [gentoo-dev] bug queue size over time

[Alec Warner]

On Tue, Mar 20, 2018 at 12:24 AM, Kent Fredric  wrote:

> On Mon, 19 Mar 2018 19:33:11 -0700
> "Paweł Hajdan, Jr."  wrote:
>
> > Is it possible to get graphs of bugs.g.o bug queue size for certain
> > query (e.g. by assignee) over time?
> >
> > Best,
> > Paweł
> >
>
> The *data* is there to do it, but its a bit of a pain, you have to
> extract all the individual "changed" events and then use that to reason
> about each individual bugs state at a given time, and use *that* to
> deduce how many open bugs there *were* at a historical moment.
>
> And that's a lot of painful queries for the REST API.
>

I'd avoid the REST API here. If you want this data; I'd consider filing a
bug. Infra can do stuff like run nightly reports for this information and
hang them off of endpoints you can access.
This works well for public bugs; and not well for private ones.


>
> I've done something like this before with Perl bugs[1], but again, very
> painful, slow and time consuming.
>
> This sort of thing would be *much* easier if we could have direct bulk
> access to the underlying MYSQL store, but that's a tricky thing to do
> because:
>
> 1. Its MySQL
> 2. Some bugs have visibility restrictions that have to be factored for
>

In this way, you can download the (likely hundreds of megs) of JSON or
whatever, and do the sorting / filtering / timeseries work on the client
end?

Its not great I suspect, but it saves everyone hamming the database.

-A

>
> 
>
> Note: these pages are very browser taxing:
>
> 1: https://docs.google.com/spreadsheets/d/1mm8iYE77SRh-
> q2jOfKNSWHUetswEABJawp-94UyTHio/edit?usp=sharing
>
>
>
>
>
>

Re: [gentoo-dev] bug queue size over time

[Kent Fredric]

On Mon, 19 Mar 2018 19:33:11 -0700
"Paweł Hajdan, Jr."  wrote:

> Is it possible to get graphs of bugs.g.o bug queue size for certain
> query (e.g. by assignee) over time?
> 
> Best,
> Paweł
> 

The *data* is there to do it, but its a bit of a pain, you have to
extract all the individual "changed" events and then use that to reason
about each individual bugs state at a given time, and use *that* to
deduce how many open bugs there *were* at a historical moment.

And that's a lot of painful queries for the REST API.

I've done something like this before with Perl bugs[1], but again, very
painful, slow and time consuming.

This sort of thing would be *much* easier if we could have direct bulk
access to the underlying MYSQL store, but that's a tricky thing to do because:

1. Its MySQL
2. Some bugs have visibility restrictions that have to be factored for



Note: these pages are very browser taxing:

1: 
https://docs.google.com/spreadsheets/d/1mm8iYE77SRh-q2jOfKNSWHUetswEABJawp-94UyTHio/edit?usp=sharing
  






pgpZQIRQwdgnK.pgp
Description: OpenPGP digital signature

[gentoo-portage-dev] unsuscribe

[Pablo De Napoli]

[gentoo-dev] bug queue size over time

[Paweł Hajdan , Jr .]

Is it possible to get graphs of bugs.g.o bug queue size for certain
query (e.g. by assignee) over time?

Best,
Paweł



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] FYI: Mastersync is down

[Alec Warner]

This is just an FYI: https://infra-status.gentoo.org/

Hoping to have this fixed in a couple of days. In the meantime you may see
missing snapshots (for emerge webrsync) and no rsync propagation.

-A

Re: [gentoo-dev] things becoming better and better

[Aaron Bauman]

On Mon, Mar 19, 2018 at 07:48:01PM +0100, Toralf Förster wrote:
> honestly.
> 
> 
> When I started with my tinderbox 2 or 3 years ago I had often a fair
> amount of manual work to made to get an image up and running - moslty
> tweaking USE flags to get blockers being solved. This yielded into a
> growing list of fixed USE flags settings for certain packages.
> 
> But over the time this list became small and smaller and eventually this
> month I kicked off the last few lines (famous last words?).
> 
> Said that Gentoo has IMO a lot of success stories to tell too (beside
> the usual grumblings and annoyances) - and the quality of the Gentoo
> tree is IMO an example of that.
> 
> 
> /me was just in the mood for a statement like this
> 
> -- 
> Toralf
> PGP 23217DA7 9B888F45
> 
>

Toralf, first and foremost, thank you!  You efforts have and continue to
be successful for Gentoo.  I would also echo that the tree is much
healthier due to your efforts.  Once again, thank you.

-Aaron


signature.asc
Description: Digital signature

Re: [gentoo-portage-dev] [PATCH 0/3] INSTALL_MASK refurbishing resubmit

[Zac Medico]

On 03/15/2018 12:22 PM, Michał Górny wrote:
> Hi,
> 
> Here are three of four INSTALL_MASK updates I've sent long time ago
> which were not really reviewed. The fourth patch added support
> for repo-defined install-mask.conf and I'll do that separately.
> 
> Those patches focus on smaller changes. What they change, in order:
> 
> 1. Removes explicit file removal code for FEATURES=no*. Instead, those
>values are converted into additional INSTALL_MASK entries
>and handled directly via INSTALL_MASK processing.
> 
> 2. Rework INSTALL_MASK to filter files while installing instead of
>pre-stripping them. In other words, before: INSTALL_MASK removes
>files from ${D} before merge. After: ${D} contains all the files,
>Portage just skip INSTALL_MASK-ed stuff, verbosely indicating that.
> 
> 3. Adds support for exclusions in INSTALL_MASK. In other words, you
>can do stuff like:
> 
>  INSTALL_MASK="/usr/share/locale -/usr/share/locale/en_US"
> 
> I have been using this via user patches since the last submission.
> Guessing by 'git log', this means almost 2 years now.
> 
> --
> Best regards,
> Michał Górny
> 
> Michał Górny (3):
>   portage.package.ebuild.config: Move FEATURES=no* handling there
>   portage.dbapi.vartree: Move INSTALL_MASK handling into merging
>   portage.dbapi.vartree: Support exclusions in INSTALL_MASK
> 
>  bin/misc-functions.sh|  30 --
>  pym/portage/dbapi/vartree.py | 104 
> ++-
>  pym/portage/package/ebuild/config.py |  11 
>  3 files changed, 77 insertions(+), 68 deletions(-)
> 

As mentioned in #gentoo-portage today, the rationale for including the
INSTALL_MASKed files in CONTENTS is to that we can detect collisions
that would have occurred had people not been using INSTALL_MASK.

Since people can use INSTALL_MASK to intentionally prevent collisions,
in cases where COLLISION_IGNORE is not appropriate (this is common
practice at my workplace), we'll need a new FEATURES setting to trigger
the new behavior where INSTALL_MASKed files still trigger file collisions.
-- 
Thanks,
Zac



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Packages up for grabs

[Andrey Utkin]

On Tue, Mar 13, 2018 at 03:11:45PM +0100, Lars Wendler wrote:
> On Tue, 13 Mar 2018 12:58:10 +0100 Pacho Ramos wrote:
> 
> >net-wireless/hostapd
> 
> In case nobody else wants to take it I can do. But I'm a mere user of
> the package and don't know anything about its internals. So it would be
> very basic/low maintenance from me.

I can't let this get dropped from the tree :)
I'm mere user, too, let's comaintain. Please put us both to
metadata.xml (in whichever order you prefer).


signature.asc
Description: Digital signature

Re: [gentoo-dev] things becoming better and better

[Benda Xu]

Hi Toralf,

Toralf Förster  writes:

> When I started with my tinderbox 2 or 3 years ago I had often a fair
> amount of manual work to made to get an image up and running - moslty
> tweaking USE flags to get blockers being solved. This yielded into a
> growing list of fixed USE flags settings for certain packages.
>
> But over the time this list became small and smaller and eventually
> this month I kicked off the last few lines (famous last words?).
>
> Said that Gentoo has IMO a lot of success stories to tell too (beside
> the usual grumblings and annoyances) - and the quality of the Gentoo
> tree is IMO an example of that.

Thanks a ton for the tinkerbox and for the early bug reports!

This is the crucial way to keep our tree healthy.

Cheers,
Benda


signature.asc
Description: PGP signature

Re: [gentoo-dev] [PATCH] cmake-utils.eclass: Make the new ASM-ATT rules actually work

[James Le Cuirot]

On Mon, 19 Mar 2018 15:16:47 -0700
Matt Turner  wrote:

> Thanks for looking into this!
> 
> I'm not sure I understand the -nostdlib portion. It's something about
> working around a side-effect of -x assembler?

It's not related to that option. I think it's because this is normally
built with "as" and "ld" and by using "gcc" instead, it tries to link
libc and friends, which otherwise wouldn't happen. It'll fail if you
take it away and you'll find the error if you dig through tons of
strace. Strangely you don't see the linking command in the regular
build output.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpuEuFO3eBUW.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH] cmake-utils.eclass: Make the new ASM-ATT rules actually work

[Matt Turner]

Thanks for looking into this!

I'm not sure I understand the -nostdlib portion. It's something about
working around a side-effect of -x assembler?

[gentoo-dev] [PATCH] cmake-utils.eclass: Make the new ASM-ATT rules actually work

[James Le Cuirot]

The previous attempt actually broke ASM in media-libs/vulkan-loader
entirely so that it fell back to C code. After much experimentation
and combing through strace output, I found that -x assembler is needed
to handle non-standard file extentions and linking is done as a
separate step. CMAKE_ASM-ATT_LINK_FLAGS therefore needs to be defined
with -nostdlib to avoid errors about undefined main symbols.

Closes: https://bugs.gentoo.org/625844
---
One user has confirmed that this patch works for vulkan-loader and I'd
like a dev or two to also confirm this before I merge.

 eclass/cmake-utils.eclass | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
index f8853be502a1..f6952ec09efd 100644
--- a/eclass/cmake-utils.eclass
+++ b/eclass/cmake-utils.eclass
@@ -520,7 +520,8 @@ cmake-utils_src_configure() {
fi
cat > "${build_rules}" <<- _EOF_ || die
SET (CMAKE_ASM_COMPILE_OBJECT "  
${includes} ${CPPFLAGS}  -o  -c " CACHE STRING "ASM 
compile command" FORCE)
-   SET (CMAKE_ASM-ATT_COMPILE_OBJECT " 
 ${includes} ${CPPFLAGS}  -o  -c " CACHE STRING 
"ASM compile command" FORCE)
+   SET (CMAKE_ASM-ATT_COMPILE_OBJECT " 
 ${includes} ${CPPFLAGS}  -o  -c -x assembler " 
CACHE STRING "ASM-ATT compile command" FORCE)
+   SET (CMAKE_ASM-ATT_LINK_FLAGS "-nostdlib" CACHE STRING "ASM-ATT 
link flags" FORCE)
SET (CMAKE_C_COMPILE_OBJECT "  
${includes} ${CPPFLAGS}  -o  -c " CACHE STRING "C 
compile command" FORCE)
SET (CMAKE_CXX_COMPILE_OBJECT "  
${includes} ${CPPFLAGS}  -o  -c " CACHE STRING "C++ 
compile command" FORCE)
SET (CMAKE_Fortran_COMPILE_OBJECT " 
 ${includes} ${FCFLAGS}  -o  -c " CACHE STRING 
"Fortran compile command" FORCE)
-- 
2.16.1

Re: [gentoo-dev] things becoming better and better

[M. J. Everitt]

On 19/03/18 18:48, Toralf Förster wrote:
> honestly.
>
>
> When I started with my tinderbox 2 or 3 years ago I had often a fair
> amount of manual work to made to get an image up and running - moslty
> tweaking USE flags to get blockers being solved. This yielded into a
> growing list of fixed USE flags settings for certain packages.
>
> But over the time this list became small and smaller and eventually this
> month I kicked off the last few lines (famous last words?).
>
> Said that Gentoo has IMO a lot of success stories to tell too (beside
> the usual grumblings and annoyances) - and the quality of the Gentoo
> tree is IMO an example of that.
>
>
> /me was just in the mood for a statement like this
>
I think I speak for many readers of this list, in echo'ing a big
thank-you for your efforts on the Tinderbox project. Gentoo has been
slow to move to more automated testing methods, and this is a huge leap
forward in this regard. Hopefully, moving forward there will be less
human effort required to extend and maintain the tree of packages on
which we depend, and together with QA, huge strides forward are being
made to achieve this end.

It is quite useful to have a consistent means to test packages, and to
this end, hopefully we can eliminate some of the randomness that having
a very flexible build system creates!

Onwards and upwards ...



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] things becoming better and better

[Toralf Förster]

honestly.


When I started with my tinderbox 2 or 3 years ago I had often a fair
amount of manual work to made to get an image up and running - moslty
tweaking USE flags to get blockers being solved. This yielded into a
growing list of fixed USE flags settings for certain packages.

But over the time this list became small and smaller and eventually this
month I kicked off the last few lines (famous last words?).

Said that Gentoo has IMO a lot of success stories to tell too (beside
the usual grumblings and annoyances) - and the quality of the Gentoo
tree is IMO an example of that.


/me was just in the mood for a statement like this

-- 
Toralf
PGP 23217DA7 9B888F45




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-portage-dev] [PATCH 0/3] INSTALL_MASK refurbishing resubmit

[Joakim Tjernlund]

On Sun, 2018-03-18 at 10:03 +0100, Michał Górny wrote:
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe.
> 
> 
> W dniu czw, 15.03.2018 o godzinie 22∶10 -0700, użytkownik Zac Medico
> napisał:
> >  A binary package should
> > use the value of INSTALL_MASK that existed at build time.
> > 
> 
> Wait a minute! This doesn't make any sense. The whole point of having
> separate PKG_INSTALL_MASK and INSTALL_MASK is to be able to strip stuff
> from more complete binary packages, not to force original restrictions
> forever.

These discussions also mentions PKG_INSTALL_MASK while the actual patches
only mention INSTALL_MASK. I am getting somewhat confused, does
the patches support PKG_INSTALL_MASK too or do you only intend to support
this new exclusion syntax in INSTALL_MASK?

Jocke