Re : Re: [gentoo-portage-dev] Constraint-Based Dependency Solver for Portage: a prototype
Dear Alexander, Many thanks for your reply and your encouragements. The point that you raised is very interesting and was partially done in Debian (they defined a wrapper around apt-get instead of refactoring it): http://manpages.ubuntu.com/manpages/zesty/man8/apt-cudf-get.8.html Part of their work was formalized in coq and implemented in OCaml. In our case, we don't have any mechanized formalization of our model (maybe in the future). I too (and my colleagues) hope that someone on the team could have some time to look into our project. But maybe there are things we can do to help start a dialog, like: - reaching in other mailing lists - posting on a Gentoo forum - participating in a workshop/conference/other where we could directly meet and discuss with the community - or simply starting an informal discussion by email where instead of having to look into the Github repository, you could directly ask me Does anyone have suggestions on that topic? Again, many thanks. I really hope that with everyone's feedback, suggestions, and help, we could make something useful from this prototype. Michael Lienhardt PS: I forgot in my previous mail to talk about the other persons involved in this project: - Jacopo Mauro, Post-doc in UiO (Norway), developer of the solver backend - Simone Donetti, Engineer in Unito (Italy), he helped me perform some tests - Ferruccio Damiani (Unito), Einar Broch Johnsen and Ingrid Chieh Yu (UiO), our supervisors
Re: [gentoo-dev] AMD64 Arch Testers needed urgently
On Tue, Dec 12, 2017 at 12:24 PM, Rich Freemanwrote: > On Tue, Dec 12, 2017 at 1:15 PM, Michał Górny wrote: >> >> It seems that we've started lacking arch testers for AMD64 architecture. >> At this moment, there are already 159 bugs in amd64 backlog, and there >> is no noticeable progress. New stabilization requests are usually >> handled much faster by x86, sparc and hppa teams! >> >> If you have a stable AMD64 system and would like to help arch testing, >> please do! I don't know what exact rules for that are but I think [1] >> could be helpful. If someone knows better, then please share. >> > > As far as I'm aware the standing policy already exists that > maintainers can stabilize their own packages on amd64. > > That said, if somebody wants to organize an AT program for amd64 they > should feel free to do so. I could explain how things used to work at > least if that is helpful. > > The old way it used to work is that ATs had to pass the ebuild quiz > and they would get editbugs privs to tag bugs as tested. I won't > elaborate here unless there is interest... > I would like to know. But on the other hand, anyone interested in contributing to packages they work with is likely already doing so. On the third (and final?) hand, it may also be that there are people looking for direction. Cheers, R0b0t1
Re: [gentoo-dev] AMD64 Arch Testers needed urgently
On 12/12/2017 19:24, Rich Freeman wrote: > On Tue, Dec 12, 2017 at 1:15 PM, Michał Górnywrote: >> It seems that we've started lacking arch testers for AMD64 architecture. >> At this moment, there are already 159 bugs in amd64 backlog, and there >> is no noticeable progress. New stabilization requests are usually >> handled much faster by x86, sparc and hppa teams! >> >> If you have a stable AMD64 system and would like to help arch testing, >> please do! I don't know what exact rules for that are but I think [1] >> could be helpful. If someone knows better, then please share. >> > As far as I'm aware the standing policy already exists that > maintainers can stabilize their own packages on amd64. It would be interesting to discuss if proxy maintainers should be able to stabilize too. > > That said, if somebody wants to organize an AT program for amd64 they > should feel free to do so. I could explain how things used to work at > least if that is helpful. > > The old way it used to work is that ATs had to pass the ebuild quiz > and they would get editbugs privs to tag bugs as tested. I won't > elaborate here unless there is interest... >
[gentoo-dev] Last-rites: media-sound/amarok and remaining deps, media-sound/vdramgw
# Andreas Sturmlechner(12 Dec 2017) # Depends on dead kdelibs4/qt4, unmaintained upstream. No port to # KF5 released. If you depend on this package, please help test KF5-based # amarok- in KDE ebuild repository to decide on a possible snapshot. # Possible alternatives are media-sound/cantata (an awesome mpd client), # media-sound/clementine and media-sound/tomahawk (the latter also declared # unmaintained upstream). # Bug #635468. Masked for removal in 30 days. media-sound/amarok kde-apps/kdebase-kioslaves kde-apps/phonon-kde x11-libs/qtscriptgenerator # Andreas Sturmlechner (12 Dec 2017) # Depends on dead media-sound/amarok:4, dead upstream, # last release in 2006. Bug #635468. Masked for removal in 30 days. media-sound/vdramgw
[gentoo-dev] Last-rites: sci-electronics/cirkuit
# Andreas Sturmlechner(12 Dec 2017) # Depends on dead kdelibs4/qt4, unmaintained upstream. No port to # KF5 released. If you depend on this package, please help test KF5-based # cirkuit- in KDE ebuild repository to decide on a possible snapshot. # Bug #640884. Masked for removal in 30 days. sci-electronics/cirkuit
[gentoo-dev] Last-rites: app-accessibility/simon
# Andreas Sturmlechner(12 Dec 2017) # Depends on dead kdelibs4/qt4, no port to KF5 released yet. # If you depend on this package, help test KF5-based simon- # to decide on a possible snapshot. Bugs #640846, 639960, 635816. # Masked for removal in 30 days. app-accessibility/simon:4
[gentoo-dev] Packages up for grabs
The following packages are in need of a maintainer: dev-util/astyle net-im/toxic x11-misc/alock x11-misc/ktsuss x11-misc/spacefm -- Daniel Campbell OpenPGP Fingerprint: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 Found on hkp://keys.gnupg.net and other keyservers signature.asc Description: Digital signature
Re: [gentoo-dev] AMD64 Arch Testers needed urgently
On Tue, Dec 12, 2017 at 1:15 PM, Michał Górnywrote: > > It seems that we've started lacking arch testers for AMD64 architecture. > At this moment, there are already 159 bugs in amd64 backlog, and there > is no noticeable progress. New stabilization requests are usually > handled much faster by x86, sparc and hppa teams! > > If you have a stable AMD64 system and would like to help arch testing, > please do! I don't know what exact rules for that are but I think [1] > could be helpful. If someone knows better, then please share. > As far as I'm aware the standing policy already exists that maintainers can stabilize their own packages on amd64. That said, if somebody wants to organize an AT program for amd64 they should feel free to do so. I could explain how things used to work at least if that is helpful. The old way it used to work is that ATs had to pass the ebuild quiz and they would get editbugs privs to tag bugs as tested. I won't elaborate here unless there is interest... -- Rich
[gentoo-dev] AMD64 Arch Testers needed urgently
Hi, everyone. It seems that we've started lacking arch testers for AMD64 architecture. At this moment, there are already 159 bugs in amd64 backlog, and there is no noticeable progress. New stabilization requests are usually handled much faster by x86, sparc and hppa teams! If you have a stable AMD64 system and would like to help arch testing, please do! I don't know what exact rules for that are but I think [1] could be helpful. If someone knows better, then please share. [1]:https://wiki.gentoo.org/wiki/Project:AMD64_Arch_Testers -- Best regards, Michał Górny
[gentoo-dev] Please update Manifest hashes for your fetch-restricted packages
Hi, everyone. FYI, we (me, ulm, floppym) have updated Manifest hashes for almost all Gentoo packages. What's left are fetch-restricted packages. If you maintain such a package, please look into updating its Manifest. Also, in many cases fetch-restricted packages can be actually fetched by users with a little effort. If you'd like to help, you can try fetching them and committing the change and/or submitting a pull request or git patch. If you're fetching files, please make sure to verify their original checksums via running 'ebuild ... unpack' or likewise. Or at least make sure that SHA512 is not changing ('git diff --word-diff' is helpful for that). The packages needing checksum update are listed as staging warnings (yellow) on gentoo-ci: https://qa-reports.gentoo.org/output/gentoo-ci/output.html I will start filing bugs once the number of packages left decreases or we get closer to the deadline. -- Best regards, Michał Górny