Re: [gentoo-dev] TEXTRELs in assembly program
On 2021-04-22 21:23, Sam James wrote:
Such pkg_setups are best avoided if possible because they can be
confusing and we have other tools to handle it, so I’m glad you asked!
I’d provide a USE flag for this tool and mask it on non-multilib amd64
profiles (or mask everywhere and unmask on the multilib amd64
profiles).
Fasm itself can be built and run in pure amd64 environment, so we need
to mask only USEs for building additional tools and building fasm itself
against libc in non-multilib amd64 (native x86 is correct platform too)
it this approach.
1) The TEXTREL QA warning primarily exists because of the security
issues associated with them - they prevent PIC.
The following links may be useful:
-
https://flameeyes.blog/2016/01/16/textrels-text-relocations-and-their-impact-on-hardening-techniques/
- https://wiki.gentoo.org/wiki/Hardened/Textrels_Guide
However, I think it’s not really likely to be a real world issue if
the program in question is an assembler. You’re just going to hit
possible portability issues
but I’m not sure what the details are there.
Seems like gcc when used as linker frontend expects PIE-aware code in
object file and pass '-pie' to linker, but fasm doesn't know anything
about PIE, so ld fallbacks to TEXTRELs, AFAIK. Suggest two approaches:
disable passing PIE in gcc in some way or ignore textrel issues. Manual
linking seems to be error-prone in any non-standard configuration, such
as ${ROOT}/${SYSROOT} cross-environments, binary hosts, etc... maybe I
too scared because not so familiar with linking, however.
2) Passing -fno-PIE and friends should work if you use append-* from
flag-o-matic.eclass?
Passing -fno-pie to gcc has no effect, `strace --string-limit -vfe
execve` shows that '--pie' is passed to ld anyway.
Can’t see it here.
Looks like it accidentaly not posted by my stupid webmail client, posted
in plaintext in reply to original post.
Re: [gentoo-dev] TEXTRELs in assembly program
Ah, looks like attachment isn't attached, post my ebuild in plain text.
EAPI=7
inherit multilib toolchain-funcs
DESCRIPTION="Open source assembly language compiler"
HOMEPAGE="https://flatassembler.net;
SRC_URI="https://flatassembler.net/${P}.tgz;
LICENSE="MIT"
SLOT="0"
KEYWORDS="amd64 x86"
IUSE="-tools -libc"
DEPEND=""
RDEPEND=""
S="${WORKDIR}/${PN}"
PATCHES=( "${FILESDIR}/1-fix-gnu-stack.patch" )
TOOLS=(listing prepsrc symbols)
pkg_setup() {
if use tools || use libc; then
if [[ ${ARCH} = "amd64" && ! $(get_all_abis) =~ "x86" ]]; then
die "Multilib profile must be selected to build 32-bit tools or
libc-linked FASM for amd64 target"
fi
fi
CC=$(tc-getCC)
}
src_compile() {
# fasm is written on itself; so, if fasm already installed,
# assemble it with system fasm, otherwise assemble it
# with binary provided in tarball
if has_version -b "${CATEGORY}/${PN}"; then
FASM="${PN}"
is_bootstrap=1
elif [[ ${ARCH} = "x86" ]]; then
einfo "Bootstrapping fasm from binary"
FASM="./${PN}"
else # amd64
einfo "Bootstrapping fasm from binary"
FASM="./${PN}.x64"
fi
if ! use libc; then
if [[ ${ARCH} = "x86" ]]; then
${FASM} "source/Linux/${PN}.asm" "${T}/${PN}" || die
else # amd64
${FASM} "source/Linux/x64/${PN}.asm" "${T}/${PN}" || die
fi
else
${FASM} "source/libc/fasm.asm" || die
${CC} -m32 ${LDFLAGS} -o "${T}/${PN}" "source/libc/fasm.o" ||
die
fi
if use tools; then
# bootstrapping is done at this point, we can use
# our homebrewed binary for building tools
[[ -v is_bootstrap ]] && FASM="${T}/${PN}"
for tool in "${TOOLS[@]}"; do
${FASM} "tools/libc/${tool}.asm" || die
${CC} -m32 ${LDFLAGS} -o "${T}/${tool}"
"tools/libc/${tool}.o" || die
done
fi
}
src_install() {
exeinto /usr/bin
doexe "${T}/${PN}"
dodoc "${PN}.txt"
if use tools; then
for tool in "${TOOLS[@]}"; do
doexe "${T}/${tool}"
done
dodoc "tools/fas.txt"
fi
}
Re: [gentoo-dev] TEXTRELs in assembly program
> On 22 Apr 2021, at 22:07, Nekun wrote: > > Hi all, > Hi! > Working on the fasm ebuild, have some questions: > > 1. fasm is written on itself and has two variants: self-contained binary for > x86 and amd64 and linked with libc only for x86. Also, there are tools for > working with the proprietary symbolic information format which is libc-linked > and only x86. So, I provide two USEs, fail in pkg_setup if we on amd64 host > and hasn't multilib profile if they are set and link it with default CC with > -m32. Not sure it's a 'clean' way, would be happy to get some clarification > about handling such cases. Such pkg_setups are best avoided if possible because they can be confusing and we have other tools to handle it, so I’m glad you asked! I’d provide a USE flag for this tool and mask it on non-multilib amd64 profiles (or mask everywhere and unmask on the multilib amd64 profiles). > > 2. When running my ebuild, got two warnings: one about text relocations, > other about executable stack. Second problem seems trivial, just apply > patches which adds corresponding ELF sections. But the first one is not > clear: I found that TEXTRELs occurs due to default '--pie' option passed to > ld by gcc and seems like it isn't possible to remove default ld options (only > add to), so I can construct ld commandline for linking with libc manually and > resolve a bunch of corner cases... But is avoiding TEXTRELs in assembly > programs really necessary? Performance issues in case of assembly-written > assembler seems negligible... What's best according to ::gentoo policies? > Two points. 1) The TEXTREL QA warning primarily exists because of the security issues associated with them - they prevent PIC. The following links may be useful: - https://flameeyes.blog/2016/01/16/textrels-text-relocations-and-their-impact-on-hardening-techniques/ - https://wiki.gentoo.org/wiki/Hardened/Textrels_Guide However, I think it’s not really likely to be a real world issue if the program in question is an assembler. You’re just going to hit possible portability issues but I’m not sure what the details are there. 2) Passing -fno-PIE and friends should work if you use append-* from flag-o-matic.eclass? But yeah, we have a nice legacy there in terms of good defaults which made their way upstream. See the Gentoo Hardened project’s history for more information. > See ebuild draft in attachment. Can’t see it here. Regards, sam signature.asc Description: Message signed with OpenPGP
[gentoo-dev] TEXTRELs in assembly program
Hi all, Working on the fasm ebuild, have some questions: 1. fasm is written on itself and has two variants: self-contained binary for x86 and amd64 and linked with libc only for x86. Also, there are tools for working with the proprietary symbolic information format which is libc-linked and only x86. So, I provide two USEs, fail in pkg_setup if we on amd64 host and hasn't multilib profile if they are set and link it with default CC with -m32. Not sure it's a 'clean' way, would be happy to get some clarification about handling such cases. 2. When running my ebuild, got two warnings: one about text relocations, other about executable stack. Second problem seems trivial, just apply patches which adds corresponding ELF sections. But the first one is not clear: I found that TEXTRELs occurs due to default '--pie' option passed to ld by gcc and seems like it isn't possible to remove default ld options (only add to), so I can construct ld commandline for linking with libc manually and resolve a bunch of corner cases... But is avoiding TEXTRELs in assembly programs really necessary? Performance issues in case of assembly-written assembler seems negligible... What's best according to ::gentoo policies? See ebuild draft in attachment.
Re: [gentoo-dev] timezone configuration - why copying, not symlinking /etc/localtime ?
On 2021-03-27 23:40, Joshua Kinard wrote: The MIPS machine has functioning local disk drives, and currently, it boots fine by just pulling a kernel off my TFTP server and booting from the local drive, no initramfs needed because I compiled everything into it. Out of curiosity, if your kernel images already come from the TFTP servers why not simply put separate initramfs files there too? I wonder if there's a small C program out there that can call whatever the kernel functions are to mount a disk partition that could be embedded into a tiny initramfs, then pivot_root to $REAL_ROOT and run /bin/init? You might be interested in this FOSDEM 2020 talk: https://archive.fosdem.org/2020/schedule/event/ema_boot_linux_only/ Not exactly what you have asked for but the problem they are trying to solve is the same as yours - boot Linux on a system whose first-stage bootloader impose considerable size constraints. And since it uses kexec at its core, it's essentially what Rich has suggested - except it's already been (at least partially) done :-) -- MS OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] timezone configuration - why copying, not symlinking /etc/localtime ?
On 2021-03-29 10:06, James Le Cuirot wrote: Have you seen CONFIG_CMDLINE? It lets you bake command line args into the kernel image itself. And since 5.6, there is also bootconfig: https://www.kernel.org/doc/html/latest/admin-guide/bootconfig.html -- MS OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Continuous integration on GURU
On giovedì 22 aprile 2021 15:45:11 CEST Theo Anderson wrote: > Hi Agostino, > > After some discussion in IRC we've agreed to have the maintainer of > the respective packages be assigned to the bug with guru@g.o be CC'd. > Where no maintainer exists for a package guru@g.o remains as the > assignee. If you could make those changes that would be great (I > suppose doing it retroactively would be a bit of a mission and is out > of the question). > > Thanks Existing bugs have been re-assigned. New bugs will be assigned to maintainer and guru is always CC'ed. Packages with no maintainer will have guru@ as assignee. If you notice anything wrong please let me know. Agostino
Re: [gentoo-dev] Continuous integration on GURU
On Thu, Apr 22, 2021 at 01:45:11PM +, Theo Anderson wrote: > After some discussion in IRC we've agreed to have the maintainer of > the respective packages be assigned to the bug with guru@g.o be CC'd. > Where no maintainer exists for a package guru@g.o remains as the > assignee. If you could make those changes that would be great (I > suppose doing it retroactively would be a bit of a mission and is out > of the question). wrt retroactive, changes like this can be automated with pybugz and simple scripts assuming all the metadata is right and match bugzilla accounts, it'd just be a lot of mail spam. -- ionen signature.asc Description: PGP signature
Re: [gentoo-dev] Continuous integration on GURU
> On 22 Apr 2021, at 14:31, Agostino Sarubbo wrote: > > Thanks for all feedback. > > Please discuss all points internally (branch, email, trackers and so on) and > send me an email with all changes you would like to have. As an aside, I do appreciate the CI and it’s turned out to be pretty useful! It would not surprise me if I’m one of your biggest clients, but I’m going to choose to believe it’s because I’m super duper productive ;) > Agostino > > > signature.asc Description: Message signed with OpenPGP
Re: [gentoo-dev] Continuous integration on GURU
On Thu, 22 Apr 2021 13:30:10 +0200 Agostino Sarubbo wrote: > On giovedì 22 aprile 2021 12:22:00 CEST Theo Anderson wrote: > > On the subject of many bugs, there are now almost 150 open bugs > > assigned to g...@gentoo.org. With this has come quite an email > > avalanche for which I think people must have set up mail filters by > > now. I imagine this means that bugs will no longer get the same > > amount of attention as they used to. To increase the visibility do > > you think it would be a good idea to CC or assign the bugs to the > > specific package maintainers rather than g...@gentoo.org? > > Hello Theo, > > I'm fine to assign directly and/or cc'ing guru@. For now I'm > following the guidelines but it takes one second to change it. > Please discuss this internally and let me know if I have to change > the assignee. > > Agostino > Hi Agostino, After some discussion in IRC we've agreed to have the maintainer of the respective packages be assigned to the bug with guru@g.o be CC'd. Where no maintainer exists for a package guru@g.o remains as the assignee. If you could make those changes that would be great (I suppose doing it retroactively would be a bit of a mission and is out of the question). Thanks
Re: [gentoo-dev] Continuous integration on GURU
Thanks for all feedback. Please discuss all points internally (branch, email, trackers and so on) and send me an email with all changes you would like to have. Agostino
Re: [gentoo-dev] python and frieds installs test code
> On 22 Apr 2021, at 11:50, Joakim Tjernlund > wrote: > > I have noted that python, portage and gentoolkit appers to install many MB of > what appers > to be test code: > python: /usr/lib/python*/test, /usr/lib/python*/ctypes/test, > /usr/lib/python*/lib2to3/tests, >/usr/lib/python*/unittest, /usr/lib/python*/distutils/tests ... > > portage/gentoolkit: /usr/lib/python*/site-packages/portage/tests > /usr/lib/python*/site-packages/gentoolkit/test .. > > Didn't look further, I guess there is more pkgs > > The question then is, are these required in a running system? It’s possible that there are various dev-python/* packages which we need to strip tests out of, but the ones you’ve listed aren’t ones we can fix AFAIK. > > Jocke signature.asc Description: Message signed with OpenPGP
Re: [gentoo-dev] Continuous integration on GURU
> On 22 Apr 2021, at 13:59, Ionen Wolkens wrote: > [snip] > And, even if you don't see it like that, someday someone may want > to go on a fixing spree using those trackers (may it be for ::guru > or ::gentoo) but will keep seeing them mixed up together. Yes, this is particularly apt for me. Let’s just have another tracker. It’s not really helpful to have one for all - there’s no use case other than looking at the large list. Separate ones have a real purpose - letting us do sprees or quickly mouseover and see blockers we’ve been checking on. > -- > ionen signature.asc Description: Message signed with OpenPGP
Re: [gentoo-dev] Continuous integration on GURU
On giovedì 22 aprile 2021 14:59:00 CEST Ionen Wolkens wrote: > And, even if you don't see it like that, someday someone may want > to go on a fixing spree using those trackers (may it be for ::guru > or ::gentoo) but will keep seeing them mixed up together. You can do it as wel by doing a separate bugzilla search. Agostino
Re: [gentoo-dev] Continuous integration on GURU
On 22/04/2021 14:39, Agostino Sarubbo wrote: On giovedì 22 aprile 2021 12:02:20 CEST Michał Górny wrote: Well, I suppose scanning the dev branch would be preferable over the master branch. In reality, they are usually only a few hours apart but it might be useful to know of new breakage in dev before it's merged to master. It would be ideal if you could do a switch when master and dev are in sync, and just copy the state from master. Hi, I think that your approach could be generally valid but for this use case I'm against because of the following: 1) The approach is valid in cases like our github PRs and the bot that approves the commit. In this case, who moves the commit between branches does not know if the scan has been done or not. 2) I don't see the reason to scan against something that we don't know if will be the same in master branch 3) We are not doing a similar approach for ::gentoo so I don't see why do this for GURU since, after all, it is an overlay 4) Packages in master are supposed to be tested at least from 2 different people (who made the commit in dev and who moves the commit to master) so it means less bugspam Well, not quite, packages in master have been manually/visually checked for obvious (QA) mistakes and have been automatically checked by repoman/pkgcheck. In principle the role of the Trusted Contributor is first of all to ensure that no malicious commits make it into the master branch, as described on the wiki[1]. In practice this means that we also do basic QA checks and look at the repoman/pkgcheck results, since we are looking at the commit anyway. We do not actually run emerge on the ebuild, back in the early days I used to do that, but the amount of commits has grown enormously and it is no longer practically possible to do this (and here is where the tinderbox comes in handy). Furthermore, as per [1] we are not supposed to postpone a merge just because a commit has QA issues, fails to build or whatever. The only situation in which we do not merge a commit, is if it is malicious. QA issues or obvious mistakes are reported back to the author, or fixed immediately, but they do not disqualify a commit for merging to the master branch. On the matter of running the tinderbox on the master branch or the dev branch, I am undecided. It makes sense to do the checks as soon as possible and to fix things before they reach the master branch. On the other hand there are sometimes very big issues (missing dependencies and such) and I am not sure how the tinderbox will behave in these cases. Filing bugs for things which the Trusted Contributors can see in repoman/pkgcheck (such as missing dependencies) is a waste of cpu power, and only serves to increase the number of emails, so if the tinderbox would also file reports for these issues I would advise to run the tinderbox only on the master branch. (Then there is also the matter to consider that in theory the dev branch could contain malicious code, whereas the master branch is guaranteed to be free of this. So if the tinderbox runs on the dev branch, then in theory a hypothetical malicious commit might break the tinderbox.) Tl;dr Commits are checked, not actually tested. [1] https://wiki.gentoo.org/wiki/Project:GURU/Information_for_Trusted_Contributor One more thing: might be a good idea to consider splitting some of the 'big' trackers (like CFLAGS) between Gentoo and GURU. I think solving these bugs in GURU has lower priority than in Gentoo. I think that trackers like CFLAGS/LDFLAGS are here to track how many packages have the problem. I don't see it like (for example) the gcc-porting tracker that gives the idea about how much packages need a fix and how much packages need to be last-rited Agostino
Re: [gentoo-dev] Continuous integration on GURU
On Thu, 2021-04-22 at 14:39 +0200, Agostino Sarubbo wrote: > On giovedì 22 aprile 2021 12:02:20 CEST Michał Górny wrote: > > Well, I suppose scanning the dev branch would be preferable over > > the master branch. In reality, they are usually only a few hours apart > > but it might be useful to know of new breakage in dev before it's merged > > to master. > > > > It would be ideal if you could do a switch when master and dev are > > in sync, and just copy the state from master. > > Hi, > > I think that your approach could be generally valid but for this use case I'm > against because of the following: > > 1) The approach is valid in cases like our github PRs and the bot that > approves the commit. In this case, who moves the commit between branches does > not know if the scan has been done or not. > > 2) I don't see the reason to scan against something that we don't know if > will > be the same in master branch > > 3) We are not doing a similar approach for ::gentoo so I don't see why do > this > for GURU since, after all, it is an overlay > > 4) Packages in master are supposed to be tested at least from 2 different > people (who made the commit in dev and who moves the commit to master) so it > means less bugspam > This is not how GURU works. The dev->master merges are always fast- forward, and are only reviewed to prevent malicious actions. -- Best regards, Michał Górny
Re: [gentoo-dev] Continuous integration on GURU
On Thu, Apr 22, 2021 at 8:39 AM Agostino Sarubbo wrote: > > On giovedì 22 aprile 2021 12:02:20 CEST Michał Górny wrote: > > Well, I suppose scanning the dev branch would be preferable over > > the master branch. In reality, they are usually only a few hours apart > > but it might be useful to know of new breakage in dev before it's merged > > to master. > > > > It would be ideal if you could do a switch when master and dev are > > in sync, and just copy the state from master. > > Hi, > > I think that your approach could be generally valid but for this use case I'm > against because of the following: > > 1) The approach is valid in cases like our github PRs and the bot that > approves the commit. In this case, who moves the commit between branches does > not know if the scan has been done or not. > > 2) I don't see the reason to scan against something that we don't know if will > be the same in master branch > > 3) We are not doing a similar approach for ::gentoo so I don't see why do this > for GURU since, after all, it is an overlay > > 4) Packages in master are supposed to be tested at least from 2 different > people (who made the commit in dev and who moves the commit to master) so it > means less bugspam > Perhaps another approach could be to add a third branch, "staging". Any reviewers could move the appropriate ebuilds to "staging" once all the reviews and discussions are done but before moving to "master" In fact, probably a github action could be set up to automatically move to "master" after the CI stuff passes.
Re: [gentoo-dev] Continuous integration on GURU
On Thu, Apr 22, 2021 at 02:39:02PM +0200, Agostino Sarubbo wrote: > On giovedì 22 aprile 2021 12:02:20 CEST Michał Górny wrote: > > One more thing: might be a good idea to consider splitting some > > of the 'big' trackers (like CFLAGS) between Gentoo and GURU. I think > > solving these bugs in GURU has lower priority than in Gentoo. > > I think that trackers like CFLAGS/LDFLAGS are here to track how many packages > have the problem. I don't see it like (for example) the gcc-porting tracker > that gives the idea about how much packages need a fix and how much packages > need to be last-rited If want to track, can't we just have separate tracker(s) for GURU? Now when look at this tracker can't tell how much is ::gentoo or ::guru without doing some extra work. And, even if you don't see it like that, someday someone may want to go on a fixing spree using those trackers (may it be for ::guru or ::gentoo) but will keep seeing them mixed up together. -- ionen signature.asc Description: PGP signature
Re: [gentoo-dev] python and frieds installs test code
On Thu, 2021-04-22 at 10:50 +, Joakim Tjernlund wrote: > I have noted that python, portage and gentoolkit appers to install many MB of > what appers > to be test code: > python: /usr/lib/python*/test, /usr/lib/python*/ctypes/test, > /usr/lib/python*/lib2to3/tests, > /usr/lib/python*/unittest, /usr/lib/python*/distutils/tests ... > > portage/gentoolkit: /usr/lib/python*/site-packages/portage/tests > /usr/lib/python*/site-packages/gentoolkit/test .. > > Didn't look further, I guess there is more pkgs > > The question then is, are these required in a running system? > Yes. -- Best regards, Michał Górny
Re: [gentoo-dev] Continuous integration on GURU
On giovedì 22 aprile 2021 12:02:20 CEST Michał Górny wrote: > Well, I suppose scanning the dev branch would be preferable over > the master branch. In reality, they are usually only a few hours apart > but it might be useful to know of new breakage in dev before it's merged > to master. > > It would be ideal if you could do a switch when master and dev are > in sync, and just copy the state from master. Hi, I think that your approach could be generally valid but for this use case I'm against because of the following: 1) The approach is valid in cases like our github PRs and the bot that approves the commit. In this case, who moves the commit between branches does not know if the scan has been done or not. 2) I don't see the reason to scan against something that we don't know if will be the same in master branch 3) We are not doing a similar approach for ::gentoo so I don't see why do this for GURU since, after all, it is an overlay 4) Packages in master are supposed to be tested at least from 2 different people (who made the commit in dev and who moves the commit to master) so it means less bugspam > One more thing: might be a good idea to consider splitting some > of the 'big' trackers (like CFLAGS) between Gentoo and GURU. I think > solving these bugs in GURU has lower priority than in Gentoo. I think that trackers like CFLAGS/LDFLAGS are here to track how many packages have the problem. I don't see it like (for example) the gcc-porting tracker that gives the idea about how much packages need a fix and how much packages need to be last-rited Agostino
Re: [gentoo-dev] Continuous integration on GURU
On giovedì 22 aprile 2021 12:22:00 CEST Theo Anderson wrote: > On the subject of many bugs, there are now almost 150 open bugs > assigned to g...@gentoo.org. With this has come quite an email avalanche > for which I think people must have set up mail filters by now. I > imagine this means that bugs will no longer get the same > amount of attention as they used to. To increase the visibility do you > think it would be a good idea to CC or assign the bugs to the specific > package maintainers rather than g...@gentoo.org? Hello Theo, I'm fine to assign directly and/or cc'ing guru@. For now I'm following the guidelines but it takes one second to change it. Please discuss this internally and let me know if I have to change the assignee. Agostino
Re: [gentoo-dev] Continuous integration on GURU
On giovedì 22 aprile 2021 12:25:50 CEST Michał Górny wrote: > On Thu, 2021-04-22 at 11:59 +0200, Agostino Sarubbo wrote: > > Hello, > > > > I would like to let you know that the CI is now able to work with > > overlays. > > > > Since Guru is pretty active I took advantage of this situation to > > implement > > and test the CI > > > > Atm it has been configured to work with master branch. > > I don't know how much is useful scan the dev branch since a first revision > > has not yet been done. If you have opinions about, please let me know. > > > > More info at: > > https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ > > > > The bugs will have an internal_ref as guru_ci. >
[gentoo-dev] python and frieds installs test code
I have noted that python, portage and gentoolkit appers to install many MB of what appers to be test code: python: /usr/lib/python*/test, /usr/lib/python*/ctypes/test, /usr/lib/python*/lib2to3/tests, /usr/lib/python*/unittest, /usr/lib/python*/distutils/tests ... portage/gentoolkit: /usr/lib/python*/site-packages/portage/tests /usr/lib/python*/site-packages/gentoolkit/test .. Didn't look further, I guess there is more pkgs The question then is, are these required in a running system? Jocke
Re: [gentoo-dev] Continuous integration on GURU
On Thu, 2021-04-22 at 11:59 +0200, Agostino Sarubbo wrote: > Hello, > > I would like to let you know that the CI is now able to work with overlays. > > Since Guru is pretty active I took advantage of this situation to implement > and test the CI > > Atm it has been configured to work with master branch. > I don't know how much is useful scan the dev branch since a first revision > has > not yet been done. If you have opinions about, please let me know. > > More info at: > https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ > > The bugs will have an internal_ref as guru_ci. > One more thing: might be a good idea to consider splitting some of the 'big' trackers (like CFLAGS) between Gentoo and GURU. I think solving these bugs in GURU has lower priority than in Gentoo. -- Best regards, Michał Górny
Re: [gentoo-dev] Continuous integration on GURU
On Thu, 22 Apr 2021 11:59:21 +0200 Agostino Sarubbo wrote: > Hello, > > I would like to let you know that the CI is now able to work with > overlays. > > Since Guru is pretty active I took advantage of this situation to > implement and test the CI Thank you for implementing this, it certainly helps raise the standard of guru packages. > > Atm it has been configured to work with master branch. > I don't know how much is useful scan the dev branch since a first > revision has not yet been done. If you have opinions about, please > let me know. I'm not sure this would be very beneficial. It's often that feedback is left on packages in dev to get them in a presentable or issue free state before being pushed to master. Running the tinderbox against dev might just make a few too many bugs, perhaps picking up some which are already in the process of being fixed. The dev branch doesn't lag too far behind master these days anyhow. > > More info at: > https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ > > The bugs will have an internal_ref as guru_ci. > > Agostino > On the subject of many bugs, there are now almost 150 open bugs assigned to g...@gentoo.org. With this has come quite an email avalanche for which I think people must have set up mail filters by now. I imagine this means that bugs will no longer get the same amount of attention as they used to. To increase the visibility do you think it would be a good idea to CC or assign the bugs to the specific package maintainers rather than g...@gentoo.org? Cheers Theo
Re: [gentoo-dev] Continuous integration on GURU
On Thu, 2021-04-22 at 11:59 +0200, Agostino Sarubbo wrote: > Hello, > > I would like to let you know that the CI is now able to work with overlays. > > Since Guru is pretty active I took advantage of this situation to implement > and test the CI > > Atm it has been configured to work with master branch. > I don't know how much is useful scan the dev branch since a first revision > has > not yet been done. If you have opinions about, please let me know. > > More info at: > https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ > > The bugs will have an internal_ref as guru_ci. > Well, I suppose scanning the dev branch would be preferable over the master branch. In reality, they are usually only a few hours apart but it might be useful to know of new breakage in dev before it's merged to master. It would be ideal if you could do a switch when master and dev are in sync, and just copy the state from master. -- Best regards, Michał Górny
[gentoo-dev] Continuous integration on GURU
Hello, I would like to let you know that the CI is now able to work with overlays. Since Guru is pretty active I took advantage of this situation to implement and test the CI Atm it has been configured to work with master branch. I don't know how much is useful scan the dev branch since a first revision has not yet been done. If you have opinions about, please let me know. More info at: https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ The bugs will have an internal_ref as guru_ci. Agostino
Re: [gentoo-dev] unmasking java 11 on gentoo (for those that maintain packages where java is involved, either directly or conditionally)
Dne 22. 04. 21 v 8:37 Kaibo Ma napsal(a): Is there a tracking issue for Java 11 on Bugzilla? Kaibo Ma this is it: https://bugs.gentoo.org/697014 fordfrog
[gentoo-dev] Last rites: dev-python/idna-ssl
# Michał Górny (2021-04-22) # py3.7 backport with no revdeps left. # Removal on 2021-05-22. Bug #784983. dev-python/idna-ssl -- Best regards, Michał Górny
Re: [gentoo-dev] unmasking java 11 on gentoo (for those that maintain packages where java is involved, either directly or conditionally)
Is there a tracking issue for Java 11 on Bugzilla? Kaibo Ma On Wed, 14 Apr 2021 at 15:45, Miroslav Šulc wrote: > hi guys, > > we're still far from unmasking java 11 on gentoo, but i hope it will > happen, one day (or another...). currently there is one issue across the > whole gentoo tree that is a sure blocker and could and should be easily > resolved. as java 11 does not compile bytecode older than 1.6, > everything that specifies in deps virtual/(jdk|jre)-1.[2-5] will fail to > compile and run. these deps should be lifted up to > virtual/(jdk|jre)-1.8. also, packages that depend on > virtual/(jdk|jre)-1.[67] should be lifted up to 1.8 as that is the > lowest version that we support on gentoo and future versions of java > might drop support for 1.6 and 1.7 as well, but it's not a blocker for now. > > just to get an idea how many ebuilds are affected, here's a short summary: > > $ git --no-pager grep -Eho "virtual/(jre|jdk)-1.[2-7]" | sort | uniq -c >1 virtual/jdk-1.2 >7 virtual/jdk-1.3 > 68 virtual/jdk-1.4 > 119 virtual/jdk-1.5 > 444 virtual/jdk-1.6 > 136 virtual/jdk-1.7 >1 virtual/jre-1.2 >7 virtual/jre-1.3 > 68 virtual/jre-1.4 > 124 virtual/jre-1.5 > 460 virtual/jre-1.6 > 113 virtual/jre-1.7 > > here's the list of all packages where java 1.5 or older is used: > > $ git --no-pager grep -Elo "virtual/(jre|jdk)-1.[2-5]" | sed -E > "s%/[^/]+$%%g" | sort | uniq > app-accessibility/brltty > app-accessibility/freetts > app-crypt/jacksum > app-emacs/jde > app-misc/jitac > app-office/hourglass > app-text/hyperestraier > dev-db/db-je > dev-db/hsqldb > dev-db/qdbm > dev-java/ant-contrib > dev-java/ant-owanttask > dev-java/apple-java-extensions-bin > dev-java/apt-mirror > dev-java/aspectj > dev-java/avalon-framework > dev-java/bcel > dev-java/bnd-junit > dev-java/bndlib > dev-java/browserlauncher2 > dev-java/bytelist > dev-java/cal10n > dev-java/cdegroot-db > dev-java/cldc-api > dev-java/codemodel > dev-java/commons-el > dev-java/commons-fileupload > dev-java/commons-lang > dev-java/commons-math > dev-java/commons-net > dev-java/commons-pool > dev-java/commons-validator > dev-java/dtdparser > dev-java/easymock-classextension > dev-java/ehcache > dev-java/ezmorph > dev-java/fastinfoset > dev-java/fscript > dev-java/glassfish-persistence > dev-java/gnu-classpath > dev-java/gson > dev-java/hamcrest-integration > dev-java/hawtjni-runtime > dev-java/helpgui > dev-java/higlayout > dev-java/htmlcleaner > dev-java/ical4j > dev-java/jansi > dev-java/jarbundler > dev-java/java-dep-check > dev-java/java-getopt > dev-java/javahelp > dev-java/java-service-wrapper > dev-java/javolution > dev-java/jaxen > dev-java/jbitcollider-core > dev-java/jboss-logmanager > dev-java/jcmdline > dev-java/jcodings > dev-java/jdbc2-stdext > dev-java/jdbm > dev-java/jebl > dev-java/jgoodies-looks > dev-java/jid3 > dev-java/jinput > dev-java/jisp > dev-java/jlibeps > dev-java/jnr-ffi > dev-java/jnr-netdb > dev-java/joni > dev-java/jortho > dev-java/jreleaseinfo > dev-java/jstun > dev-java/jta > dev-java/junit-addons > dev-java/junrar > dev-java/jvmstat > dev-java/jvyamlb > dev-java/jzlib > dev-java/j2ssh > dev-java/ldapsdk > dev-java/libg > dev-java/libmatthew-java > dev-java/l2fprod-common > dev-java/miglayout > dev-java/minlog > dev-java/mockito > dev-java/msv > dev-java/nekohtml > dev-java/odfdom > dev-java/osgi-compendium > dev-java/osgi-enterprise-api > dev-java/osgi-foundation > dev-java/pdf-renderer > dev-java/picocontainer > dev-java/prefuse > dev-java/radeox > dev-java/resin-servlet-api > dev-java/sblim-cim-client > dev-java/skinlf > dev-java/slf4j-ext > dev-java/spymemcached > dev-java/squareness-jlf > dev-java/stax-ex > dev-java/stax2-api > dev-java/sun-httpserver-bin > dev-java/sun-jai-bin > dev-java/sun-jimi > dev-java/sun-jms > dev-java/sun-jmx > dev-java/swingx > dev-java/swt > dev-java/tagsoup > dev-java/tapestry > dev-java/validation-api > dev-java/werken-xpath > dev-java/wsdl4j > dev-java/xmlstreambuffer > dev-java/xom > dev-java/zeus-jscl > dev-lang/interprolog > dev-lang/R > dev-lang/xsb > dev-libs/OpenNI > dev-libs/OpenNI2 > dev-lisp/abcl > dev-ruby/rjb > dev-tex/tex4ht > dev-util/android-sdk-update-manager > dev-util/jarwizard > dev-util/oprofile > games-board/domination > games-board/megamek > games-puzzle/pauker > java-virtuals/jmx > media-gfx/freewrl > media-gfx/graphviz > media-gfx/povtree > media-libs/libcaca > media-libs/libjpeg-turbo > media-libs/libpano13 > media-libs/mlt > media-sound/entagged-tageditor > media-sound/protux > media-tv/channeleditor > media-video/projectx > net-analyzer/munin > net-analyzer/neti > net-dns/libidn > net-libs/NativeThread > net-misc/tigervnc > net-nds/jxplorer > sci-biology/amap > sci-libs/cdf > sci-libs/libsigrok > sci-libs/libsvm > sci-libs/plplot > sci-misc/netlogo-bin > sci-physics/jaxodraw > sci-physics/thepeg > sys-devel/gettext > sys-libs/db > > i would like to ask you to revisit your packages where
