Re: [gentoo-dev] AMD64 Arch Testers needed urgently

[Kent Fredric]

On Wed, 13 Dec 2017 21:58:05 +0100
Thomas Deutschmann  wrote:

> b) Because not all devs care about stable Gentoo, I would recommend
> auto-stabilization: I.e. if a package is in the repository for x days
> build bot would try to build the package and mark the package stable
> if everything passes. If for some reason maintainer want to block a
> specific version they could create a bug or set a flag in an already
> existing bug which will cause build bot to ignore this version.

Slightly modified suggestion:

Add a flag called "autostabilize" with [unset], [y], [n]

Default is 'unset', and if found unset after a given time, it flips to
y and the stable bot gets queued up.

If its set to 'n', then stable bot never does anything.

This way maintainers who want to rush the stablebot on things they
consider "safe" can get ahead of the queue.


[nb: unsigned mail, pinentry currently broken due to -fPIC profile
migration]

Re: [gentoo-dev] javaws always use icedtea

[James Le Cuirot]

On Wed, 13 Dec 2017 22:25:51 +
Samuel Bernardo  wrote:

> I'm using oracle jdk as default jvm, but when I review java-config
> result after setting oracle-jdk-bin as prefered jvm, javaws continues to
> start icedtea version.

Disable the webstart flag against icedtea(-bin) and unmerge
dev-java/icedtea-web. Job done. This used to be configurable through
eselect but it was really overcomplicated for no benefit. This is all
documented here and shown when you install icedtea-web the first time.

https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-java/icedtea-web/files/README.gentoo-r1

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpSfsyNWBm6Q.pgp
Description: OpenPGP digital signature

[gentoo-dev] javaws always use icedtea

[Samuel Bernardo]

Hello,

I'm using oracle jdk as default jvm, but when I review java-config
result after setting oracle-jdk-bin as prefered jvm, javaws continues to
start icedtea version.

Analysing the script /usr/libexec/eselect-java/run-java-tool.bash I
realised that itweb-javaws is hardcoded:

> if [ "${tool}" = "javaws" ] && [ -x "/usr/bin/itweb-javaws" ]; then 
>         exec "/usr/bin/itweb-javaws" "${@}" 
> fi 

Shouldn't this also change when java-config defines new predefined jvm?

Thanks for any clarification about this implementation in the mentioned
script.
The ebuild that installs the script is app-eselect/eselect-java and I
would like to change this script to also set javaws when predefining jvm.

I also published this message in the gentoo forum:

https://forums.gentoo.org/viewtopic-t-1073738.html

Best,

Samuel

Re: [gentoo-dev] AMD64 Arch Testers needed urgently

[Thomas Deutschmann]

On 2017-12-13 18:51, William Hubbs wrote:
> In theory, this is correct. However, when maintainers don't stabilize
> packages and no one else does either, our stable tree suffers.

I agree but we have to pay attention that we don't stabilize packages at
all costs because otherwise they would never go stable.

If this is the problem then we should discuss stabilization at all. What
do people expect from something marked stable vs. reality. ;)

And in this case I would prefer a system like Debian SID -> Testing
supported by build bots. I can think of 2 variants:

a) Once maintainer files a stabilization request, a build bot will pick
up the bug and try building the package in a chroot per architecture. If
everything passes build bot will mark the version stable for the tested
architecture.

A flag or a blacklist could prevent build bot stabilization.


b) Because not all devs care about stable Gentoo, I would recommend
auto-stabilization: I.e. if a package is in the repository for x days
build bot would try to build the package and mark the package stable if
everything passes. If for some reason maintainer want to block a
specific version they could create a bug or set a flag in an already
existing bug which will cause build bot to ignore this version.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] AMD64 Arch Testers needed urgently

[Lucas Ramage]

I see, well I can setup buildbot to do that. Is there some place in
particular that I should send my test results?

On Wed, Dec 13, 2017 at 1:28 PM, Aaron W. Swenson 
wrote:

> On 2017-12-13 13:20, Lucas Ramage wrote:
> > > In  my discussions with other developers, I've found that this is the
> > ​> ​
> > biggest concern. Most devs are runnning ~amd64, so they don't feel that
> > ​> ​
> > they can mark things stable.
> >
> > W
> > ​hat about running a stable chroot?​ Are there any tools that can be used
> > to automate this process?
>
> Yes, a stable chroot is okay, and there is app-portage/tatt that can run
> through the various USE flag combinations for you.
>
> It’s output isn’t terribly helpful, so it takes a little while to
> understand what it’s trying to tell you.
>



-- 
Regards,

[image: Visit online journal] 

*Lucas Ramage* / Software Engineer
ramage.lu...@openmailbox.org / (941) 404-6794

*PGP Fingerprint* / Learn More 
EAE7 45DF 818D 4948 DDA7 0F44 F52A 5A96 7B9B 6FB7


*Visit online journal*
http://lramage94.github.io 

[image: Github]  [image: Linkedin]

Re: [gentoo-dev] AMD64 Arch Testers needed urgently

[Aaron W. Swenson]

On 2017-12-13 13:20, Lucas Ramage wrote:
> > In  my discussions with other developers, I've found that this is the
> ​> ​
> biggest concern. Most devs are runnning ~amd64, so they don't feel that
> ​> ​
> they can mark things stable.
> 
> W
> ​hat about running a stable chroot?​ Are there any tools that can be used
> to automate this process?

