Re: [gentoo-dev] base.eclass
On Sun, 8 Jul 2012 23:40:29 +0200 "Andreas K. Huettel" wrote: > Am Sonntag 08 Juli 2012, 22:10:02 schrieb Michał Górny: > > On Sun, 08 Jul 2012 19:49:25 +0200 > > > > René Neumann wrote: > > > Hi all, > > > > > > I'd like just to receive a short clarification about the 'status' > > > of base.eclass: Is this eclass expected to be available > > > everywhere, i.e. should each eclass make sure it imports and > > > incorporates it. Or is it just an eclass like the others and > > > ebuilds should make sure they inherit it if needed? > > > > No. It is unmaintained, has serious design flaws and it simply > > should not be used anywhere. At least in EAPI != [01]. > > Please clarify this. > > A lot of (inheriting eclasses and) packages depend on features > provided by base.eclass (e.g., PATCHES), which are pretty neat and > which I would sorely miss. So I would certainly object to deprecating > base.eclass, unless its relevant functionality is only moving to a > better place. base.eclass is randomly exporting non-requested, non-wanted phase functions colliding with other inherited eclasses. It's just the lexical order of inherits what stops mayhem from happening. In other words, base.eclass is only suitable if you are expecting to export *all* phase functions which simply doesn't happen in eclasses. For example, if distutils used base eclass, every VCS eclass inherited before it would be ignored (due to src_unpack() redefined to default one for no good reason). -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] base.eclass
On Sun, 8 Jul 2012 17:35:08 -0400
Alexis Ballier wrote:
> On Sun, 8 Jul 2012 22:10:02 +0200
> Michał Górny wrote:
>
> > On Sun, 08 Jul 2012 19:49:25 +0200
> > René Neumann wrote:
> >
> > > Hi all,
> > >
> > > I'd like just to receive a short clarification about the 'status'
> > > of base.eclass: Is this eclass expected to be available
> > > everywhere, i.e. should each eclass make sure it imports and
> > > incorporates it. Or is it just an eclass like the others and
> > > ebuilds should make sure they inherit it if needed?
> >
> > No. It is unmaintained, has serious design flaws and it simply
> > should not be used anywhere. At least in EAPI != [01].
> >
>
> what is the PATCHES=() replacement in new eapis? (mainly why i use
> base.eclass more and more these days)
That's what I used:
[[ ${PATCHES} ]] && epatch "${PATCHES[@]}"
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] Last rites for net-ftp/netkit-tftp
On 07/08/2012 08:57 PM, Jeroen Roovers wrote: On Sun, 08 Jul 2012 23:29:35 +0200 Pacho Ramos wrote: El dom, 08-07-2012 a las 21:49 +0200, Diego Elio Pettenò escribió: Il 08/07/2012 20:13, Chí-Thanh Christopher Nguyễn ha scritto: Please report a removal bug for this, so any issues concerning users of netkit-tftp can be tracked. Here it is: https://bugs.gentoo.org/show_bug.cgi?id=425362 And actually Robin K. who submitted the overflow bug I fixed, pointed out that there _are_ cases where hpa doesn't work but netkit does, so I've downgraded the removal to a simple masking for bad code. I guess we'll wait a bit more before removing this, in the mean time though I don't really feel happy with leaving it unmasked so it'll stay as it is. If its upstream is completely dead, it has bad code and it has a replacement, I would still go to treeclean it But if it provides the only means to netboot certain hardware, then you might think twice. jer I have several ubiquity routerstations (the hardware in questions) and I've asked Robin Kauffman to report the steps to reproduce in the bug. I'll try to get to the bottom of why tftp-hpa doesn't work. --Tony -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 8040 5A4D 8709 21B1 1A88 33CE 979C AF40 D045 5535 GnuPG ID : D0455535
Re: [gentoo-dev] Last rites for net-ftp/netkit-tftp
On Sun, 08 Jul 2012 23:29:35 +0200 Pacho Ramos wrote: > El dom, 08-07-2012 a las 21:49 +0200, Diego Elio Pettenò escribió: > > Il 08/07/2012 20:13, Chí-Thanh Christopher Nguyễn ha scritto: > > > Please report a removal bug for this, so any issues concerning > > > users of netkit-tftp can be tracked. > > > > Here it is: > > https://bugs.gentoo.org/show_bug.cgi?id=425362 > > > > And actually Robin K. who submitted the overflow bug I fixed, > > pointed out that there _are_ cases where hpa doesn't work but > > netkit does, so I've downgraded the removal to a simple masking for > > bad code. > > > > I guess we'll wait a bit more before removing this, in the mean time > > though I don't really feel happy with leaving it unmasked so it'll > > stay as it is. > > > > If its upstream is completely dead, it has bad code and it has a > replacement, I would still go to treeclean it But if it provides the only means to netboot certain hardware, then you might think twice. jer
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2012-07-08 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2012-07-08 23h59 UTC. Removals: games-util/nforenum 2012-07-02 04:55:38 mr_bones_ net-libs/xulrunner 2012-07-04 07:18:48 ssuominen net-misc/mDNSResponder 2012-07-05 22:13:02 dilfridge x11-plugins/enigmail2012-07-06 07:33:40 ssuominen x11-plugins/replytolist 2012-07-06 07:33:41 ssuominen x11-themes/mythtv-themes2012-07-08 23:07:21 cardoe Additions: app-crypt/oclhashcat-lite-bin 2012-07-02 01:25:52 zerochaos app-crypt/oclhashcat-plus-bin 2012-07-02 01:52:04 zerochaos app-crypt/hashcat-gui 2012-07-02 02:12:24 zerochaos sys-kernel/mkinitcpio 2012-07-02 10:43:03 xmw app-misc/ttysnoop 2012-07-02 11:46:15 maksbotan net-misc/yajhfc 2012-07-02 14:48:24 mattm media-plugins/qmmp-plugin-pack 2012-07-02 18:09:15 hwoarang dev-util/monkeystudio 2012-07-03 17:20:33 kensington sys-fs/libfat 2012-07-03 21:24:11 vapier x11-themes/bespin 2012-07-04 02:20:21 creffett net-misc/gtkvncviewer 2012-07-04 06:08:05 angelos sys-kernel/mkinitcpio-nfs-utils 2012-07-04 18:16:26 xmw dev-ml/ocaml-gettext2012-07-05 01:56:16 aballier media-gfx/iscan-plugin-gt-x770 2012-07-05 18:56:54 flameeyes x11-libs/qtermwidget2012-07-06 13:35:52 yngwin x11-terms/qterminal 2012-07-06 13:43:29 yngwin media-sound/coquillo2012-07-06 15:45:40 yngwin net-wireless/kismet-ubertooth 2012-07-06 20:40:57 zerochaos dev-db/textsearch_ja2012-07-06 22:45:57 naota media-gfx/entangle 2012-07-08 18:58:15 flameeyes -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: games-util/nforenum,removed,mr_bones_,2012-07-02 04:55:38 net-libs/xulrunner,removed,ssuominen,2012-07-04 07:18:48 net-misc/mDNSResponder,removed,dilfridge,2012-07-05 22:13:02 x11-plugins/enigmail,removed,ssuominen,2012-07-06 07:33:40 x11-plugins/replytolist,removed,ssuominen,2012-07-06 07:33:41 x11-themes/mythtv-themes,removed,cardoe,2012-07-08 23:07:21 Added Packages: app-crypt/oclhashcat-lite-bin,added,zerochaos,2012-07-02 01:25:52 app-crypt/oclhashcat-plus-bin,added,zerochaos,2012-07-02 01:52:04 app-crypt/hashcat-gui,added,zerochaos,2012-07-02 02:12:24 sys-kernel/mkinitcpio,added,xmw,2012-07-02 10:43:03 app-misc/ttysnoop,added,maksbotan,2012-07-02 11:46:15 net-misc/yajhfc,added,mattm,2012-07-02 14:48:24 media-plugins/qmmp-plugin-pack,added,hwoarang,2012-07-02 18:09:15 dev-util/monkeystudio,added,kensington,2012-07-03 17:20:33 sys-fs/libfat,added,vapier,2012-07-03 21:24:11 x11-themes/bespin,added,creffett,2012-07-04 02:20:21 net-misc/gtkvncviewer,added,angelos,2012-07-04 06:08:05 sys-kernel/mkinitcpio-nfs-utils,added,xmw,2012-07-04 18:16:26 dev-ml/ocaml-gettext,added,aballier,2012-07-05 01:56:16 media-gfx/iscan-plugin-gt-x770,added,flameeyes,2012-07-05 18:56:54 x11-libs/qtermwidget,added,yngwin,2012-07-06 13:35:52 x11-terms/qterminal,added,yngwin,2012-07-06 13:43:29 media-sound/coquillo,added,yngwin,2012-07-06 15:45:40 net-wireless/kismet-ubertooth,added,zerochaos,2012-07-06 20:40:57 dev-db/textsearch_ja,added,naota,2012-07-06 22:45:57 media-gfx/entangle,added,flameeyes,2012-07-08 18:58:15 Done.
Re: [gentoo-dev] base.eclass
Am Sonntag 08 Juli 2012, 22:10:02 schrieb Michał Górny: > On Sun, 08 Jul 2012 19:49:25 +0200 > > René Neumann wrote: > > Hi all, > > > > I'd like just to receive a short clarification about the 'status' of > > base.eclass: Is this eclass expected to be available everywhere, i.e. > > should each eclass make sure it imports and incorporates it. Or is it > > just an eclass like the others and ebuilds should make sure they > > inherit it if needed? > > No. It is unmaintained, has serious design flaws and it simply should > not be used anywhere. At least in EAPI != [01]. Please clarify this. A lot of (inheriting eclasses and) packages depend on features provided by base.eclass (e.g., PATCHES), which are pretty neat and which I would sorely miss. So I would certainly object to deprecating base.eclass, unless its relevant functionality is only moving to a better place. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] base.eclass
On Sun, 8 Jul 2012 22:10:02 +0200 Michał Górny wrote: > On Sun, 08 Jul 2012 19:49:25 +0200 > René Neumann wrote: > > > Hi all, > > > > I'd like just to receive a short clarification about the 'status' of > > base.eclass: Is this eclass expected to be available everywhere, > > i.e. should each eclass make sure it imports and incorporates it. > > Or is it just an eclass like the others and ebuilds should make > > sure they inherit it if needed? > > No. It is unmaintained, has serious design flaws and it simply should > not be used anywhere. At least in EAPI != [01]. > what is the PATCHES=() replacement in new eapis? (mainly why i use base.eclass more and more these days)
Re: [gentoo-dev] base.eclass
El dom, 08-07-2012 a las 22:59 +0200, René Neumann escribió: > Am 08.07.2012 22:10, schrieb Michał Górny: > > On Sun, 08 Jul 2012 19:49:25 +0200 > > René Neumann wrote: > > > >> Hi all, > >> > >> I'd like just to receive a short clarification about the 'status' of > >> base.eclass: Is this eclass expected to be available everywhere, i.e. > >> should each eclass make sure it imports and incorporates it. Or is it > >> just an eclass like the others and ebuilds should make sure they > >> inherit it if needed? > > > > No. It is unmaintained, has serious design flaws and it simply should > > not be used anywhere. At least in EAPI != [01]. > > > > Thanks for the clarification. As Mike already mentioned, one should > probably change the ebuild description to reflect just that fact. > (Because at the moment it just says the complete opposite.) > > - René > And, if we are supposed to stop using it, it should print some kind of warning to remember developers to drop its usage signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Last rites for net-ftp/netkit-tftp
El dom, 08-07-2012 a las 21:49 +0200, Diego Elio Pettenò escribió: > Il 08/07/2012 20:13, Chí-Thanh Christopher Nguyễn ha scritto: > > Please report a removal bug for this, so any issues concerning users of > > netkit-tftp can be tracked. > > Here it is: > https://bugs.gentoo.org/show_bug.cgi?id=425362 > > And actually Robin K. who submitted the overflow bug I fixed, pointed > out that there _are_ cases where hpa doesn't work but netkit does, so > I've downgraded the removal to a simple masking for bad code. > > I guess we'll wait a bit more before removing this, in the mean time > though I don't really feel happy with leaving it unmasked so it'll stay > as it is. > If its upstream is completely dead, it has bad code and it has a replacement, I would still go to treeclean it signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] base.eclass
Am 08.07.2012 22:10, schrieb Michał Górny: > On Sun, 08 Jul 2012 19:49:25 +0200 > René Neumann wrote: > >> Hi all, >> >> I'd like just to receive a short clarification about the 'status' of >> base.eclass: Is this eclass expected to be available everywhere, i.e. >> should each eclass make sure it imports and incorporates it. Or is it >> just an eclass like the others and ebuilds should make sure they >> inherit it if needed? > > No. It is unmaintained, has serious design flaws and it simply should > not be used anywhere. At least in EAPI != [01]. > Thanks for the clarification. As Mike already mentioned, one should probably change the ebuild description to reflect just that fact. (Because at the moment it just says the complete opposite.) - René signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] base.eclass
On Sun, 08 Jul 2012 19:49:25 +0200 René Neumann wrote: > Hi all, > > I'd like just to receive a short clarification about the 'status' of > base.eclass: Is this eclass expected to be available everywhere, i.e. > should each eclass make sure it imports and incorporates it. Or is it > just an eclass like the others and ebuilds should make sure they > inherit it if needed? No. It is unmaintained, has serious design flaws and it simply should not be used anywhere. At least in EAPI != [01]. -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] inittab with SIGPWR support
Hi all, To have a better support for Gentoo lxc guests, it would be nice if our default inittab contained a line for handling SIGPWR sent to PID 1 to shut the system down. As far as I can tell systemd and upstart already do that, which then makes it possible to have LXC handle most Linux guests just fine. Let me know if anyone has doubts about the validity of doing this by default. Thanks, -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Last rites for net-ftp/netkit-tftp
Il 08/07/2012 20:13, Chí-Thanh Christopher Nguyễn ha scritto: > Please report a removal bug for this, so any issues concerning users of > netkit-tftp can be tracked. Here it is: https://bugs.gentoo.org/show_bug.cgi?id=425362 And actually Robin K. who submitted the overflow bug I fixed, pointed out that there _are_ cases where hpa doesn't work but netkit does, so I've downgraded the removal to a simple masking for bad code. I guess we'll wait a bit more before removing this, in the mean time though I don't really feel happy with leaving it unmasked so it'll stay as it is. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
[gentoo-dev] More packages looking for new maintainers
Just a few more packages that I'm no longer using or for which I no longer have hardware or so on so forth. Yes I'm still cleaning this stuff up. Notes in brackets below a list. * indicates a dependency of the described package; + indicates there is another maintainer/herd for it anyway. app-crypt/ekeyd dev-lua/luasocket * [This requires an EntropyKey — upstream seems to be mostly dead as the original developers no longer are with SimTec as far as I know. I still have two devices, and I'll try bringing them with me in the US, but I'm not sure if it's worth for me to try keeping it up to date in this situation.] dev-util/gdbserver [This should be just removed as gdb now has an USE flag for it] mail-client/nail + media-video/subtitleeditor + net-analyzer/squidview + net-libs/liboauth net-misc/bti + net-misc/gogoc + sys-power/apcupsd + -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Last rites for net-ftp/netkit-tftp
Diego Elio Pettenò schrieb: > I just fixed a (reported) buffer overflow on it (not a security bug), > but the code is very bad and I'm expecting more issues in the future. > > The ebuild wasn't bumped since 2008, the upstream FTP site is entirely > gone (there's no more the _domain_ of it), and net-ftp/tftp-hpa should > replace it in all ways. > > So it'll be removed next month if there are no reasons to keep it around. Please report a removal bug for this, so any issues concerning users of netkit-tftp can be tracked. Best regards, Chí-Thanh Christopher Nguyễn
[gentoo-dev] Last rites for net-ftp/netkit-tftp
I just fixed a (reported) buffer overflow on it (not a security bug), but the code is very bad and I'm expecting more issues in the future. The ebuild wasn't bumped since 2008, the upstream FTP site is entirely gone (there's no more the _domain_ of it), and net-ftp/tftp-hpa should replace it in all ways. So it'll be removed next month if there are no reasons to keep it around. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] base.eclass
On Sun, Jul 8, 2012 at 1:54 PM, Ciaran McCreesh wrote: > On Sun, 08 Jul 2012 19:49:25 +0200 > René Neumann wrote: >> I'd like just to receive a short clarification about the 'status' of >> base.eclass: Is this eclass expected to be available everywhere, i.e. >> should each eclass make sure it imports and incorporates it. Or is it >> just an eclass like the others and ebuilds should make sure they >> inherit it if needed? > > base.eclass is a historical mistake, from before the design of eclasses > was fully figured out and moved into the package manager. Unfortunately, > rather than letting it die, people keep putting things in it and using > it... I think it would be a good idea to remove the second sentence of the description, which is clearly false. # @DESCRIPTION: # The base eclass defines some default functions and variables. Nearly # everything else inherits from here.
Re: [gentoo-dev] base.eclass
On Sun, 08 Jul 2012 19:49:25 +0200 René Neumann wrote: > I'd like just to receive a short clarification about the 'status' of > base.eclass: Is this eclass expected to be available everywhere, i.e. > should each eclass make sure it imports and incorporates it. Or is it > just an eclass like the others and ebuilds should make sure they > inherit it if needed? base.eclass is a historical mistake, from before the design of eclasses was fully figured out and moved into the package manager. Unfortunately, rather than letting it die, people keep putting things in it and using it... -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] base.eclass
Hi all,
I'd like just to receive a short clarification about the 'status' of
base.eclass: Is this eclass expected to be available everywhere, i.e.
should each eclass make sure it imports and incorporates it. Or is it
just an eclass like the others and ebuilds should make sure they inherit
it if needed?
In my special case, I discovered that I cannot rely on 'PATCHES' being
honored and hence have to introduce something like:
src_prepare () {
epatch "some.patch"
distutils_src_prepare
}
And, imho, this is just noise -- having PATCHES=( "some.patch" ) would
be clearer :)
Thanks,
René
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] "maintainer needed" for app-emul/playonlinux
On Sun, Jul 8, 2012 at 12:53 PM, David Abbott wrote: > On Sun, Jul 8, 2012 at 12:49 PM, Michael Mol wrote: >> I filed bug 425330. Nothing special, I'm just a heavy user and >> advocate of IPv6, and I figured I ought to file the bug locally so >> that the Gentoo dev associated with it can run it up the flagpole to >> upstream. >> >> I just saw that it's now CC'd to "maintainer-needed". I don't like it >> when packages I use lack at least an interested liason between Gentoo >> and the package's upstream. >> >> I'm not a Gentoo dev in any official sense. I've never been a package >> maintainer for any distro. I've just been a Gentoo user for 2-3 years, >> a Linux user for ten years, and a C++-on-Windows dev for the past five >> years. But I'd be interested in giving it a shot. >> >> What's the next step? >> > > Hi Michael, > You could contact the "Gentoo Proxy Maintaining Team" > http://www.gentoo.org/proj/en/qa/proxy-maintainers/index.xml > > HTH, That's what I needed to know, so yes. Contacted, thanks. :) -- :wq
Re: [gentoo-dev] "maintainer needed" for app-emul/playonlinux
On Sun, Jul 8, 2012 at 12:49 PM, Michael Mol wrote: > I filed bug 425330. Nothing special, I'm just a heavy user and > advocate of IPv6, and I figured I ought to file the bug locally so > that the Gentoo dev associated with it can run it up the flagpole to > upstream. > > I just saw that it's now CC'd to "maintainer-needed". I don't like it > when packages I use lack at least an interested liason between Gentoo > and the package's upstream. > > I'm not a Gentoo dev in any official sense. I've never been a package > maintainer for any distro. I've just been a Gentoo user for 2-3 years, > a Linux user for ten years, and a C++-on-Windows dev for the past five > years. But I'd be interested in giving it a shot. > > What's the next step? > > -- > :wq Hi Michael, You could contact the "Gentoo Proxy Maintaining Team" http://www.gentoo.org/proj/en/qa/proxy-maintainers/index.xml HTH, David
[gentoo-dev] "maintainer needed" for app-emul/playonlinux
I filed bug 425330. Nothing special, I'm just a heavy user and advocate of IPv6, and I figured I ought to file the bug locally so that the Gentoo dev associated with it can run it up the flagpole to upstream. I just saw that it's now CC'd to "maintainer-needed". I don't like it when packages I use lack at least an interested liason between Gentoo and the package's upstream. I'm not a Gentoo dev in any official sense. I've never been a package maintainer for any distro. I've just been a Gentoo user for 2-3 years, a Linux user for ten years, and a C++-on-Windows dev for the past five years. But I'd be interested in giving it a shot. What's the next step? -- :wq
Re: [gentoo-dev] About ppc status and stable keywords
On 07/08/2012 07:55 AM, Pacho Ramos wrote: For a long time I have been observing ppc team reacts really slowly to stabilization requests, causing us to need to keep old ebuilds for a long time. Maybe it's time to start dropping stable keywords for ppc as looks like team doesn't have enough man power to keep stable updated. What do you think? I have access to native ppc and ppc64 (although the latter is in poorer condition). I could join that team and stabilize important ebuilds. My interest in ppc comes from various devices that still use ppc like the mikrotik RB1000U. Can I join the team? -- Anthony G. Basile, Ph. D. Chair of Information Technology D'Youville College Buffalo, NY 14201 (716) 829-8197
[gentoo-dev] About ppc status and stable keywords
For a long time I have been observing ppc team reacts really slowly to stabilization requests, causing us to need to keep old ebuilds for a long time. Maybe it's time to start dropping stable keywords for ppc as looks like team doesn't have enough man power to keep stable updated. What do you think? signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: Kernel compiles and you
Michał Górny posted on Wed, 04 Jul 2012 22:38:50 +0200 as excerpted: > On Wed, 4 Jul 2012 20:06:58 +0200 Tobias Klausmann > wrote: > >> On Wed, 04 Jul 2012, Michał Górny wrote: >> > There's a very simple yet custom solution I'm using. Shortly saying: >> > checkout the kernel git to /usr/src/linux and chown to your user. As >> > far as it goes, it's superior to having kernel sources installed by >> > ebuilds. >> > >> > I just have to remember to do 'git fetch' from time to time and 'git >> > merge' whenever a new version is tagged. >> >> It is also beyond the package manager's control. That means users who >> want to just configure their kernel (and run point releases otherwise) >> have to actively check for new tags/versions. > > True. I think that's the direction I should look into improving. > >> Aside from that the git tree is not exactly lightweight: my current 2.6 >> checkout weighs in at 1.4G whereas the unpacked tar is 512M. > > Well, that's the other problem. On the other hand, you usually have to > have that 1G free anyway unless you intend to manually unmerge the > previous *-sources before installing the new one. And the time needed to > do that... git is so much faster. I'll second the git being faster bit. What's especially nice about it is that checking out and building any arbitrary tag (release or rc), or for that matter, doing a bisect down to an individual commit, if you're trying to track down some issue or other, is really easy. [1] But the main reason for this reply is to add this idea: Here, I have my regular user, and I have my admin-hat user. My regular user has sudo locked down quite strictly, with a password required for anything not specific parameter locked, etc. But, the one thing the regular usr CAN do, is sudo (with password) to the admin user. Additionally, my regular user isn't in the portage, wheel, etc, groups either (and polkit is generally locked down for it as well), so it really is quite privilege-locked, EXCEPT that it can sudo to admin. The admin user then has unrestricted passwordless sudo access. Basically root, except that I can type the command unprivileged first, then when for instance the rm gives me the expected permissions error, I can see that it's what I did indeed intend to rm, and arrow-up, home, sudo in front, to actually do it. The admin user is then what I use to git pull and build the kernel, so that's the only user (other than root) with write access to the kernel sources. My normal user doesn't have that access, thus avoiding the normal-user-writable security issue mentioned in your (klausman's) blog. Since that admin user then has unrestricted passwordless sudo, sudoing (from that admin user) to root for the actual install is trivial. Meanwhile, I actually have a set of kernel maintenance helper scripts that I use to update, configure (either oldconfig for the update or just to change something...), build and install the kernel. They're not ready for use by the general public yet, but they're a reasonable start, including a configuration file for most stuff one might want to change (where the kernel dir is located, where the output dir is located so as to keep the sources dir itself clean if so desired, whether to auto- mount /boot for installation, etc). There's even provision for automatically applying patches from a user patches dir! =:^) Since I've been running a git kernel for several years now, the git- kernel scripts are current, but I did start on the scripts back when I was still using tarballs, so there's scripts that automate most of that, as well, tho they're a bit stale now as I've not actually run/tested them in a couple years (but I did try to update them for the 3.0 kernel, etc). If you'd like, I can email them. As I said, they're not really fit for public consumption yet, but it's a reasonable start including a config file, and I use it for maintaining my systems (both x86 and amd64, separate output dirs based on the bash ARCH variable) here, with a maturity and development over several years, so if you're interested in /making/ them fit for public consumption, it'd certainly save quite some days work over starting from scratch. Obviously I'm running/testing the scripts as a gentoo user, but other than perhaps some of the config file comments, there's not a whole lot specific to gentoo about 'em. --- [1] I routinely run live-git kernels, but don't like to run anything before rc1 until some days later, just in case. So when a release comes out, I'll often update a couple days into the new cycle, and then simply checkout and build the release tag. Then sometime after rc1 or rc2, I update again, and test from there. I figure if I need to bisect anything, news of any too drastic data-eating bugs pre-rc1 should be available, and I can then bisect back into the previously blackout period with a bit more confidence. -- Duncan - List replies preferred. No HTML
Re: [gentoo-dev] About tests needing internet connection to run
On Sat, 7 Jul 2012 17:46:49 -0400 Alexandre Rostovtsev wrote: > On Sat, Jul 7, 2012 at 11:21 AM, Michał Górny > wrote: > > To be honest, I think the first thing to do would be fixing the test > > suites to skip tests which fail due to internet connection being > > unavailable. Well, there would still be question how to reliably > > determine that... > > For some packages, e.g. geocode-glib, which is basically a library for > calling a particular web service from C code, running the test suite > without network access is almost pointless. (Unless, of course, you > feel like implementing a clone of that web service just to run the > test suite.) > > I don't like tests that need network access, but in a few cases, they > are the only to automatically verify that a package works. And 'skipped' tests simply mean that the test suite was unable to verify whether the package works for one reason or another. Well, other than build-time failures and a few possible runtime failures. You just have to ensure that it correctly notices the difference between 'no internet' and 'no matching API there'. Probably the domain resolution failure should be the borderline. Well, and I don't really mind having PROPERTIES about it. Some users may actually want to know that tests could do better with internet access. -- Best regards, Michał Górny signature.asc Description: PGP signature
