After a long time upstream provided a release candidate of the new 0.0.8 version. It contains a lot of bug fixes and minor enhancements. SRC_URI and Homepage has also changed in last years. See attached ebuild which is in use here for around 4 month without problems.
Created attachment 217858 [details, diff] Diff between 0.0.6 and 0.0.8_rc2
Thank you for report Thomas. Unfortunately both dev-libs/libax25 and media-radio/ax25-apps do not have dedicated maintainers in Gentoo and this means that bugs will stay as is until something really serious happens (e.g. security issue or previous version will stop working) or maintainer steps in and closes this bugs. Another possibility is proxy-maintaing: this means that someone will maintain this package (will be mentioned as maintainer in metadata.xml and will be CC'ed for bugs about package in bugzilla) while some developer (any developer actually) will review and commit work into the tree. If you wish to step in as maintainer, I can help with the review/commit part.
Peter, I know the state of the packages well. My intention was to ask ssuominen to add me as proxy maintainer for both packages as he is mentoring me. But I will gladly accept your help here.
bumped
Samuli, is there any reason not to mask this package(s)? As our policy suggests: http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3&chap=1#doc_chap4 There is a difference between using package.mask and ~arch for ebuilds. The use of ~arch denotes an ebuild requires testing. The use of package.mask denotes that the application or library itself is deemed unstable. For example, if gimp-1.2.0 is the stable release from Gimp developers, and a new bug fix release is available as 1.2.1, then a developer should mark the ebuild as ~arch for testing in portage because the release is deemed to be stable. In another example, if Gimp decides to release an unstable/development series marked as 1.3.0, then these ebuilds should be put in package.mask because the software itself is of development quality and is not recommended by the developers for distribution. Release candidates are called release candidates as they are not suggested for distribution. Also, new*, dodoc should have || die at the end since they don't die on their own.
(In reply to comment #5) > Samuli, is there any reason not to mask this package(s)? As our policy > suggests: > > http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3&chap=1#doc_chap4 > > There is a difference between using package.mask and ~arch for ebuilds. The use > of ~arch denotes an ebuild requires testing. The use of package.mask denotes > that the application or library itself is deemed unstable. For example, if > gimp-1.2.0 is the stable release from Gimp developers, and a new bug fix > release is available as 1.2.1, then a developer should mark the ebuild as ~arch > for testing in portage because the release is deemed to be stable. In another > example, if Gimp decides to release an unstable/development series marked as > 1.3.0, then these ebuilds should be put in package.mask because the software > itself is of development quality and is not recommended by the developers for > distribution. > > > Release candidates are called release candidates as they are not suggested for > distribution. Upstream knows best? Just like we use snapshot of mplayer, glibc in stable? Or release candidate of xorg-server in stable? Version schemes are just version schemes, incrementals. I trust Thomas here, he's familiar with media-radio/ applications per past experience. > Also, new*, dodoc should have || die at the end since they don't die on their > own. > Pointless. The application will work fine without documentation (and I test my ebuilds). Was there any real issue here?
Peter, let me give some more background information about the 'rc' state here. After the old upstream crew stopped the development of the ax25 packages the actual crew took over. But instead of doing formal releases they put all code into CVS and urged everyone to use that code 'to always get the newest patches'. It took me some time and discussion to convince them to prepare at least formal release candidates for a new version regularly. I hope that clarify that a little bit.
(In reply to comment #6) > Upstream knows best? Just like we use snapshot of mplayer, glibc in stable? Yup. glibc developers stated explicitly that they want people to use either CVS snapshot or redhat (see Mikes mail on upstream mailing list). mplayer - we all know why this happens (also not hard to dig the history...). This all is just exceptions that prove the rule. > Or release candidate of xorg-server in stable? Highly patched... which means that it's quite different version. > Version schemes are just version schemes, incrementals. Still they have sense. > I trust Thomas here, he's familiar with media-radio/ applications per past > experience. True. But I've started this discussion here as it looks like this mplayer/glibc/ffmpeg and similar examples where upstream just ignores downstream needs makes people to believe that all projects are doing similar way. But ... that's not true and it's possible to find in this in bugzilla counter examples where upstream developers told us that we are using rc and this means we want software with know bugs... > Pointless. The application will work fine without documentation (and I test my > ebuilds). > > Was there any real issue here? Yes. The real issue here is that this violates our policy. If you disagree, with policy argument on -dev or if there is no arguments follow policy. FWIW we have end-quiz question number 15, exactly documenting this case.
(In reply to comment #7) > Peter, let me give some more background information about the 'rc' state here. Then this makes perfect sense. Thanks for explanation. But still it's good when ebuilds correlate with quizzes.
(In reply to comment #8) > Yes. The real issue here is that this violates our policy. If you disagree, > with policy argument on -dev or if there is no arguments follow policy. FWIW we > have end-quiz question number 15, exactly documenting this case. > Where as it's good to teach new developers to play it safe, it doesn't make any sense to have this discussion here where there's nothing wrong with the dodoc line in the ebuild in question and where I've checked that every file explicitely exists. Like I always do. Like everyone should. So my current answer to 15. would be "When it's required to retain the end functionality of the application." but I'm not taking the quiz here. I do teach people to play it safe.