Yes, a stable chroot is okay, and there is app-portage/tatt that can run
through the various USE flag combinations for you.

It’s output isn’t terribly helpful, so it takes a little while to
understand what it’s trying to tell you.


signature.asc
Description: Digital signature

Re: [gentoo-dev] AMD64 Arch Testers needed urgently

[Lucas Ramage]

> In  my discussions with other developers, I've found that this is the
​> ​
biggest concern. Most devs are runnning ~amd64, so they don't feel that
​> ​
they can mark things stable.

W
​hat about running a stable chroot?​ Are there any tools that can be used
to automate this process?

On Wed, Dec 13, 2017 at 12:51 PM, William Hubbs  wrote:

> On Wed, Dec 13, 2017 at 01:22:04PM +0100, Thomas Deutschmann wrote:
> > On 2017-12-12 19:24, Rich Freeman wrote:
> > > As far as I'm aware the standing policy already exists that
> > > maintainers can stabilize their own packages on amd64.
> >
> > That's right but keep in mind that nevertheless you need a stable
> > system. Marking a package stable because it works on your ~arch box you
> > use for your daily dev work would lead the whole process ad absurdum.
>
> In  my discussions with other developers, I've found that this is the
> biggest concern. Most devs are runnning ~amd64, so they don't feel that
> they can mark things stable.
>
> > And in general maintainer stabilization should be the last resort. The
> > person who wrote the ebuild maybe doesn't notice that the ebuild is
> > doing something wrong (doesn't honor CFLAGS, calls compiler directly,
> > not working with /bin/sh not /bin/bash ...).
>
> In theory, this is correct. However, when maintainers don't stabilize
> packages and no one else does either, our stable tree suffers.
>
> William
>



-- 
Regards,

[image: Visit online journal] 

*Lucas Ramage* / Software Engineer
ramage.lu...@openmailbox.org / (941) 404-6794

*PGP Fingerprint* / Learn More 
EAE7 45DF 818D 4948 DDA7 0F44 F52A 5A96 7B9B 6FB7


*Visit online journal*
http://lramage94.github.io 

[image: Github]  [image: Linkedin]

Re: [gentoo-dev] AMD64 Arch Testers needed urgently

[William Hubbs]

On Wed, Dec 13, 2017 at 01:22:04PM +0100, Thomas Deutschmann wrote:
> On 2017-12-12 19:24, Rich Freeman wrote:
> > As far as I'm aware the standing policy already exists that
> > maintainers can stabilize their own packages on amd64.
> 
> That's right but keep in mind that nevertheless you need a stable
> system. Marking a package stable because it works on your ~arch box you
> use for your daily dev work would lead the whole process ad absurdum.

In  my discussions with other developers, I've found that this is the
biggest concern. Most devs are runnning ~amd64, so they don't feel that
they can mark things stable.

> And in general maintainer stabilization should be the last resort. The
> person who wrote the ebuild maybe doesn't notice that the ebuild is
> doing something wrong (doesn't honor CFLAGS, calls compiler directly,
> not working with /bin/sh not /bin/bash ...).

In theory, this is correct. However, when maintainers don't stabilize
packages and no one else does either, our stable tree suffers.

William


signature.asc
Description: Digital signature

Re: [gentoo-dev] Packages up for grabs

[Jonas Stein]

Hi Thomas,

> I've been interested in getting more involved with Gentoo - would
> package maintenance be a good place to start?

You can fix bugs for many packages, but you should only assign your self
to a package, if you want to take care for bug reports in a long term.
I suggest to make small fixes and pull requests first and get familiar
with repoman + git first.


> I'd be interested in astyle and alock as these are tools I would use
> myself. Do I just start by reading
> https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers and try to get
> in touch with the right people?

That is a good start. There are many new informative links.
You can join us on IRC and tell us what you already can do, what your
interests are. We will have lists with things to do in all flavors and
difficulties. You may ping me on IRC, my nick is jstein.

-- 
Best,
Jonas



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] AMD64 Arch Testers needed urgently

[Thomas Deutschmann]

On 2017-12-12 19:24, Rich Freeman wrote:
> As far as I'm aware the standing policy already exists that
> maintainers can stabilize their own packages on amd64.

That's right but keep in mind that nevertheless you need a stable
system. Marking a package stable because it works on your ~arch box you
use for your daily dev work would lead the whole process ad absurdum.

And in general maintainer stabilization should be the last resort. The
person who wrote the ebuild maybe doesn't notice that the ebuild is
doing something wrong (doesn't honor CFLAGS, calls compiler directly,
not working with /bin/sh not /bin/bash ...).


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Packages up for grabs

[Thomas Bracht Laumann Jespersen]

On 12 December 2017 at 22:46, Daniel Campbell  wrote:
>
> The following packages are in need of a maintainer:
>
> dev-util/astyle
> net-im/toxic
> x11-misc/alock
> x11-misc/ktsuss
> x11-misc/spacefm

Hi!

I've been interested in getting more involved with Gentoo - would
package maintenance be a good place to start?

I'd be interested in astyle and alock as these are tools I would use
myself. Do I just start by reading
https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers and try to get
in touch with the right people?

It seems like alock's site is broken:
http://darkshed.net/projects/alock (I'm seeing an error connecting to
mysql)

-- Thomas
> --
> Daniel Campbell
> OpenPGP Fingerprint: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
> Found on hkp://keys.gnupg.net and other keyservers