[gentoo-dev] Python 2 cleanup: remaining packages, Nov 2020 update
Hi, Here's an update on where we're standing right now. Including only non- masked packages. Waiting for stabilization of py3/no-py version: - kde-apps/kross-interpreters Waiting for cleanup of old (non-trivial!): - dev-db/mongodb - dev-db/percona-server - media-tv/kodi - media-tv/mythtv - x11-plugins/enigmail Build-time deps, to stay for the time being: - dev-lang/spidermonkey - dev-python/pypy* - dev-qt/qtwebengine - games-strategy/0ad - www-client/chromium Waiting for py3 port (likely last rite candidates): - games-engines/renpy Dependencies of other packages on the list: - dev-python/cheetah (dev-db/mongodb) - dev-python/numpy-python2 (games-engines/renpy) - dev-python/typing (dev-db/mongodb) -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] tagging eclasses with allowed transitive inherits
On Sat, 2020-11-07 at 15:18 -0700, Tim Harder wrote: > In terms of QA, unintentional transitive eclass usage is generally bad. > This occurs when an ebuild uses functionality from an eclass it doesn't > directly inherit. It would be useful for eclasses that allow certain > transitive usage (e.g. various python eclasses) to be able to tag that > relationship internally so tools can make use of that data. > > Along those lines, pkgcheck now has eclass doc parsing support which > allows scanning ebuilds for missing, indirect, or unused eclass inherits > as well as internal eclass function usage. In order to more closely > report valid indirect inherit results, some tag including this data > needs to be included for eclasses allowing this relationship. > > What do interested parties think about including an optional eclass doc > tag such as '@TRANSITIVE_INHERITS:' or other similar name in eclasses > that allow this? The tag value would be a space-separated list of > allowed transitive inherits for the given eclass. > Technically speaking, I would go even further and say that listing python-utils-r1 redundantly is wrong. This inheritance is considered an implementation detail of the eclass. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] tagging eclasses with allowed transitive inherits
In terms of QA, unintentional transitive eclass usage is generally bad. This occurs when an ebuild uses functionality from an eclass it doesn't directly inherit. It would be useful for eclasses that allow certain transitive usage (e.g. various python eclasses) to be able to tag that relationship internally so tools can make use of that data. Along those lines, pkgcheck now has eclass doc parsing support which allows scanning ebuilds for missing, indirect, or unused eclass inherits as well as internal eclass function usage. In order to more closely report valid indirect inherit results, some tag including this data needs to be included for eclasses allowing this relationship. What do interested parties think about including an optional eclass doc tag such as '@TRANSITIVE_INHERITS:' or other similar name in eclasses that allow this? The tag value would be a space-separated list of allowed transitive inherits for the given eclass. Tim
Re: [gentoo-dev] Packages & projects up for grabs due to jer's retirement
On Tue, Nov 03, 2020 at 10:32:11PM +0100, Michał Górny wrote: > net-libs/nodejs I'll take this one for now. William signature.asc Description: PGP signature
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
Hi, On 2020-11-07 12:30, Agostino Sarubbo wrote: 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. 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. 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. but the majority are fixed so in my opinion they were useful 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... -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?
07.11.2020 14:39, Andreas K. Huettel пишет: > > > On November 7, 2020 1:42:44 PM GMT+02:00, Alexey Sokolov > wrote: >> 22.10.2020 20:16, Andreas K. Hüttel пишет: >>> Am Donnerstag, 22. Oktober 2020, 18:44:48 EEST schrieb Michał Górny: On Thu, 2020-10-22 at 11:17 -0400, Brian Evans wrote: > Users frequently are choosing the wrong profile versions in new >> installs > and accidentally downgrading to 17.0 with some saying they see it >> first. > > A simple reordering could help new installs. >>> >>> Independent of this useful change, it's probably time to deprecate >> the amd64 >>> 17.0 profiles! >>> >> >> Prefix bootstrap script still makes new installations to use it > > Meh. Time to change that then... > Nah, Fabian has just fixed it (in another reply to my message in this thread) -- Best regards, Alexey "DarthGandalf" Sokolov
Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?
On November 7, 2020 1:42:44 PM GMT+02:00, Alexey Sokolov wrote: >22.10.2020 20:16, Andreas K. Hüttel пишет: >> Am Donnerstag, 22. Oktober 2020, 18:44:48 EEST schrieb Michał Górny: >>> On Thu, 2020-10-22 at 11:17 -0400, Brian Evans wrote: Users frequently are choosing the wrong profile versions in new >installs and accidentally downgrading to 17.0 with some saying they see it >first. A simple reordering could help new installs. >> >> Independent of this useful change, it's probably time to deprecate >the amd64 >> 17.0 profiles! >> > >Prefix bootstrap script still makes new installations to use it Meh. Time to change that then... -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-dev] LiveCD Project disbanding: packages up for grabs
>dev-util/dialog >sys-block/parted Im going to add base-system to these two later (in addition to dedicated maintainers) -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?
On 07-11-2020 11:42:44 +, Alexey Sokolov wrote: > 22.10.2020 20:16, Andreas K. Hüttel пишет: > > Am Donnerstag, 22. Oktober 2020, 18:44:48 EEST schrieb Michał Górny: > >> On Thu, 2020-10-22 at 11:17 -0400, Brian Evans wrote: > >>> Users frequently are choosing the wrong profile versions in new installs > >>> and accidentally downgrading to 17.0 with some saying they see it first. > >>> > >>> A simple reordering could help new installs. > > > > Independent of this useful change, it's probably time to deprecate the > > amd64 > > 17.0 profiles! > > > > Prefix bootstrap script still makes new installations to use it This should be solved with b0445c0a8dd6d2f792c5bb088b154aca53868353 a9c478dc881ee18fefc7342da994b00e60eaad8e on gentoo.git and 0d7f6b6eb00d0f51f35019846b8f79048b30be93 on prefix.git. Thanks, Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?
22.10.2020 20:16, Andreas K. Hüttel пишет: > Am Donnerstag, 22. Oktober 2020, 18:44:48 EEST schrieb Michał Górny: >> On Thu, 2020-10-22 at 11:17 -0400, Brian Evans wrote: >>> Users frequently are choosing the wrong profile versions in new installs >>> and accidentally downgrading to 17.0 with some saying they see it first. >>> >>> A simple reordering could help new installs. > > Independent of this useful change, it's probably time to deprecate the amd64 > 17.0 profiles! > Prefix bootstrap script still makes new installations to use it -- Best regards, Alexey "DarthGandalf" Sokolov
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
Am Samstag, 7. November 2020, 10:26:27 EET schrieb Agostino Sarubbo: > 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. Ago, this whole thread started out about the quality of the bug reports. However... Seriously, with the insistence to keep your setup closed-source, you are not helping your case. If you want this to be an in any way official Gentoo project, you'll have to stick to the Gentoo social contract just like everyone else. Cheers, Andreas -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
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
[gentoo-dev] Last rites: sys-cluster/cluster-glue, sys-cluster/crmsh, sys-cluster/pacemaker, sys-cluster/resource-agents
# Michał Górny (2020-11-07) # sys-cluster/cluster-glue fails to install for almost a year now. # The remaining packages are its reverse dependencies. # # The stable version of sys-cluster/pacemaker is vulnerable. It is also # using Python 2. A newer version can not be stabilized because # of the above. # # Removal in 30 days. Bug #704610. sys-cluster/cluster-glue sys-cluster/crmsh sys-cluster/pacemaker sys-cluster/resource-agents -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
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] LiveCD Project disbanding: packages up for grabs
On Wed, 2020-11-04 at 16:09 -0500, Matt Turner wrote: > dev-python/pyparted > sys-block/parted > sys-fs/squashfs-tools > I can take these three. I see that dev-python/pyparted has working tests which is surprisingly nice. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
