Re : Re: [gentoo-portage-dev] Constraint-Based Dependency Solver for Portage: a prototype

[michael . lienhardt]

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

[R0b0t1]

On Tue, Dec 12, 2017 at 12:24 PM, Rich Freeman  wrote:
> 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

[Francesco Riosa]

On 12/12/2017 19:24, Rich Freeman wrote:
> 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.

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]

# 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]

# 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]

# 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

[Daniel Campbell]

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

[Rich Freeman]

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...

-- 
Rich

[gentoo-dev] AMD64 Arch Testers needed urgently

[Michał Górny]

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

[Michał Górny]

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