[gentoo-dev] unprefixed eqawarn
Hello all,
the truth is that I should have separated this email into two threads. However
they have a
relation, so let's discuss them in one place.
The first:
While is not mandatory begin an eqawarn with "QA Notice" and thus there are no
rules
about that I think it helps while grepping on build logs.
All of us agree that is should be fixed in the eqawarn function, but it won't
happen soon.
So, if you are interested to get bug reports (at least from me) about
unprefixed eqawarn,
please add the usual "QA Notice:" prefix as we did in
https://bugs.gentoo.org/728046[1]
If you think that add "QA Notice:" will break existing scripts or so, please
let us know.
I'm adding as attachment the list of eqawarn that miss the 'QA Notice' prefix.
The second:
By filing bugs for eqawarn/qa notice, I have been pointed out, for some class
of issues,
that a bugreport is not needed.
At this point, since bugs can be filed by everyone, I think is better introduce
something
that make clear that we do not expect a bugreport about a particular issue.
An example is here:
eqawarn "QA (Dev) Notice: "
eqawarn ".."
eqawarn ".."
eqawarn "Please remember that QA (Dev) Notice do not deserve a bugreport"
In other words a "QA (Dev) Notice:" is supposed to be one or more of the
following:
- something useful for maintainer at the bump time
- something that is not worth for a bugreport
- something that is not worth for an immediate fix
- something that will disappear soon with a new version of a package
Two side notes:
1)
I have tried to introduce that on irc in #gentoo-qa to get a feedback about
that, but I have
not received a response, so this should be the proper place.
So this is NOT to point the finger to people that did not answer, but it's just
to say that I'm
not expecting something like: "why you didn't discuss this with us first" from
qa ;)
2)
@ionen already pointed out to me that configure.in qa notice in
autotools.eclass no dot
deserve a qa notice.
What do you think?
Agostino
[1] https://bugs.gentoo.org/728046
autotools.eclass:
eqawarn "This package has a configure.in file which has long been deprecated.
Please"
eqawarn "Running '${1}' in ${EBUILD_PHASE_FUNC} phase"
chromium-2.eclass:
eqawarn "L10N warning: no .pak file for ${lang} (${lang}.pak not found)"
eqawarn "L10N warning: no ${lang} in LANGS"
distutils-r1.eclass:
eqawarn "Non-PEP517 builds are deprecated for ebuilds using plain distutils."
eqawarn "${build_backend} backend is deprecated. Please see:"
eqawarn "Python extension modules (*$(get_modname)) found installed. Please
set:"
ecm.eclass:
eqawarn "Build system was modified by ECM_TEST=forceoptional-recursive."
flag-o-matic.eclass:
eqawarn "Appending an empty argument to LIBS is invalid! Skipping."
eqawarn "Appending non-library to LIBS (${flag}); Other linker flags should be
passed via LDFLAGS"
go-module.eclass:
eqawarn "This ebuild uses EGO_SUM which is deprecated"
gstreamer-meson.eclass:
eqawarn "QA: IUSE=orc is missing while plugin supports it"
eqawarn "QA: IUSE=orc is present while plugin does not support it"
eqawarn "QA: IUSE=introspection is missing while plugin supports it"
eqawarn "QA: IUSE=introspection is present while plugin does not support it"
haskell-cabal.eclass:
eqawarn "No Setup.lhs or Setup.hs found. Either add Setup.hs to package or call
cabal-mksetup from ebuild"
java-pkg-simple.eclass:
eqawarn "Need at least JDK 9 to compile module-info.java in src_compile."
java-utils-2.eclass:
eqawarn "java-pkg_ensure-dep: ${dev_error}"
eqawarn "java-pkg_ensure-dep: ${dev_error}"
python-r1.eclass:
eqawarn "python_foreach_impl has been called directly while using distutils-r1."
python-utils-r1.eclass:
eqawarn "The directory ${fn} occludes package installed for ${EPYTHON}."
eqawarn "${l}"
eqawarn "For more information on occluded packages, please see:"
rpm.eclass:
eqawarn 'do not use ${DISTDIR} with rpm_unpack -- it is added for you'
eqawarn 'do not use full paths with rpm_unpack -- use ./ paths instead'
ruby-fakegem.eclass:
eqawarn "${CATEGORY}/${PF}: Unknown test recipe '${RUBY_FAKEGEM_RECIPE_TEST}'
specified, using 'none'"
eqawarn "Generating generic fallback gemspec *without* dependencies"
ruby-ng.eclass:
eqawarn "RUBY_PATCHES is no longer supported, use PATCHES instead"
eqawarn "Missing test dependency dev-ruby/rspec"
toolchain.eclass:
eqawarn "Snapshot release with pre-generated info pages found!"
wxwidgets.eclass:
eqawarn "This package relies on the deprecated GTK 2 slot, which will go away
soon (https://bugs.gentoo.org/618642)"
[gentoo-dev] Important note on tinderbox behavior
Dear all,
TL;DR: tinderbox will skip packages with know failures
it's a matter of fact that on bugzilla there are hundreds of bugs that
tinderbox continues to reproduce.
That results in a waste of resources and time.
What was done to improve this situation:
in the past few months I launched few tinderbox environments with the scope of
collect the known failures.
These failures, that have an open bug, have been noted on a list.
When tinderbox starts, it queries bugzilla to understand the status of the bug
and in case of open bugs it passes the package names to emerge as
--exclude $PACKAGE
That save a lot of time because emerge FOO --exclude FOO hangs immediately.
Imagine a scenario where a broken package has no DEPEND. The waste of resource
is very minimal.
Imagine another scenario where:
- the package FOO is broken
- the package BAR has 100 depend
- the package FOO is a depend of BAR
- the package FOO is at position 100 of the depend order
that results in build 99 packages for nothing.
In short the problem is not in the package itself, but when a lot of DEPEND
are involved.
This behavior, *that was already experimented in the latest few months* does
not change anything on your side.
The only con that comes in my mind is that when a version bump silently fixes
an issue and maintainer is not aware about that.
The bug still remains as open and as a consequence, the package continues to
be excluded.
For this reason, please be pay more attention to open bugs.
As a side note, bugs are obviously categorized. For example a build failure
for a package FOO on musl, will produce '--exclude FOO' only on musl.
Same thing for doc brokeness.
For this reason please expect less 'tinderbox has reproduced this issue with
version "${VERSION}" - Updating summary.' and not seeing anymore this message
is not a symptom of 'this is fixed now' ( https://bugs.gentoo.org/770889#c6 )
Failures regarding Modern C porting are excluded from this behavior. Instead
'-fpermissive' will be used to build as much as possible.
Tests failures have also no influence on that, but keep in mind that packages
with known test failure(s) are not built by default.
Thanks
Agostino
Re: [gentoo-dev] Package stabilization groups
Hello, although it might seem offtopic, but while talking about metadata.xml fileds and `pkgdev bugs` I would like to ask opinions about have a metadata.xml field that allows the maintainer to exclude the package from `pkgdev bugs` That should be useful for core packages (gcc/glibc) and for packages that can be properly tested by have an account somewhere. Thanks
[gentoo-dev] Re: [gentoo-announce] Gentoo Services Migration: Bugzilla, Forums, Wiki
On mercoledì 29 marzo 2023 08:03:59 CEST Robin H. Johnson wrote: > Hi! > > This is a notification that multiple Gentoo services (bugzilla, forums, > wiki) will be moving and temporarily offline possibly until sometime > Saturday 2023/04/01. Hi all, in order to keep CI making its work, I created a temporary repository where issues can be filed. I will cc maintainers/committers but you can monitor issues as well. Just keep in mind that CI can't search for open bugs on bugzilla (because of a down of course), so bugs that have already been reported in the past, may be reported on github too, but from my perspective is better have few duplicates rather than unnoticed bugs that may reach the end users. If you don't want to be CC'ed on bugs, please let me know. Agostino https://github.com/asarubbo/bugzilla_maintenance_2023-03-29/issues[1] [1] https://github.com/asarubbo/bugzilla_maintenance_2023-03-29/issues
Re: [gentoo-dev] Disturbing state of arch testing in Gentoo
On martedì 8 novembre 2022 14:26:18 CET Michał Górny wrote: > If the code was > public, I could try figuring it out and perhaps even fixing it. Stable requests are handled by many people. o, since your requests were ignored by all members and sam said that him, arthurzam, jsmolic are using tattoo, my guess is that you have already everything in place. Quoting the relevant part from sam's email: Agostino
Re: [gentoo-dev] Disturbing state of arch testing in Gentoo
Hi, Whatever outside the arch testing (like tinderbox) is off topic here since it is a completely different argument. To make John Helmert III happy, I just switched to tatt; so my actual workflow is tatt + nattka and there is nothing more. If there are unanswered questions about the arch testing, please let me know. Agostino
Re: [gentoo-dev] Disturbing state of arch testing in Gentoo
On domenica 6 novembre 2022 14:27:40 CET John Helmert III wrote: > As far as I can tell, there's ONE person relying completely on a > proprietary arch testing system. > > Ago, could you comment on this? What's blocking you from open sourcing > your software? Hi, I already answered in the previous post: "I still use getatoms.py to fetch 'doable' stablereqs (it is on my todo to switch to nattka). And I have a script the **simply** does emerge over the list of the packages. There is nothing obscure in it." I'm working in arch testing since 2009. In the past I relied on scripts done by someone else and every time there was an issue I got no response. At a certain point I decided to make my own script in language I know so I can edit it when is needed. Since few years we allow self stabilization from maintainer. Do we know how and with what they test? No because it is not required. The requirement for test is that the package you are testing works as expected. https://wiki.gentoo.org/wiki/Project:AMD64_Arch_Testers#Arch_tester.27s_policy[1] Agostino [1] https://wiki.gentoo.org/wiki/Project:AMD64_Arch_Testers#Arch_tester.27s_policy
Re: [gentoo-dev] Disturbing state of arch testing in Gentoo
On domenica 6 novembre 2022 09:15:40 CET Michał Górny wrote: > On top of that, it seems that most of it still relies on proprietary > software and we have no clue how *exactly* it works, and it's really, > really hard to get a straight answer. I'm speaking for myself. I still use getatoms.py to fetch 'doable' stablereqs (it is on my todo to switch to nattka). And I have a script the *simply* does emerge over the list of the packages. There is nothing obscure in it. > So, my questions are: > > 1. Is "runtime testing required" field being respected? Obviously not > every package can be (sufficiently) tested via FEATURES=test, so we've > added that fields. However, if arch testers just ignore it and push > things stable based on pure build testing... sam already provided the right answer. In addition, when we introduced runtime_testing and package_list fields we requested support in pybugz: https://github.com/williamh/pybugz/issues/105[1] There is no trace (into the github ticket) about runtime testing field because I discussed/ requested over irc. > 2. How are kernels being tested? Given the speed with which new gentoo- > sources stablereqs are handled, I really feel like "arch testing" there > means "checking if sources install", and have little to do with working > kernels. For amd64, I boot into the new kernel to verify that at least it boots. For other 'exotic' arches, since there is a lack of hardware, the rule was to verify that at least it builds (install if we want to use the right word). If you think that build only is not appropriate, I can skip kernel stablereqs. > 3. How does the automation handle packages that aren't trivially > installable? I recall that in the past stablereqs were stalled for > months without a single comment because automation couldn't figure out > how to proceed, and nobody bothered reporting a problem. I skip them from automation and from time to time I handle it manually. Agostino [1] https://github.com/williamh/pybugz/issues/105
Re: [gentoo-dev] Re: [PATCH 1/1] linux-info.eclass: Add SKIP_KERNEL_CHECK in addl funcs to support tinderbox
On sabato 3 settembre 2022 10:49:01 CEST Toralf Förster wrote: > Sounds promising, so SKIP_KERNEL_CHECK="y" in make.conf will make it ? right. Agostino
Re: [gentoo-dev] [PATCH 1/1] linux-info.eclass: Provide ability to skip CONFIG_* checks
On sabato 6 agosto 2022 04:12:18 CEST Mike Gilbert wrote: > Please avoid abusing the I_KNOW_WHAT_I_AM_DOING variable any further. I'm the original requestor of this change. I agree with floppym, so at this point I'd suggest to migrate the current I_KNOW_WHAT_I_AM_DOING into something that reflects what actually is doing/skipping. Atm we have: $ grep -Rl I_KNOW_WHAT_I_AM_DOING ecm.eclass check-reqs.eclass perl-functions.eclass Agostino
[gentoo-dev] Create an index for all qa notices
Hello all, I noticed that we have many people that, after received a bug report, ask for what the reported 'qa notice' means. Sometimes there is a tracker and people can take an hint from the resolved bugs but when there aren't a lot of info I feel they are a bit lost. Today, by pure chance, I stumbled upon the "Rust Compiler Error Index" and I thought: why we don't do the same thing with our qa notices? I think that devmanual could be the right place and each QA notice should have an 'identification code'. In that way we can link the error in the qa notice like: https://devmanual.gentoo.org/appendices/qa-notices/qa0001[1] https://devmanual.gentoo.org/appendices/qa-notices/qa0002[2] and so on. Reference: https://doc.rust-lang.org/error-index.html[3] What do you think? Agostino [1] https://devmanual.gentoo.org/appendices/qa-notices/qa0001 [2] https://devmanual.gentoo.org/appendices/qa-notices/qa0002 [3] https://doc.rust-lang.org/error-index.html
[gentoo-dev] [TINDERBOX] lto
Hello all. This is to make you aware that, per sam request, tinderbox is testing the tree against lto. At the time of writing, the CFLAGS/CXXFLAGS tested are: -flto -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing They are mentioned in the comment 0 of each bug. To make it more explicit, '(lto)' will appear in the summary too. The buglist is available here: https://tinyurl.com/yc4tu3cj Agostino
Re: [gentoo-dev] Feature request: auto-CC for bugs modified via commit tags
On martedì 25 gennaio 2022 18:00:30 CET Michael Orlitzky wrote:
> Can I request that Bug: and Closes: tags in our commits automatically
> CC the committer on the bug that is modified?
>
> Use case: I often fix (sci-*) bugs that I'm not CCed on, and a user
> will leave a comment like "it still crashes on x86" that I never see.
> Of course, I could manually CC myself on every bug. But that will send
> everyone an extra email, and is forgettable. Plus, avoiding the manual
> step is kind of the point of the automation, right?
>
> One potential downside is that the commit author could wind up CCed
> twice via an alias, but that could be solved with a sufficiently clever
> implementation. Or disregarded if it's not too much of a problem in
> practice; the bugs will usually be closed, after all.
While it does not hurt implement an hook I'd say that:
- CI already cc'es the author of the commit when he breaks a package or
introduces a QA
issue.
This is related to a new bugs and, obviously, does not cover your use-case.
- If you are CC'ed by the hook and you are part of the alias that is the
assignee of the bug,
you will receive two emails unless the hook integrates the alias.
- Based on the previous point, I'd suggest to use a wrapper if you want to be
cc'ed on the
bug you are resolving:
#!/bin/bash
BUG="${1}"
COMMIT_MESSAGE="${2}"
repoman commit -c "${BUG}" -m "${COMMIT_MESSAGE}" && bugz --key "${APIKEY}"
modify --add-cc n...@gentoo.org "${BUG}"
Agostino
Re: [gentoo-dev] [RFC] Moving more architectures to ~arch only
On giovedì 14 ottobre 2021 15:40:02 CEST Marek Szuba wrote: > WDYT? I agree for arches that have exotic hardware but I'd keep x86 since testing can be done on amd64 via 32bit chroot. On the other hand I'm pretty sure we have few x86 users so, sooner or later, x86 will go into ~arch as well. Agostino
Re: [gentoo-dev] [RFC] Decoupling stabilization from security bugs
On giovedì 12 agosto 2021 14:53:33 CEST Michał Górny wrote: > To resolve these problems going forward and establish consistent > behavior in the future, I'd like to propose to disable 'package list' > fields on security bugs and instead expect regular stabilization bugs to > be used (and made block the security bugs) for stabilizations. While I > understand that filing additional bugs might be cumbersome for some > people, I don't think it's such a herculean effort to outweigh > the problems solved. I think it is a good idea but the stabilization bug that blocks the security bug should at least have something (bugzilla KEYWORD?) to facilitate the search of the security stabilization. Atm we look for bugs with assignee = security@ and cc = arch@ Agostino
[gentoo-dev] Lastrite app-crypt/WiRouterKeyRec
# Agostino Sarubbo (2021-08-12) # Latest release 2012, not anymore useful for current routers # Removal in ~30 days. app-crypt/WiRouterKeyRec Agostino
[gentoo-dev] Tinderbox available for overlays
Hello, I would like to let you know that tinderbox is available for overlays. If you want tinderbox to run against your overlay, just send me an email and provide a valid Gentoo Bugzilla account for bug assignation. Agostino
Re: [gentoo-dev] Declare the type of source
On lunedì 28 giugno 2021 17:07:57 CEST Michael Orlitzky wrote: > If the package declares a dependency on e.g. virtual/c-compiler, ago > would want to re-test it whenever a new version of any compiler is > released that satisfies virtual/c-compiler. Conversely, if the package > doesn't require virtual/c-compiler, we may assume that it doesn't > compile C code, and is not affected by the new version. I need to admit that your solution is more simplest because there is nothing to implement. We can create a new category (like virtual) called tinderbox, then for example we could have: tinderbox/c tinderbox/c++ tinderbox/go and so on. Those tinderbox 'packages' added as DEPEND must not pull a default compiler or so, instead they will not pull anything. They are there with the purpose of show the output of something like: equery depends tinderbox/c Agostino
[gentoo-dev] Declare the type of source
Hello all, long story short: when there is a major change (new gcc, new libc, and so on), tinderbox takes a lot of time to test the entire tree. Let's do a practical example: A new version of sys-devel/gcc is added to the tree. There is no way to know how much packages compiles C/C++ code, so the easiest way is compile the entire tree. Instead, imagine that each ebuild declares a variable called SOURCETYPE ( or similar, or in metadata.xml if you prefer ) and with a tool like equery/eix we are able to get the list of all packages that compiles C code. The same thing applies to other languages like python, ruby, go and so on where compile the dev-$language category covers a lot of packages, but there will be always other ebuilds that uses $language in other categories. What do you think? Agostino
Re: [gentoo-dev] eqawarn and Qa Notice
On lunedì 28 giugno 2021 11:28:23 CEST Michał Górny wrote: > That said, it might be more consistent to change Portage behavior to use > some visible distinction between output types (not just color), e.g. > have it output: > > * [QA] ... > * [WA] ... > * [ER] ... +1 Agostino
[gentoo-dev] eqawarn and Qa Notice
Hello,
atm we have qa checks in:
- ${PORTDIR}/metadata/install-qa-check.d
- /usr/lib/portage/pythonX.Y/install-qa-check.d (installed via portage)
Many of them do not begin as "Qa Notice" so it is very hard track them without
naked eye especially via tinderbox.
There is a bug where I reported part of:
https://bugs.gentoo.org/728046
are there any contrary opinions in adding "Qa Notice" at the begin of each
check?
Agostino
Re: [gentoo-dev] [PATCH 2/2] python-utils-r1.eclass: Enable parallel bytecompile compilation
On mercoledì 23 giugno 2021 11:36:33 CEST Mart Raudsepp wrote: > + jobs=$(( nproc + 1 )) I don't know who historically started the nproc+1 story (it looks to be in the handbook too), but it has been demonstrated that nproc+1 is slower than nproc. Agostino
Re: [gentoo-dev] Update your IRC handle in LDAP
On sabato 29 maggio 2021 10:09:46 CEST Michał Górny wrote: > It would be also nice if you took this as an opportunity to grow up > and start using your developer nickname instead of switching through > silly nicknames all the time, so that people can actually find you. +1 Agostino
[gentoo-dev] TINDERBOX and CI updates: installed packages and commit that causes rebuild
Hello all, I would like to send an update about what recently added in the tinderbox/ci systems. At the begin of the build log, the commit SHA that causes the build is pointed out. This is useful in cases like: 1) There is a commit about package A 2) Package A needs package B as a depend 3) Package B fails 4) People ask why they have been CC'ed At the begin of the log there is also the list of installed packages (qlist - ICvUSS), this is useful when people ask if package X is installed or if USE Y is enabled. Since it is on a browser, ctrl-f helps a lot in this case. Example here: https://787971.bugs.gentoo.org/attachment.cgi?id=705810 Agostino
[gentoo-dev] CI and be CC'ed in a bug report
Hello, I've noticed that it's been in vogue lately say "as you were asked many times" when there is something to say. Well, this often (always?) happens without a reference but I don't care. As asked by sam, CI should CC people that are breaking stuff with their commits, see: https://cutt.ly/Wbx08SQ However since there are message like this: https://cutt.ly/vbx2qv2 I'm giving a public explanation about what is happening: 1) Compilation of package 'A' works as expected 2) A new major change is introduced (gcc/glibc/binutils) 3) The CI system always runs an updated system, then it uses latest ~arch versions 4) Someone touches the package by introducing a simple comment in the ebuild 5) Since the ebuild was touched, the CI tries to compile it 6) Package 'A' fails to compile because of GCC-11 and not because of the comment added into the ebuild. This happens mostly when the entire tree has not been 'tinderboxed' with the new major change. So Mikle, I have nothing to fix. For the record, if you want to request a change, you should send at least an email or open a ticket. Send a message somewhere (mostly IRC) and say "as you were asked many times" just seems to be unproductive (or unprofessional, it depends on the point of view) As a side note, as written before and reminder: who does not want to receive email/reports from tinderbox and ci may request to be in the exclusion list. Agostino
[gentoo-dev] Re: [gentoo-dev-announce] [GURU] Bug mail now directed to guru-bugs@g.o
On martedì 27 aprile 2021 10:12:09 CEST Michał Górny wrote: > not to mention someone suddenly starting to file such a large > number of bugs without any heads up. Here are the heads up: https://archives.gentoo.org/gentoo-dev/message/ 9dcfdcd82b774ac812bdb1e7b7fbd396 https://archives.gentoo.org/gentoo-dev/message/ 59efe56d47253521c514d11039e3ff1b
Re: [gentoo-dev] Continuous integration on GURU
On giovedì 22 aprile 2021 15:45:11 CEST Theo Anderson wrote: > Hi Agostino, > > After some discussion in IRC we've agreed to have the maintainer of > the respective packages be assigned to the bug with guru@g.o be CC'd. > Where no maintainer exists for a package guru@g.o remains as the > assignee. If you could make those changes that would be great (I > suppose doing it retroactively would be a bit of a mission and is out > of the question). > > Thanks Existing bugs have been re-assigned. New bugs will be assigned to maintainer and guru is always CC'ed. Packages with no maintainer will have guru@ as assignee. If you notice anything wrong please let me know. Agostino
Re: [gentoo-dev] Continuous integration on GURU
Thanks for all feedback. Please discuss all points internally (branch, email, trackers and so on) and send me an email with all changes you would like to have. Agostino
Re: [gentoo-dev] Continuous integration on GURU
On giovedì 22 aprile 2021 14:59:00 CEST Ionen Wolkens wrote: > And, even if you don't see it like that, someday someone may want > to go on a fixing spree using those trackers (may it be for ::guru > or ::gentoo) but will keep seeing them mixed up together. You can do it as wel by doing a separate bugzilla search. Agostino
Re: [gentoo-dev] Continuous integration on GURU
On giovedì 22 aprile 2021 12:02:20 CEST Michał Górny wrote: > Well, I suppose scanning the dev branch would be preferable over > the master branch. In reality, they are usually only a few hours apart > but it might be useful to know of new breakage in dev before it's merged > to master. > > It would be ideal if you could do a switch when master and dev are > in sync, and just copy the state from master. Hi, I think that your approach could be generally valid but for this use case I'm against because of the following: 1) The approach is valid in cases like our github PRs and the bot that approves the commit. In this case, who moves the commit between branches does not know if the scan has been done or not. 2) I don't see the reason to scan against something that we don't know if will be the same in master branch 3) We are not doing a similar approach for ::gentoo so I don't see why do this for GURU since, after all, it is an overlay 4) Packages in master are supposed to be tested at least from 2 different people (who made the commit in dev and who moves the commit to master) so it means less bugspam > One more thing: might be a good idea to consider splitting some > of the 'big' trackers (like CFLAGS) between Gentoo and GURU. I think > solving these bugs in GURU has lower priority than in Gentoo. I think that trackers like CFLAGS/LDFLAGS are here to track how many packages have the problem. I don't see it like (for example) the gcc-porting tracker that gives the idea about how much packages need a fix and how much packages need to be last-rited Agostino
Re: [gentoo-dev] Continuous integration on GURU
On giovedì 22 aprile 2021 12:22:00 CEST Theo Anderson wrote: > On the subject of many bugs, there are now almost 150 open bugs > assigned to g...@gentoo.org. With this has come quite an email avalanche > for which I think people must have set up mail filters by now. I > imagine this means that bugs will no longer get the same > amount of attention as they used to. To increase the visibility do you > think it would be a good idea to CC or assign the bugs to the specific > package maintainers rather than g...@gentoo.org? Hello Theo, I'm fine to assign directly and/or cc'ing guru@. For now I'm following the guidelines but it takes one second to change it. Please discuss this internally and let me know if I have to change the assignee. Agostino
Re: [gentoo-dev] Continuous integration on GURU
On giovedì 22 aprile 2021 12:25:50 CEST Michał Górny wrote: > On Thu, 2021-04-22 at 11:59 +0200, Agostino Sarubbo wrote: > > Hello, > > > > I would like to let you know that the CI is now able to work with > > overlays. > > > > Since Guru is pretty active I took advantage of this situation to > > implement > > and test the CI > > > > Atm it has been configured to work with master branch. > > I don't know how much is useful scan the dev branch since a first revision > > has not yet been done. If you have opinions about, please let me know. > > > > More info at: > > https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ > > > > The bugs will have an internal_ref as guru_ci. >
[gentoo-dev] Continuous integration on GURU
Hello, I would like to let you know that the CI is now able to work with overlays. Since Guru is pretty active I took advantage of this situation to implement and test the CI Atm it has been configured to work with master branch. I don't know how much is useful scan the dev branch since a first revision has not yet been done. If you have opinions about, please let me know. More info at: https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ The bugs will have an internal_ref as guru_ci. Agostino
Re: [gentoo-dev] [TINDERBOX] Testing guru
On martedì 6 aprile 2021 17:51:19 CEST Agostino Sarubbo wrote: > Hello, > > the tinderbox is testing the packages into guru overlay. > Please expect related bugs. > If you have any objections, please let me know > > Agostino @guru-committers: please use "repoman commit -c" when you commit the changes. Thanks
[gentoo-dev] [TINDERBOX] Testing guru
Hello, the tinderbox is testing the packages into guru overlay. Please expect related bugs. If you have any objections, please let me know Agostino
[gentoo-dev] Non-maintainer commits and CI
Hello, it happens frequently that CI discovers failure(s) in non-maintainer commits. The most striking examples are maintainer-needed, proxy-maint and general pull request where who made the change has no visibility on the new bug. Do you think that is a good idea to CC everyone involved in the commit? Agostino
Re: [gentoo-dev] [TINDERBOX] A round with dev-lang/python-exec[-native-symlinks]
On martedì 29 dicembre 2020 13:03:07 CET Michał Górny wrote: > @ago, could you make sure that the tinderbox tells people to read up > on the tracker? I added the note. However the first thing I would to do in reports like this is at least click on the tracker bug. -- Agostino
[gentoo-dev] [TINDERBOX] A round with dev-lang/python-exec[-native-symlinks]
Hello, as requested by mgorny, the tinderbox is doing a round with dev-lang/python- exec[-native-symlinks]. Please expect related bugs. The tracker is at: https://bugs.gentoo.org/762406 -- Agostino
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
On lunedì 28 dicembre 2020 09:56:19 CET Michał Górny wrote: > I would like to propose that we stop patching > packages, discontinue support for it and last rite it. +1 -- Agostino
[gentoo-dev] Please close bugs when a commit fixes it
Hello, I noticed that people uses "repoman commit -b" and bugs remain opened. In case of test failures, CI does not run tests if there are already opened bugs about that so it is unable to catch if your commit really fixed the issue. Thank you
Re: [gentoo-dev] A feedback about the CI bug reporting system
On lunedì 9 novembre 2020 13:13:19 CET Marek Szuba wrote: > I think this might be the case of a "silent majority, vocal minority" > scenario. For the record: I for one have found your tinderbox bugs very > useful, not in the least because you test unusual configurations my own > build testing does not cover. There have been glitches - but IMHO very > few of them, and human operators make mistakes too. > > I still very much wish your tickets were tagged in a way which would > make it possible to separate failures from QA notices (especially those > that show up during normal emerge runs, such as that suspected > DISTUTILS_USE_SETUPTOOLS mismatches), though. I really do not need > e-mail notifications about the latter, looking them up via my p.g.o page > is quite sufficient. Hello Marek and thank you for the feedback. Ftr DISTUTILS_USE_SETUPTOOLS has been disabled for a while but I think we can use a tag in WHITEBOARD to meet your needs. I think it has been used in the past and it doesn't hurt have it. Agostino
Re: [gentoo-dev] A feedback about the CI bug reporting system
Hello Thomas, On sabato 7 novembre 2020 17:06:56 CET Thomas Deutschmann wrote: > I have to second what other already said. > > Dropping bugs and forcing maintainer to review and spend time to check > if there is a problem and what was the reported problem at all creates > more work. And I consider anything creating more load for others which > was not requested not as helpful. Let me repeat what I have already written. Does portage print the exact error when dying? No, so we have a package manager that ends without saying why and while everyone is refusing to talk about that and understand this, in my opinion this issue denies everyone to make an automated full/complete report. Toralf did and is doing a great job, but you are confusing CI with a man that reviews and files bug half-manually. > That said, I don't have these problems with toralf's reports. They are > more complete and will show the problem in the report for most bugs. Let me repeat what I have already written somewhere. The rule in case of bug report is to attach the build log and provide emerge --info. If you think that those info are not enough that's fine, but please document that. > I do not agree with this conclusion. Just because developers didn't > ignore you and spent additional time to understand and try to help like > we normally do when we get reports from inexperienced users, doesn't > mean it was a pleasure... If find the exact error in a build log requires too much time and you do not want to spend time, instead of be forced to not ignore me you can request to be excluded from the reports. In general the CI reports are there to help. People that does not see those reports as help can request to not receive reports anymore. Agostino
Re: [gentoo-dev] A feedback about the CI bug reporting system
On venerdì 6 novembre 2020 08:21:39 CET Agostino Sarubbo wrote: > Hello all, > > 6 months have been passed after the CI system started to file bug reports. > ~ 4700 bugs have been submitted > > We _know_ that atm is not possible to set a specific summary, instead a > generic summary is used in case of compile failures and test failures. > There are also some documented limitations. > > If there aren't much commits, usually you get the bug after 30 minutes after > the commit and this looks to be nice. > > Since there are conflicting opinions I would like to know if you find it > useful or not. > > More info about the project here: > https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ > > Please keep me CC'ed > > Thank you > Agostino Thanks all for the feedback. What looks strange is that ci/tinderbox opened ~4700 bugs, sure, there are invalid/duplicate bugs but the majority are fixed so in my opinion they were useful, but looking at the mailing list feedback looks to be a completely crap. I want to play the game of destructive people but in a constructive way. Thanks to @gyakovlev for the idea I have opened a new github project where we can collect the requests and the bugs: https://github.com/asarubbo/ci/issues An important note: I consider this 'project' as something related to QA ( if you have a different opinion feel free to say ), so since I received rant from developers for something requested by other developers, I will touch the code ONLY when there is the QA lead approval. When you want a new feature or you want to modify something that already exists, please open a thread (gentoo-dev is fine, and thanks to bman for the tracking idea) and open a github issue only when there is a written track of the QA lead approval mentioned above. There is a README into the repository that explains all class of bugs discovered by the CI system. Thank you Agostino
Re: [gentoo-dev] A feedback about the CI bug reporting system
IN REPLY to Aaron Bauman that didn't keep me CC'ed as requested: >Is this coming from the same individual who would complain when security >bugs were not filled out properly in the summary? So, take a dose of >your own medicine here. People prefer usable reports that allow them to >solve problems. First: we are talking about a different topic, so what happened in security context doesn't matter here. Second: I never complained about summary of security bugs, so since you said: "Keep it on the ML and people will have record." can you tell me where your statement is recorded? >Where was this positive feedback? As you stated on #gentoo-dev today you >don't really participate in the ML... so, I presume the positive feedback >came on IRC. Most of us don't scan those logs to "prove" such things. Keep it >on the ML and people will have record. By positive feedback I mean that the system worked and discovered bugs. >This shouldn't be "ago v toralf" This isn't ago v toralf and it never was unless you misunderstood. > Right now, it looks like that is mostly negative given the ML feedback. I really guess you have a distorted view of reality. >Frankly, if this is anything like your security efforts (re: fuzzing) >then I can understand the concerns people have expressed. >Please, stop with the "automate everything, open many bugs, and move on" >philosophy. It didn't work well in security and it won't work here. >Build a quality solution that makes an impact for the distro. Again, this is something not related of what we are talking about. Fuzzing research have been stopped over 3 years ago so what you're talking about? >ACK. This is the same level of coordination the security team received >when a multitude of bugs were filed once ago discovered fuzzing. Sorry, but I real do not have tracks of what you are talking about. > It was lots of bugs little information, inabilities to reproduce various >crashes, invalid ratings/severity levels, and often a blog that >simply regurgitated the same inaccuracies. Usually I don't partecipate in mailing list because it is a place where other can throw mud on others like this. Little Information? I do not guess so because the provided information were: 1) command to reproduce 2) stacktrace 3) affected version 4) fixed version 5) commit fix 6) reproducer 7) timeline > inabilities to reproduce various crashes If you can't reproduce a crash it is not my fault > Any attempt to ask/coordinate was met with lack of information or simply "see my blog" responses. Do you have a track of this? > The only time interaction occured was when bugs were closed due to invalidity, lack of information, or severity/ratings downgraded. Do you have track of this? In short, please remain on topic, if you have anything to say about other projects, feel free to open a thread where we can do a separate discussion ;) Thanks P.S. I don't know why but instead of seeing a constructive discussion I notice that there is always a bit of contempt about what others do, and this is really bad for an opensource community
Re: [gentoo-dev] A feedback about the CI bug reporting system
On sabato 7 novembre 2020 07:15:31 CET Robin H. Johnson wrote: > Can you please tell us what you need to let others contribute to > improving the quality of the reports from your CI system? Hello Robin, I don't understand why in general people focus on what is missing into a simple script that merges packages instead of ask himself where this feature should go. In my opinion, we can try to do whatever to the script or we can write a new one but the main problem is in portage that only states in which phase emerge is dying. If emerge is able to tell the exact error, then it can be used also from users that want to do bug reports. Agostino
Re: [gentoo-dev] A feedback about the CI bug reporting system
IN REPLY TO Michał Górny that didn't keep me CC'ed as requested: >I do disagree with your presumption that this needs to be automated. >The whole point behind providing a service is that you should be ready >to dedicate *your* time into the service. However, we keep feeling that >you assume that your time is too precious, and it is better to waste >a little bit of everybody else's time. This is why Toralf's effort is >much more appreciated. I don't guess that my time is precious and your time is not. If you take a look at the amount of bugs you will see that it is not possible for an human to file those bugs manually. So if is not clear, the concept would be: I invest my time to find bugs that have not been discovered by others, but you give me an hand to find the exact issue by analyzing the build log helping yourself with ctrl-f function of the browser >I am concerned about new test scenarios being run and QA warnings being >reported without proper research and documentation. It's not exactly >helpful to spam people with hundreds of bugs without a single proper >document explaining how to resolve issues. This just provokes people to >do apply bad workarounds, not to mention wasting everyone's time. Usually, qa notices are not something invented by me. So in other words you are saying that while I'm reporting a QA notice that comes from portage I should explain how to solve the problem? I guess you should resolve the problem upstream. Each QA notice must have something that explain how to solve that. While considering the above, usually to help I add something useful at the end of the bug. >The compiler-rt bugs were one example of both of my points being valid. >You've started running a specific scenario without researching >the underlying problems first, and you have missed entirely that you're >reporting a lots of bugs for the same root issue. People have gotten >hundreds of bugs with no clear explanation how to fix them. The only >reason we didn't get hundreds of horrible 'fixes' is that the problem >was probably too hard to workaround. Did you forget how the compiler-rt class of bugs started? Let me remind that: - I had the tinderbox with no load and nothing to check - I thought about a round with compiler-rt - Since _YOU_ are the most active behind the llvm stuff I asked to you if you know how to use the compiler-rt stuff ( I have the IRC logs if you really have a memory lapse ) - You and Afrever answered me about the C/LD flags to use. - After the first report (it was an error never seen by me) I asked: Hey is this a report related to compiler-rt? You answered yes - I asked if it was worth to create a bug tracker - you confirmed - I started to file the other bugs So would be better to say to the community that: - I have asked to you "how-to" - You shared the necessary info - I started to file bugs (~50 and not hundreds as you said) - You (or someone else) discovered that it is broken without libcxx >DISTUTILS_USE_SETUPTOOLS is yet another example of a minor catastrophe. >Sure, I could've added more information to the check message. However, >there is a major difference between people slowly getting QA warnings >from a new check and people getting hundreds of bugs telling them to fix >these warnings. This is a difference between involving a thinking >person, and a semi-automated process that doesn't account for obvious >mistakes. DISTUTILS_USE_SETUPTOOLS is yet another example of memory lapse. Did you forget how the DISTUTILS_USE_SETUPTOOLS class of bugs started? Let me remind that: - During the stabilization process I saw these DISTUTILS_USE_SETUPTOOLS warnings - I asked if was fine to report them - You answered that was fine, but avoid the cases where the warning was in stable but was fixed in ~arch - after few weeks or month ( I don't remember exactly) I was asked by aballier to file this class of bugs. Since tinderbox runs always the latest version of the software, I started to file bugs When you started to see these bugs you also requested to show the exact value of DISTUTILS_USE_SETUPTOOLS that I immediately added. So what I would to point out is: If someone reads this thread think that I autonomously started posting nonsense bugs, but in reality these bugs were requested and initially also resolved. So if at some point you discovered that these bugs are nosense because of upstream changes, I have no fault. >AR bugs is another class of controversy. There is one thing to ensure >that build systems respect AR for toolchain work, there is another to >assume that it's fine not to have 'ar' archiver on the system. And yes, >I do realize there are other people involved in this bad idea that >apparently now you need an arch-specific toolchain to unpack >the archives inside Debian packages. So this is something that points out that the situation is not clear, it's not me, the tinderbox or the CI. >I am also concerned about the sheer number of
Re: [gentoo-dev] A feedback about the CI bug reporting system
On venerdì 6 novembre 2020 09:18:50 CET Joonas Niilola wrote: > Would it be possible for "someone" to figure it out, if you made your > tinderbox scripts/code public? ;) Hate to say it, but toralf does pretty > good job here, so it could be better. As stated multiple times, toralf said that the way he's filing bugs expect a copy-paste action for the summary, this is not possible if you want to do that in a more automatic way. > Yes, I do find your tinderbox work useful most of the time. Thanks! > However the latest, ehh, show with DISTUTILS_USE_SETUPTOOLS has made > people do *hundreds* of commits that now apparently need a fixing > anyway, or reverting back, and that doesn't feel nice. Sure maybe the > eclass could do some fixing too, but maybe this notice wasn't meant to > be full-tree scanned (at least _yet_). This class of bugs comes from a request. Months ago I also asked if I had report these bugs during the stabilization and I got a positive feedback. > From my point of view your work is, and has been, appreciated, but you > could coordinate better with other people. Hate to say it again, but > toralf does seems to do a better job here too in that regard. Unless > you're fine with comparing tinderboxers. > With toralf's logs it's easy to reproduce the whole environment leading > to a build failure, while with yours it's just build.log, thay may or > may not be enough to find the build-breaking issue. This is something already discussed (maybe privately?) and clearly state by me. If you say that with my logs you are unable to reproduce the issue, since I'm providing emerge --info and build log, you are saying that those info are not enough. So, I'd suggest to fix this issue upstream by clearly defining what is needed in a bug report, because AFAIK atm for a bug report is needed a build log and emerge --info If you want more info, why do not extend the emerge --info into for example emerge --info --extended instead of ask one by one to attach more info?? So the point is that there is no rule but just everyone ask without fixing the problem upstream. While you have a new option for detailed info, every people that run tinderbox or just people that report bugs can use it. If you see an example of toralf bug, I can see: gcc-config -l: [1] x86_64-pc-linux-gnu-7.3.1 [2] x86_64-pc-linux-gnu-10.2.0 * clang version 11.0.0 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/lib/llvm/11/bin /usr/lib/llvm/11 11.0.0 Available Python interpreters, in order of preference: [1] python3.7 [2] python3.9 (fallback) [3] python3.8 (fallback) [4] python2.7 (fallback) Available Ruby profiles: [1] ruby25 (with Rubygems) [2] ruby26 (with Rubygems) [3] ruby27 (with Rubygems) * Available Rust versions: [1] rust-bin-1.47.0 * The following VMs are available for generation-2: 1) IcedTea JDK 3.17.0 [icedtea-8] *) AdoptOpenJDK 8.272_p10 [openjdk-bin-8] Available Java Virtual Machines: [1] icedtea-8 [2] openjdk-bin-8 system-vm The Glorious Glasgow Haskell Compilation System, version 8.8.4 Again: why these info are not in emerge --info if are useful for a bugreport? I'm sure you understand the concept Agostino
[gentoo-dev] A feedback about the CI bug reporting system
Hello all, 6 months have been passed after the CI system started to file bug reports. ~ 4700 bugs have been submitted We _know_ that atm is not possible to set a specific summary, instead a generic summary is used in case of compile failures and test failures. There are also some documented limitations. If there aren't much commits, usually you get the bug after 30 minutes after the commit and this looks to be nice. Since there are conflicting opinions I would like to know if you find it useful or not. More info about the project here: https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ Please keep me CC'ed Thank you Agostino
[gentoo-dev] Re: RFC: Standard build environment variables
On domenica 28 giugno 2020 14:18:23 CEST Michael Orlitzky wrote: > To avoid these issues, I suggest creating a list of "Gentoo environment > variables" in the devmanual with descriptions of how they should be used > and pointers to the references (for why we chose that meaning). That way > a user can export LD, for example, and know that it will be used how he > thinks it will be used. +1 Agostino
[gentoo-dev] Add more toolchain variables to emerge --info
https://bugs.gentoo.org/show_bug.cgi?id=722456 What is your opinion? -- Agostino
[gentoo-dev] Stabilizations and src_test
Hello all, If you work on the stabilization workflow you may have noticed that: - There are people that rant if you don't run src_test against their packages; - There are people that rant if you open a test failure bug against their packages and you block the stabilization. So, unless there will be a clear policy about that, I'd suggest to introduce a way to establish if a package is expected to pass src_test or not. A simple way to achieve this goal would be: introduce a new bugzilla custom flag (like "Runtime testing required" we already have) maybe called "src_test pass" or similar, that, by default is yes and the maintainer should set it to no when needed. In case of 'yes', the arch team member must compile with FEATURE="test" and he is allowed to block the stabilization in case of test-failure. In case there will be a test-failure there are two choices: 1) The maintainer fixes the test failure; 2) The maintainer does not want to take care, so he can simply remove the blocker and set "src_test pass" to no. Both of the above are fine for me. Obviously, if there are already test-failure bugs open, the flag "src_test pass" should be set to 'no' when the stabilization bugs is filled. I'm sure that this way would help to avoid wasting time on both sides. What do you think about? -- Agostino
[gentoo-dev] Last-rites: app-admin/hardening-check
# Agostino Sarubbo (2019-10-18) # Superseded by app-admin/checksec # Removal in 30 days. app-admin/hardening-check
[gentoo-dev] Re: EAPI 2 must die
On giovedì 6 giugno 2019 08:25:54 CEST Luca Barbato wrote: > Anybody has hardware to test it? I can do it on timberdoodle. Agostino
[gentoo-dev] Re: [gentoo-dev-announce] Last rites: dev-db/pgadmin4
On venerdì 26 ottobre 2018 01:37:50 CEST Aaron W. Swenson wrote: > # Aaron W. Swenson (25 Oct 2018) > # Fails to build against up to date OpenSSL library (Bug 663966). No longer > # supported upstream. Use dev-db/pgadmin4. > # Masked for removal on 2018-11-24, bug #669650. > dev-db/pgadmin3 I guess there is a typo in the subject. -- Agostino Sarubbo Gentoo Linux Developer
[gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?
Hello Sergei, thanks to bring into the topic which nowadays is a common point of discussion :) On Monday 24 July 2017 22:22:23 Sergei Trofimovich wrote: > 1. lack of automation I'd summarize the techical steps into: 1) get the list of packages 2) test 3) commit to git 4) write on bugzilla 1 is done by getatoms https://github.com/kensington/bugbot 2 is done by the tester in the manner he prefer 3 no official tool available, I used a modified version of https://gitweb.gentoo.org/proj/arch-tools.git/tree/batch-stabilize.py which is still based on CVS 4 no official tool available, I used my own bash script which calls pybugz So, points 3 and 4 needs to be improved, I have the idea on how the script should look, but I have no time to do it and no python knowledge. I can assist everyone that candidate itself to make the tool/script like I did with kensington when he made getatoms. > 2. lack of manpower lack of manpower, so in my opinion reduce a bit the workload. I proposed something in one of my last mail to -dev, the following refers to the arches with very less manpower: 1) Don't file keywordreq, since noone work on them. File directly stablereq. 2) Reduce the number of the stable packages on those arches 3) Make a more visible list (like this list in term of visibility:https://qa-reports.gentoo.org/output/gentoo-ci/output.html) of the arches-dependent bugs so that everyone can contribute to maintain alive the exotic arches. -- Agostino Sarubbo Gentoo Linux Developer
Re: [gentoo-dev] taking a break from arches stabilization
x86 96 Actually the result is increased by the large number of packages in the gstreamer stablereq. I worked daily-by-daily for amd64/x86 and occasionally for an arch. I always picked up the arch which have more bugs from the above list. A always assured that there wasn't an arch with > 200 bugs. Unfortunately I don't have time to work on the arch-specific. But if I can help with 7 arches you shouldn't bother :) On the other side, I respect and 'share' the point of view of the maintainer which has some arch-specific bugs freezed with noone that take care of. It is a fact that for those arches there are few users, so to improve the situation we can: 1) Don't file keywordreq, since noone work on them. File directly stablereq. 2) Reduce the number of the stable packages on those arches 3) Make a more visible list( like a list here in term of visibility:https://qa-reports.gentoo.org/output/gentoo-ci/output.html) of the arches-dependent bugs so that everyone can contribute to maintain alive the exotic arches. If is not our interest to maintain those alive, just ignore my proposal. -- Agostino Sarubbo Gentoo Linux Developer
[gentoo-dev] taking a break from arches stabilization
Hi all. every time that I attach my tmux session to see what happens on irc, I always see the same discussion about the 'minor' arches status. Since I joined gentoo(2011) I worked on all arches except hppa, I put more effort in amd64 and less where I saw other people work on it (arm,alpha) But every time the magic phrase is that those arches are unmaintained. Now, since I work on these arches just to help, i.e. I don't have any business and I do non have any installation of those arches and the work I'm doing is not appreciated at all I decided to stop for now. If your dream is to put sparc and ia64 to ~arch, go ahead, I have no objections. I will take a break also from amd64 and x86...let's see how things will change. -- Agostino Sarubbo Gentoo Linux Developer
[gentoo-dev] About ALLARCHES
We are working to provide some tools for the stabilization process. Unfortunately, there isn't atm something able to manage the requests with the ALLARCHES keyword, So, *everyone* with the commit access can keyword for all after a stabilization/keyword happened at least for one arch. Thanks.
[gentoo-dev] The changes about the stabilization process - part 2
Hello All, this message is an update of: https://archives.gentoo.org/gentoo-dev/message/4b2ef0e9aa7588224b8ae799c5fe31fa What is changed in the meantime: 1) All operations on the bugzilla, about the sanity-check and so on are done with the account stable-...@gentoo.org So, if you want to filter them, please use the 'X-Bugzilla-Who' flag. 2) We will move the "Atoms to stabilize" field to "Packages list" as pointed out by ulm here: https://archives.gentoo.org/gentoo-dev/message/0714886af9e9a233d8dc2b2d0a1f261e 3) We have two pages on the wiki that come from past contributions; they were not written recently and they need to be reviewed. So consider the content a draft, but keep the links that will be permanent. https://wiki.gentoo.org/wiki/Stable_request https://wiki.gentoo.org/wiki/Package_testing -- Agostino
[gentoo-dev] The changes about the stabilization process
Hello all. with the great and awesome work of Michael Palimaka (kensington) and the support of the wg-stable, for the stabilization process, some changes on our bugzilla have been done. We have two new components: - Stabilization - Keywording When you will choose one of those, you will see two new fields: - Atoms to stabilize - Runtime testing required Atoms to stabilize needs to be filled in the following way: =CATEGORY/PACKAGE-VERSION so for example: =app-portage/eix-0.31.10 In this way all arches in CC need to stabilize the specified atom. When you have multiple atoms with different targets you need to do: =app-portage/eix-0.31.10 amd64 x86 =app-portage/portage-utils ppc In the following way, amd64 and x86 will stabilize only eix and ppc will stabilize only portage-utils. Runtime testing required (which is not mandatory) needs to be filled in the following way: - Yes, you are asking to run a package after have compiled/installed it. - No, you don't need runtime testing (e.g. packages that install only some files). Unfortunately there isn't an automated way to port all current stablereqs to those changes, so I will port them to the stabilization component and ask to fill properly the "Atoms to stabilize" and "Runtime testing required" fields in the next days. In the near future, we will produce a wiki page which describes how to properly request the stabilizations to ensure that they will be processed correctly. NOTE: I'm intending this message as a sort of announcement to invite everyone to port their stable requests. I guess there isn't much to discuss here. If you don't like some of the changes that have been done, please open a specific thread about. Thanks. -- Agostino Sarubbo Gentoo Linux Developer
[gentoo-dev] ALLARCHES and the maintainer action(s)
Hello, The ALLARCHES keyword is out since some time. For who does not remeber, the announcement is here [1] So, if an arch developer tests the package(s) on one architecture, he is allowed to stabilize/keyword for all. Unfortunately some people forget to look at the KEYWORDS field and stabilize the package only for one architecture. At this point I'm asking maintainer(s) to stabilize/keyword their packages when an arch developer made a stabilization and forget to do the task for all arches. In this way you give an hand to the arch teams. Thanks in advance. [1]: https://archives.gentoo.org/gentoo-dev/message/5d96b51ced1d1ed126951f117c828482 -- Agostino Sarubbo Gentoo Linux Developer
[gentoo-dev] Re: [gentoo-core] Git Migration: go-live!
On Sunday 09 August 2015 05:36:16 Robin H. Johnson wrote: Quick instructions: Set PORTAGE_GPG_KEY=0xLONG-GPG-KEY in your make.conf $ git config user.signingkey 0xLONG-GPG-KEY $ git clone git+ssh://g...@git.gentoo.org/repo/gentoo.git $ vim ... $ repoman commit -m '...' [2] $ git push --signed 2 questions: 1) The git workflow [1] does not mention to add PORTAGE_GPG_KEY to make.conf and neither to use the long gpg key. Does the short create a problem? 2) The git workflow [1] says to do git config --local commit.gpgsign 1 - Do we need to use git push --signed if was already in the config ? I'm asking just for have an up-to-date documentation, and maybe add all the notes there. Thanks. [1]: https://wiki.gentoo.org/wiki/Gentoo_git_workflow -- Agostino Sarubbo Gentoo Linux Developer
[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: kde-base/kdepim-icons/
On Sunday 09 August 2015 20:42:00 hasufell wrote: So, now we have 21 commits with the exact same commit message: = Stable for amd64, wrt bug #556974 = At that point, it's even debatable to have separate commits. IMO, if you stabilize a huge chunk of ebuilds, you have two possibilities: 1. just make it one giant commit (we don't revert stabilizations anyway)... if it's category-based, start the commit message with = kde-base: stable after dev-qt/qtgui bump for ia64 = if it is related to a particular package (e.g. a bump of dev-lang/ruby and very closely related packages that span across multiple categories) start it with = dev-lang/ruby: stabilize for ia64 including reverse dependencies = or somesuch (which is still not very nice, but better) 2. Have a sensical commit message for each saparate commit. E.g., make a local bash hack that automatically prepends category/pn to your commit message (I think zlogene has done that already) and hope for bug https://bugs.gentoo.org/show_bug.cgi?id=557148 to get more attention. This is better than mass commits if it can be sensibly automated. Anyway. 21 commits with the same message is really confusing. I can see that arch teams might have the most trouble with commit methods, becasue they have the highest commit rate, but we have to improve this. Since the repoman commit was done per package, I guess the feature requested in bug 557148 should fix this type of issue. -- Agostino Sarubbo Gentoo Linux Developer
[gentoo-dev] about the stable requests
Looks like everyone is file stable requests with own rules or better to say is without common rules. I'd like to document a sort of best-practice(s) on our wiki. Who want to partecipate? -- Agostino Sarubbo Gentoo Linux Developer
Re: [gentoo-dev] Enable format-security in the dev profiles
On Monday 21 July 2014 10:08:44 Diego Elio Pettenò wrote: Any -Werror=* flag will make random autoconf checks fail for no good reason, don't use them on profiles, it's silly. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ I don't see where I asked about -Werror instead of only - Wformat. -- Agostino Sarubbo Gentoo Linux Developer
Re: [gentoo-dev] Enable format-security in the dev profiles
On Monday 21 July 2014 08:52:51 Paweł Hajdan, Jr. wrote: On 7/21/14, 6:02 AM, Samuli Suominen wrote: Why not generate a Portage QA warning out from the warning -Wformat-security produces instead? That way compile wouldn't abort needlessly. +1, and then it can be done globally. Paweł This is fine for me too. -- Agostino Sarubbo Gentoo Linux Developer
[gentoo-dev] Enable format-security in the dev profiles
Hello, I'd like to enable by default format-security at least in the dev profiles. Thought? References: https://bugs.gentoo.org/show_bug.cgi?id=259417 https://fedoraproject.org/wiki/Format-Security-FAQ -- Agostino Sarubbo Gentoo Linux Developer
[gentoo-dev] Re: stabilizing libraries without testing reverse deps
This is a delicate point. If you look at the policy, it says to test few rdeps. The arch tester is in charge to test the packages on his architecture. These type of failures are _not_ architecture dependant. So, instead of have 10 ATs that are testing the same rdeps, seems logic that the maintainer could do it one time. What do you think?
Re: [gentoo-dev] Move m68k, sh, s390 to ~arch
On 09/23/2013 22:41, Markos Chandras wrote: (unless of course you want to increase your number of cvs commits which is a worrying argument on its own) 11:16 #gentoo-bugs: +bonsaikitten ago: do me a favour and de-keyword all affected packages for s390 Also, nobody give me an award for the commits, so I really don't understand what you mean. -- Agostino Sarubbo Gentoo Linux Developer
[gentoo-dev] Move m68k, sh, s390 to ~arch
Hello, the council has decided[1] to drop m68k, sh, s390 to unstable. If someone has something to say about, this is the last opportunity or in few days I will start to mark them as ~arch. [1]: https://www.gentoo.org/proj/en/council/meeting-logs/20130917-summary.txt -- Agostino Sarubbo Gentoo Linux Developer
[gentoo-dev] Improve the security of the default profile
Hello, during an irc debate, me and other people just noticed that the default profile could use more flags to enhance the security. An hint is here: https://wiki.ubuntu.com/ToolChain/CompilerFlags Please argue about what we _don't_ use. Note: please CC me in your response. -- Agostino Sarubbo Gentoo Linux Developer
Re: [gentoo-dev] Improve the security of the default profile
On Thursday 05 September 2013 12:47:01 Tom Wijsman wrote: What I wonder about here is at which cost this does come, when looking at the fstack-protector then I see that it emits extra code; so, now the question is what kind of overhead this causes. We use -fstack-protector-all in the hardened profile, so it is not unknown at all. I am pretty sure security might not be that important on a real time system that perhaps isn't connected to the internet; so, besides making it the default, we might want to introduce the necessary means to turn it off again, by the very least perhaps documentation would suffice. Do you intend to discuss that flag or more generally any security flag? I just want to point out the thread because other people will have something to say about. -- Agostino Sarubbo Gentoo Linux Developer
Re: [gentoo-dev] Improve the security of the default profile
On Thursday 05 September 2013 13:09:00 Tom Wijsman wrote: Yes, I am aware of that, I am not saying it is unknown; but I am wondering about those questions: What kind of overhead does this cause? At the first look I don't see anything wrong. Do you intend to discuss that flag or more generally any security flag? both, let's talk the toolchain guys about. -- Agostino Sarubbo Gentoo Linux Developer
[gentoo-dev] The status of the 'minor' arches in gentoo
In the last time I'm helping some other arches (also arches which I have no interest) because they appears understaffed. Days ago, I tried to make a virtual machine with qemu, for SH since the dev- machine[1] is a bit slow; well, I discovered we have no ISO[2] available and there is no handbook[3] for it. The same thing is for S390/S390X/M68K/. So how I am able to install one of that _supported_ arches if there isn't any sort of guide? An interesting fact is that we have an handbook for MIPS[4], a declared unsupported architecture (does not make sense for me). Another example is that we have no stable keyword on GCC/glibc for m68k and I don't know if I need to use another compiler or another libc. Checking on bugzilla I saw no report for some of those arches, so for me that _partially_ means that probably there are very few users for those arches on gentoo. Now, imho, we have 2 choice: 1)Support them with an iso or at least a manual if we can't do an handbook 2)Lose the stable keyword and don't waste manpower anymore. What do you think about? Ref: [1]: http://www.gentoo.org/proj/en/infrastructure/dev-machines.xml [2]: http://www.gentoo.org/main/en/where.xml [3]: http://www.gentoo.org/doc/en/handbook/#doc_chap2 [4]: http://www.gentoo.org/doc/en/handbook/handbook- mips.xml?style=printablefull=1 -- Agostino Sarubbo / ago -at- gentoo.org Gentoo Linux Developer
Re: [gentoo-dev] The status of the 'minor' arches in gentoo
On Sunday 17 February 2013 19:36:16 Markos Chandras wrote: First you need to tell us what arches you think they are considered 'minor' and/or understaffed so we can finally document that. Then, in my opinion, the ideal approach would be to just drop the stable keywords for them. http://www.gentoo.org/proj/en/base/index.xml#doc_chap4 I don't see project page for: m68k, sh, s390 20:41 ago expn m68k 20:41 willikins m68k = vapier, 20:41 ago expn sh 20:42 willikins sh = vapier,matsuu,armin76,ago, 20:42 ago expn s390 20:42 willikins s390 = vapier,armin76,ago, -- Agostino Sarubbo / ago -at- gentoo.org Gentoo Linux Developer
Re: [gentoo-dev] The status of the 'minor' arches in gentoo
On Sunday 17 February 2013 20:22:00 Markos Chandras wrote: I am not sure what are you trying to prove here. I point out that there is not iso, no manual, no manpower. No project page does not mean the arch is minor or dead or whatever. For me this means that there is no enough support. Moreover, you see that there are devs in these arches. Did you try to talk to them? For what purpose? I'm asking a general opinion based on some facts. I also asked for a list of minor arches and you didn't provide one. I presume, you think that m68k, sh, and s390 are minor? Yes, they can be. Seriously, who has an m68k? do you see reports/requests on bugzilla? What about ia64, ppc? Do we have enough manpower there? Because iirc there arches also lack in stabilization bugs as well. https://bugs.gentoo.org/buglist.cgi?keywords=STABLEREQ%2C%20keywords_type=allwordsf1=cco1=equalsquery_format=advancedbug_status=UNCONFIRMEDbug_status=CONFIRMEDbug_status=IN_PROGRESSv1=ppc%40gentoo.orgproduct=Gentoo%20Linuxlist_id=1560890 https://bugs.gentoo.org/buglist.cgi?keywords=STABLEREQ%2C%20keywords_type=allwordsf1=cco1=equalsquery_format=advancedbug_status=UNCONFIRMEDbug_status=CONFIRMEDbug_status=IN_PROGRESSv1=ia64%40gentoo.orgproduct=Gentoo%20Linuxlist_id=1560892 I don't see big queue for those arches. -- Agostino Sarubbo / ago -at- gentoo.org Gentoo Linux Developer
Re: [gentoo-dev] The status of the 'minor' arches in gentoo
On Sunday 17 February 2013 13:14:28 Alec Warner wrote: It is not clear to me why you would email the -dev list about these arches, vapier is pretty responsive over email and irc. I don't guess is a good idea have a private conversation and then drop an arch... -- Agostino Sarubbo / ago -at- gentoo.org Gentoo Linux Developer
Re: [gentoo-dev] Last time touched bugs by year
On Thursday 14 February 2013 19:19:52 Tomáš Chvátal wrote: I added the bug queries to http://qa-reports.gentoo.org/ based by year of last being touched. Take look, try to close the oldest ones/invalid ones and so on. I think it is lame we have bugs last touched in 2k5 Probably we don't need to see maintainer-wanted stuff.. -- Agostino Sarubbo / ago -at- gentoo.org Gentoo Linux Developer
[gentoo-dev] Re: [gentoo-dev-announce] please sign your manifests
On Tuesday 12 February 2013 15:14:15 William Hubbs wrote: All, as preparation for the up-coming cvs-git migration of the portage tree, the council is strongly suggesting that from this point forward all developers sign their manifests with their gpg key as described in the developer's manual [1]. If you have any questions on this, please feel free to let us know. As most of us do, I do the commit from another machine, not mine. So, for ssh 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. This is an example: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo- x86/app-portage/splat/Manifest?revision=1.45view=markup The manifest apparently is signed, but there is no really gpg sign. If someone know how to do it, please let me know. -- Agostino Sarubbo / ago -at- gentoo.org Gentoo Linux Developer
[gentoo-dev] Kernel calls gcc directly: fine?
If you try to launch make V=1 from the kernel source directory you will see: gcc -Wp,-MD,scripts/mod/.empty.o.d -nostdinc -isystem /usr/lib/gcc/x86_64- pc-linux-gnu/4.5.3/include -I/usr/src/linux-3.3.8-gentoo/arch/x86/include - Iarch/x86/include/generated -Iinclude -include /usr/src/linux-3.3.8- gentoo/include/linux/kconfig.h -D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function- declaration -Wno-format-security -fno-delete-null-pointer-checks -O2 -m64 - march=core2 -mno-red-zone -mcmodel=kernel -funit-at-a-time -maccumulate- outgoing-args -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 - DCONFIG_AS_CFI_SECTIONS=1 -DCONFIG_AS_FXSAVEQ=1 -pipe -Wno-sign-compare -fno- asynchronous-unwind-tables -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -Wframe- larger-than=2048 -fno-stack-protector -fomit-frame-pointer -Wdeclaration- after-statement -Wno-pointer-sign -fno-strict-overflow -fconserve-stack - DCC_HAVE_ASM_GOTO-DKBUILD_STR(s)=#s - DKBUILD_BASENAME=KBUILD_STR(empty) -DKBUILD_MODNAME=KBUILD_STR(empty) -c -o scripts/mod/empty.o scripts/mod/empty.c So it calls gcc directly. I see we don't like gcc called directly from the tracker[1], but this is for packages/ebuild. Should this bug block that tracker or it is invalid? [1]: https://bugs.gentoo.org/show_bug.cgi?id=cc-directly -- Agostino Sarubbo / ago -at- gentoo.org Gentoo/AMD64 Arch Security Liaison GPG: 0x7CD2DC5D signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] news item: upgrading to postfix-2.9
On Tuesday 17 July 2012 13:19:25 Eray Aslan wrote: I'd like to commit the following news item on 2012-07-21. Any comments? Imho, no need a news for it. emerge -DuN world;revdep-rebuild;dispatch-conf is what you normally do. -- Agostino Sarubbo / ago -at- gentoo.org Gentoo/AMD64 Arch Security Liaison GPG: 0x7CD2DC5D signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] euscan GSoC project - requesting feedback
On Monday 09 July 2012 23:41:06 you wrote: The main question is: what would you like to have on this dashboard? Currently (in the development version) there's the possibility to login and watch/unwatch packages/categories/herds/... and see the watched stuff in the account dashboard. We're planning on implementing a weekly(?) custom newsletter based on the packages you're watching, which features would you like? I talked with Federico on irc. I proposed to have an 'integration' between euscan and pybugz. In this manner everyone can file a version bump request via euscan. What do you think about? -- Agostino Sarubbo / ago -at- gentoo.org Gentoo/AMD64 Arch Security Liaison GPG: 0x7CD2DC5D signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] About what would be included in EAPI5
On Saturday 16 June 2012 12:55:22 Pacho Ramos wrote: Hello I would like to know if there is some place where things going to be included (or proposed to be included) for eapi5 are listed (if such place exists). Currently, looks like there is no eapi5 tracker :-/ Thanks a lot for the info :) maybe https://bugs.gentoo.org/show_bug.cgi?id=174380 ? -- Agostino Sarubboago -at- gentoo.org Gentoo/AMD64 Arch Security Liaison GPG: 0x7CD2DC5D signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Repoman check before file stable request
On Wednesday 13 June 2012 18:58:40 Jeroen Roovers wrote:
ekeyword $(ARCHES) ${EBUILD}
Saves time.
Yep, good example.
repoman manifest
repoman commit -p -m foo
Why would you commit the changes when you only intended to check
deps before filing a stabilisation request?
-p will not commit anything. You can see only what happens if you go ahead
without -p.
Anyway, the idea is: check the other(s) ~arch depend(s) before file stable
request in any method that you prefer.
--
Agostino Sarubboago -at- gentoo.org
Gentoo/AMD64 Arch Security Liaison
GPG: 0x7CD2DC5D
signature.asc
Description: This is a digitally signed message part.
[gentoo-dev] Repoman check before file stable request
Hello folks, would be great if everyone runs repoman before file the stable request. In particular, many times, happens that are required other ~arch packages, so a small check like this, should be enough: for i in x86 amd64 hppa $and_other_arches ;do ekeyword $i $ebuild;done repoman manifest repoman commit -p -m foo In this manner we will save a lot of time for us. Thanks in advance. -- Agostino Sarubboago -at- gentoo.org Gentoo/AMD64 Arch Security Liaison GPG: 0x7CD2DC5D signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Repoman check before file stable request
On Monday 11 June 2012 15:42:25 Agostino Sarubbo wrote: In this manner we will save a lot of time for us. Thanks in advance. s/we/you Anyway, from irc, seems is not very 'clear' what I meant. I suggested to run repoman to see if are required more packages instead of what you think is necessary; then, you are able to include the other packages in your stablereq, or open a new bug and make as a block. -- Agostino Sarubboago -at- gentoo.org Gentoo/AMD64 Arch Security Liaison GPG: 0x7CD2DC5D signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: Enable FEATURES=userpriv usersandbox by default?
On Monday 28 May 2012 14:34:22 Zac Medico wrote: Hi, In case you aren't familiar with FEATURES=userpriv, here's the description from the make.conf(5) man page: Allow portage to drop root privileges and compile packages as portage:portage without a sandbox (unless usersandbox is also used). The rationale for having the separate usersandbox setting, to enable use of sys-apps/sandbox, is that people who enable userpriv sometimes prefer to have sandbox disabled in order to slightly improve performance. However, I would recommend to enable usersandbox by default, for the purpose of logging sandbox violations. Note that ebuilds can set RESTRICT=userpriv if they require superuser privileges during any of the src_* phases that userpriv affects. I've been using FEATURES=userpriv usersandbox for years, and I don't remember experiencing any problems because of it, so I think that it would be reasonable to have it enabled by default. Objections? I'm using usersync since a long time, how about add it too? -- Agostino Sarubboago -at- gentoo.org Gentoo/AMD64 Arch Security Liaison GPG: 0x7CD2DC5D signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: new global USE flag: jit
On Monday 14 May 2012 14:05:12 Alexandre Rostovtsev wrote: I propose adding the following global USE flag: jit - Enable just-in-time compilation for improved performance. May prevent use of some PaX memory protection features in Gentoo Hardened. Current local flags that could probably be unified: app-arch/libzpaq:jit - Enable just-in-time compilation for faster compression (requires SSE2) dev-libs/libpcre:jit - Enable Just-In-Time compilation of regexp bytecode to machine code, through the SLJIT compiler. This feature might conflict wtih security mitigation strategies such as NX/PaX as enabled by Gentoo Hardened. dev-python/pypy:jit - Enable the JIT compiler dev-scheme/racket:jit - Enable just-in-time compiler media-sound/csound:luajit - Use the lua just-in-time compiler dev-lang/luajit instead of dev-lang/lua net-libs/webkit-gtk:jit - Enable JIT javascript compiler (disabling it will cause performance penalty) www-client/epiphany:jit - Allow using net-libs/webkit-gtk that has the JIT javascript compiler enabled www-client/luakit:luajit - Use the lua just-in-time compiler dev-lang/luajit instead of dev-lang/lua, which should make luakit faster. www-client/seamonkey:methodjit - Enable JIT for JavaScript using MethodJIT for faster JS performance. Hardened users can disable this USE-flag to use MPROTECT on grsecurity kernels. www-servers/nginx:pcre-jit - Enable JIT for pcre x11-libs/qt-core:jit - Enables JIT for Javascript usage inside Qt x11-libs/qt-script:jit - Enables JIT for Javascript usage inside Qt x11-libs/qt-webkit:jit - Enable JavaScriptCore just-in-time compiler for faster JavaScript execution -Alexandre. +1 -- Agostino Sarubboago -at- gentoo.org Gentoo/AMD64 Arch Security Liaison GPG: 0x7CD2DC5D signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Testing request for =sys-apps/dbus-1.5.12 and =dev-python/dbus-python-1.1.0 before entering ~arch
On Friday 11 May 2012 17:56:27 Samuli Suominen wrote: I'm planning on shipping these in ~arch. Give it a try and report in case of problems. Thanks, Samuli Will be done for amd64 in the next days ;) -- Agostino Sarubboago -at- gentoo.org Gentoo/AMD64 Arch Security Liaison GPG: 0x7CD2DC5D signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] About dropping webapps-unmaintained alias
On Saturday 21 April 2012 12:51:53 Pacho Ramos wrote: It's simply pointing to maintainer-needed and no bug is assigned to it. If a webapp package is orphan, it should go to maintainer-needed directly I think The same for webapps-request, that is a link to maintainer-wanted Thanks :) +1 -- Agostino Sarubboago -at- gentoo.org Gentoo/AMD64 Arch Security Liaison GPG: 0x7CD2DC5D signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Is gcc-4.7.0 going to be in portage tree anytime soon?
On Tuesday 17 April 2012 15:36:51 kabel wrote: Hello there, I just wanted to ask when an ebuild for gcc-4.7.0 will be in portage tree (unkeyworded, I suppose, like 4.6.0-4.6.2 are). Thank you. You can just follow the version bump request: https://bugs.gentoo.org/show_bug.cgi?id=409315 -- Agostino Sarubboago -at- gentoo.org Gentoo/AMD64 Arch Security Liaison GPG: 0x7CD2DC5D signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] glibc-2.14 for stable
On Tuesday 10 April 2012 15:35:39 Mike Frysinger wrote: there's one known bug (with a patch posted), so if you guys have anything that'd block glibc-2.14 for stable, nows' the time to file the bugs (and mark it a blocker of 370409). -mike I'd say to proceed directly in 393477 -- Agostino Sarubboago -at- gentoo.org Gentoo/AMD64 Arch Security Liaison GPG: 0x7CD2DC5D signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] glibc-2.14 for stable
On Tuesday 10 April 2012 15:51:33 Mike Frysinger wrote: not really sure what you're referring to here. that bug is already fixed in latest glibc-2.14 ebuild. I mean, no need to open a new bug, just continue in that security bug, because the fixed version has never had stable keyword. -- Agostino Sarubboago -at- gentoo.org Gentoo/AMD64 Arch Security Liaison GPG: 0x7CD2DC5D signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Can we get PIE on all SUID binaries by default, por favor?
On Monday 23 January 2012 15:00:41 Mike Gilbert wrote: I'm asking how does one enable PIE/ASLR, not how to check if it is enabled already. Just enable hardened profile that compiles generally with: -fno-strict-overflow -fPIE -fstack-protector-all in particular with gcc-hardenednossp you have: fno-strict-overflow -fPIE with gcc-hardenednopie you have: fno-strict-overflow -fstack-protector-all with gcc-hardenednopiessp you have: -fno-strict-overflow -- Agostino Sarubboago -at- gentoo.org Gentoo/AMD64 Arch Security Liaison GPG: 0x7CD2DC5D signature.asc Description: This is a digitally signed message part.
[gentoo-dev] How help in arch testing work
This mail is come from my long time experience about testing.
So, everytime, I must suggest the same things and I can say that at some point
it gets boring.
I appreciate the work of all, but I must say that some people pay little
attention to stablereq bugs, so this mail wants to be a short reminder of what
could decrease our work.
1) There is a discussion[1] about it, but for the moment, a stablereq should
be keywording and stabilization and enhancement importance.
If you need to accelerate the stabilization please set high and not from
enhancement to critical and so on.
Don't forget STABLEREQ keyword or the bug will not appears in our list.
2) _Before_ filing a request, please run repoman full, to be sure that there
is nothing to fix, then take a look at the ebuild and make sure your ebuild
have a minimum of QA; all external binary called in the ebuild(sed, mv, cp,
ln, rm, and so on) should have 'die'; if you don't use EAPI4, make sure that
all portage helper[2] have also '|| die'.
3) Check your rdepend, where is possible with scanelf[3] and if you declare
it, please, as you said, exclude gcc/glibc and all package from @system
4) Nobody knows how work all packages in tree, so there are obvious packages
like a browsers, IM, audio player,that is easy decide if is ok or not, but
there are also packages that an Arch tester has never seen, so is a lack of
time everytime google about it or ask to maintainer, so, please specify what
test you want for this package; e.g.
-only compile test
-compile test and make sure src_test goes well
-make sure /usr/bin/${foo} works properly in ${that} manner
-see 5) about library
So, you can write one time 'how to' and copy/paste for the future stablereq; I
guess I'm not asking a long and difficult task.
5) If is a library, obviously, we can try to rebuild stable RDEPENDS in tree
and an easy way to check the list of rdepend is asking our bot:
!rdep ${package}
Unfortunately it prints a complete list of RDEPEND(stable+testing), and is a
lack of time checking manually what is the list of stable packages.
So you can lighten our work in 2 ways:
a) Please rebuild the following list of rdepends.( if no need to rebuild all
because maintainer already do it)
b) Please rebuild all rdepends.
So, unfortunately, I don't know a rapid way to have only a stable list of
packages, so if really there isn't it, is very very appreciated print the list
of packages that needs rebuild
Sorry in advance if there is and I'm ignoring it, please tell me.
I want to point out that this is not a polemic, but is a way to suggest what
you can do for arch teams to increase the quality of teamwork and do not waste
precious time.
[1]: https://bugs.gentoo.org/show_bug.cgi?id=381627
[2]: qlist -e portage | grep ebuild-helpers
[3]: amd64box ~ # cat /usr/local/bin/scan
#!/bin/bash
qlist -e $@ | xargs scanelf -L -n -q -F '%n #F' | tr , ' ' | xargs qfile -Cv
| sort -u | awk '{print $1}' | uniq
--
Agostino Sarubboago -at- gentoo.org
Gentoo/AMD64 Arch Security Liaison
GPG: 0x7CD2DC5D
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] How help in arch testing work
On Wednesday 18 January 2012 11:55:30 Alexis Ballier wrote: 3) Check your rdepend, where is possible with scanelf[3] and if you declare it, please, as you said, exclude gcc/glibc and all package from @system imho this has nothing to do with stabilization There is a misunderstading about it. I did not mean what the other sayd. So, if is not clear, the goal should be: check your RDEPEND before filing stabilization. Stop what i dislike in this approach is that arch testers will follow a test plan which the maintainer has obviously tested before and knows it works. sending people into the jungle of 'try to do something with $pkg' may make them encounter problems the maintainer hadnt thought about. I think the same, but just for your info, there are, imho, few people that works in popular arches like x86/amd64 and is not possible because of missing of 'tester', imagine in arches like sparc/ia64 where only people like armin76 works =) -- Agostino Sarubboago -at- gentoo.org Gentoo/AMD64 Arch Security Liaison GPG: 0x7CD2DC5D signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] making the stable tree more up-to-date
On Friday 16 December 2011 11:42:15 justin wrote: Hi, I really like that you open all those bugs. But it makes no sense to add arches after a time out. Personally, I agree with have more stable packages in tree, but I just point out one thing. If me, or another arch tester find ebuild issue(s) and maintainers does not care of it, makes no sense imho. I mark stable with a script and I'm uncomfortable to fix them. As Justin said, all maintainers are responsible of their packages, so I'd prefer to not touch other stuff. If you(for any developers) are busy and/or you can't fix them, feel free to mail me or just give an ack via irc and I'll provide to fix. Regards Agostino signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] making the stable tree more up-to-date
On Friday 16 December 2011 06:10:13 Anthony G. Basile wrote: Does your script do any checking on the quality of the ebuild, eg that it respects C/LDFLAGS. If so, that's useful and would help package maintainers to better prepare their ebuilds for stabilization. Unfortunately no. For LDFLAGS there is a QA warning and is enough visible For CFLAGS I see with the naked eye a bit of build log My script at end of work just runs repoman full and cat entire ebuild( so, imho, should be a tasks already done by maintainers). Finally, I take a look at the ebuild to see if there are issue(s) This is all. And congrats on making dev Thanks ;) Regards Agostino signature.asc Description: This is a digitally signed message part.
