[gentoo-dev] Going inactive
Hi, I've been too busy with other things to work on Gentoo for quite some time and this isn't going to change now that I've just picked up new study and work commitments. So I'm gonna drop out of the IRC rooms and stop checking this email account (which is spammed to death). I guess this means my access will be removed at some point, although I'd welcome the idea of it staying put in case I can find time in future. Thanks to everyone who taught me something or helped with my projects. I learned a huge amount through this distro and community. Cya around! Daniel
Re: [gentoo-dev] About udev-145: new features / extras and kernel requirements
Matthias Schwarzott wrote: Up to now I have just added use-flag extras to control these. But I suppose that udev-acl and maybe gudev is a hard requirement for newer hal or devicekit versions. And upstream thinks these should be enabled by default. I've been playing with Fedora lately and they split it in 3: udev, libudev, libgudev. You will find that some apps will start requiring libgudev unconditionally. For example, the upcoming NetworkManager 0.8. Daniel
Re: [gentoo-dev] linux-info.eclass: lacking sources, config checks and module building
Robin H. Johnson wrote: It does NOT check /proc/config.gz presently. The original logic against not checking /proc was that we were targeting the kernel being built, but that's moot given the use of `uname -r` in OUTPUT_DIR. That seems like a bug. OUTPUT_DIR should default to unset which would cause the internal KV_OUT_DIR to be set to KV_DIR. However I can see from the code that's not the case, and it's not clear why. Relying on uname -r or /proc/config.gz is still something we should avoid (unless user configured, perhaps, or in very exceptional circumstances) however it looks like this isn't a change that you are proposing. Thanks for working on this. It's a sensitive area so please take care and help people pick up the pieces. If you are really motivated, it might be worth rethinking the whole separate output directory implementation. Daniel
[gentoo-dev] 2.6.29 stable plans
I'm planning to request the stabling of gentoo-sources-2.6.29 on 23rd may, 1 week from now. We have no known regressions in the kernel. Regressions in external packages in the stable tree are tracked in bug #264722. Please fix these asap. Daniel
Re: [gentoo-dev] Project summaries- kernel
Christian Faulhammer wrote: Hi, any project lead/member can post an answer to this mail for a status report: kernel: Continues to be a small team with desires to grow. Our processes scale well but recruitment does not. Only real task is to handle gentoo-sources, 90% of the time is handling upstream bugs reported by users (the kernel is so big and fast-moving that in order to be more effective, we have to do a certain amount of work before sending users upstream). gentoo-sources patchset continues to shrink, we're very close to vanilla which is great from a working-with-upstream perspective. I'm not finding much time to devote to the project due to other commitments (seems to be an ongoing curse that occurs to anyone taking the 'lead' position). Not likely to change very soon :( Happy to consider proven contributors for taking over the lead position, past present and future. Mike Pagano continues to be a driving force, continually attacking bugs, wranging patches and making releases. Recruited George Kadianakis and Markos Chandras who have helped a lot. Need to spend more time integrating them and delegating more from me and Mike. Overall in good shape with 22 open bugs. One real drain for us is dealing with crazy gentoo devs who decide to maintain packages of kernel code outside of the kernel (i.e. external kernel drivers). These break really often because these external packages use the internal kernel API which is deliberately unstable. Many maintainers are responsive, but very often we have to deal with unresponsive maintainers or packages which simply can't be fixed easily, this eats a lot of our time, slows down stabling processes, and results in a bad experience for our users. Asking for extinction of all such packages is probably unreasonable, but it would be good to see them kept out of the stable tree or something like that, and we could do a better job at communicating these maintenance difficulties to our users (use at your own risk, this will probably break next week). My ideas for potential goals/improvements, totally dependent on time and interest from team members: - get bugs upstream faster - fewer and fewer bugs - accelerate stabling to the previous rate of 3 weeks after every major release from upstream. (quite time consuming) - speed up regression handling, prioritise higher - work more with bugs that we send upstream, right now they get a bit neglected by us and sometimes by upstream (probably have 30-40 bugs in this state) - move genpatches website to independent location, automatically generated, with permanent/reliable tarball hosting kernel-misc: Maintains various userspace packages that are tightly linked to the kernel e.g. jfsutils, module-rebuild, fuse, also the kernel-2, linux-info and linux-mod eclasses. Mostly neglected. Some packages have active maintainers, thanks! For the others I usually do a bug sweep every 6 months or so, taking out the easy bugs and applying patches from users. Goals/improvements: find people to take care of this stuff..preferably people who can just step in and get on with it without me needing to find recruitment time.
Re: [gentoo-dev] GLI Officially Deprecated
Petteri Räty wrote: Why wasn't this sent to gentoo-dev-announce? It should be posted on front page gentoo.org if that is not already in the works. Thanks, Daniel
[gentoo-dev] Linux 2.6.28 stable plans
2.6.28 is out, happy holidays.. The usual things: 1. Bugs in non-kernel packages in the stable tree that appear due to this upgrade are tracked at bug #252467 2. Tentative stable date is January 15th, will be held back if we have bad kernel regressions etc, but jan 15th is the aim. If your package breaks due to this upgrade, it's your responsibility to fix this in the stable tree before this date. You can ask me for help. As long as it's gone jan 15th, your broken packages will not hold back the kernel from going stable... 3. Who's brave enough to put ext4 on / ? :) Daniel
Re: [gentoo-dev] Linux 2.6.28 stable plans
Tobias Klausmann wrote: All .28 series kernels (all rc kernels and the final one, too) do not compile on Alpha at all. Please file this at the Gentoo bugzilla as well, so that we can keep track. We can possibly even help fix it. cheers, Daniel
Re: [gentoo-dev] EAPI 2 policy for portage tree
Robert R. Russell wrote: My answer is a simple example from my own system. My current system uses a motherboard that is around 6 months old and is only correctly supported by the latest ~arch gentoo-sources. The add on video card, a 1 to 2 year old nvidia card, works great with x11-drivers/xf86-video-nv-2.1.12 as long as I am using the latest ~arch xorg-x11. The internal video card isn't even recognized by the xf86-video-intel drivers except the ~arch versions. Even some of the packages I use for school work such as kile have bugfixes and other improvements between the versions in stable and ~arch that are important to getting work done. The ability to selectively upgrade only the specific packages needed to get a working system is a major strength for Gentoo. With all of these problems, it sounds like in your case, our stable tree isn't living up to our hopes. *This* is the problem you should be bringing to our attention, instead of complications with portage and EAPI. I looked up your email address on bugzilla, hoping to find at least 5 bug reports, one for each of the problems you describe above. I could only find one (and even that one doesn't really make clear the fact that the current stable has problems which is affecting your schoolwork). Please could you fix that? Thanks! Daniel
Re: [gentoo-dev] EAPI 2 policy for portage tree
why offlist? Robert R. Russell wrote: Stabilization reports for ~xorg-x11 and the ~xf86-video-intel drivers aren't likely to go any where given the number of issues people are asking about on the forums But the important thing is that you notify the maintainers that you're in trouble. That may encourage them to focus more on the remaining blockers. But at the very minimum it makes them aware, and it serves as documentation for others who may hit the same problem. and the time taken to fix even simple bugs like this one https://bugs.gentoo.org/show_bug.cgi?id=227895 You can't judge the whole of Gentoo on your experience with one bug. It is also not an excuse for not filing the bugs, even if they take a while to get fixed. A user reporting the problem is just as significant as a developer fixing it. A more accurate guide to what the devs want on a filed bug report or a reply to a bug report( patches to the ebuilds, patches to the software, and the like) would help me out in giving the devs what they need or want. Suggestions appreciated. My advice would be, if something is broken, then file a bug (after doing some sanity checking to attempt to confirm it's not your fault, and nobody else has filed it). As far as the kile stabilization report, what priority do stabilization reports need? Do I need to give exact details on what doesn't work in the old version compared to the new version, which is unlikely because I can't even remember the problem that forced an upgrade? I wouldn't bother with the priority field. But information on the benefits and importance of stabling is important. Give developers motivation to fix the bug, by describing what problems the stabilisation solves. The end of school will also help with the bug filling rate going up in the next week or so. Great! Daniel
Re: [gentoo-dev] Linux 2.6.27 stabilisation plans
Daniel Drake wrote: I'm tentatively planning to request that gentoo-sources-2.6.27 gets marked stable on x86+amd64 on December 15th, assuming we have fixed all regressions (we have some open, which will hopefully be fixed soon). We're still on track for December 15th stabling, so please make sure your package is tested and fixed in the stable tree: Kernel-dependent packages that are broken by this upgrade are tracked at https://bugs.gentoo.org/show_bug.cgi?id=242708 Please help us fix these in the stable tree in advance of the stabling date.
Re: [gentoo-dev] sandbox-1.3 testing request
Mike Frysinger wrote: can people who feel adventurous unmask sandbox-1.3.2 and give it a spin on their systems before i unmask it for everyone ... Thanks for looking after this important package. 1.3.2 isn't in CVS, did you mean 1.3.1? Daniel
[gentoo-dev] net-misc/arpstar facing removal
It's unmaintained and broken against recent kernels. It would be nice if someone could step up and replace it by adding and maintaining a package for arpon: http://arpon.sourceforge.net/ which I guess it not a kernel module, yay I'm planning to add arpstar to package.mask on December 11th, and remove from tree at the end of the month. Daniel
Re: [gentoo-dev] Looking for help with kernel maintenance
Nicolas, Nicolas Sebrecht wrote: I would like to go further in the Linux kernel internal comprehension. Could someone tell me where to find a good starting free documentation ? Most of the documentations I've found are about old kernel versions (2.4 series). Ask this on the gentoo-kernel list, please. I'm happy to help, but there are many people there who would also appreciate being part of the discussion. Thanks, Daniel
[gentoo-dev] Linux 2.6.27 stabilisation plans
Hi, I'm tentatively planning to request that gentoo-sources-2.6.27 gets marked stable on x86+amd64 on December 15th, assuming we have fixed all regressions (we have some open, which will hopefully be fixed soon). Kernel-dependent packages that are broken by this upgrade are tracked at https://bugs.gentoo.org/show_bug.cgi?id=242708 Please help us fix these in the stable tree in advance of the stabling date. Thanks, Daniel
[gentoo-dev] Looking for help with kernel maintenance
Hi, I'm looking to find one or more people to help out with gentoo-sources-2.6 maintenance (our primary supported kernel). Right now, me and Mike Pagano do most of the kernel work. I disappear fairly often and it's always good to have more than 1 active person on the project. I'm looking for someone with at least: - Interest in kernel stuff, or a desire to become interested - Time to put towards the tasks - Enthusiasm to ask lots of questions rather than let stuff sit around - Basic experience with bugzilla - Basic kernel experience (i.e. you can compile your own) Having knowledge of kernel internals or experience with kernel hacking are NOT requirements because if you have time, interest and ask a lot of questions then these will come anyway. A lot of the work doesn't involve technical stuff, plus I was certainly very clueless about all this when I originally got involved a few years ago. Being an existing Gentoo developer is not a requirement. Most of the work is done on bugzilla and via email. This may be a good opportunity to get involved with development and later become a Gentoo developer for those that are interested. It's an enjoyable task, you get to interact with a lot of very intelligent people upstream and you end up learning a lot. Email me ([EMAIL PROTECTED]) if you are interested! Thanks, Daniel
[gentoo-dev] packages up for grabs
Hi, I want to devote more time to the kernel project and other things, so I'm looking for people or herds to take ebuild maintainership of the following packages: dev-dotnet/gsf-sharp dev-dotnet/evolution-sharp dev-util/rej net-wireless/zd1211-firmware sys-block/viaideinfo sys-fs/udftools x11-misc/touchcal any volunteers? :) Otherwise I'll push them towards maintainer-needed in a couple of weeks time. Thanks, Daniel
[gentoo-dev] Linux 2.6.26 stabilization
Hi, On November 5th, I'll request that the latest revision of gentoo-sources-2.6.26 goes stable on x86 and amd64. The UK will celebrate the event with big bonfires and fireworks. If there are any unfixed 2.6.26 regressions, please alert us, but things seem to be nicely under control. As for external packages that rely on kernel sources, if there is any remaining breakage in the stable tree please make sure an appropriate bug is blocking #232070. Daniel
Re: [gentoo-dev] Fwd: Retiring...
Carlos Silva wrote: I'm really sorry to leave you guys but my current life isn't compatible with working on Gentoo. Live is too busy to give Gentoo the time it deserves. I really liked to work with all of you. I'll try to contribute as much as possible via bugzzie. If anyone need any kind of help/information from me, just contact me to this email... Thanks for your help with everything, please pop in from time to time Daniel -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] lastrite: net-fs/coda-kernel (treecleaners)
Samuli Suominen wrote: # Samuli Suominen [EMAIL PROTECTED] (21 Apr 2008) # Masked by treecleaners for bug 160267. Removed in ~60 days. # Has been included in 2.6 kernel series. net-fs/coda-kernel Are you sure? codafs has been in the kernel for years but I think the external package is something different. -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Linux 2.6.25 info
2.6.25 was released today, gentoo-sources-2.6.25 is now in portage. As usual this will break some packages in the portage tree (ones that include kernel code), the tracker for such issues is here: http://bugs.gentoo.org/show_bug.cgi?id=218127 Jakub normally does a wonderful job of herding all such bugs, but it looks like he isn't around at the moment. Please help out by adding your bugs there, assuming that your package is in the stable tree and the current stable one works on 2.6.24. As usual I hope to start thinking about 2.6.25 stabling in 3 weeks time (that'll be May 8th) but this is of course subject to the state of affairs when we get that far :) Daniel -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Linux kernel 2.6.24 plans
2.6.24 has been released, gentoo-sources-2.6.24 will be in portage this afternoon. Tentatively hoping to mark this stable after 5 weeks (i.e. 29th February) but it may be done a little sooner. We are hoping to get this stable for inclusion in 2008.0 (and to be the kernel the livecd runs on). Testing and bug reports appreciated. The above plans will obviously changed if there are significant unsolved regressions in this release. As usual, kernel modules that are in portage (i.e. outside of the kernel) are likely to break, and the tracker bug for those issues is here: https://bugs.gentoo.org/show_bug.cgi?id=207383 I will spend some time providing direction on such issues, but is up to the package maintainers to fix these problems. Daniel -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] app-misc/beagle (temporary?) maintainer wanted
Hi, I'm the current beagle maintainer but am struggling to find the time needed for the simple maintenance efforts required. Is anyone interested in taking over here? A prospective developer (bheekling) would be interested in maintaining this package in future, but right now he does not have enough time for the recruitment process. He does plan to get recruited later, and he's helping out on existing bugs at the moment. Anyone interested in stepping up in the meantime, perhaps just proxy-maintainership style? Thanks, Daniel -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] www-apps/b2evolution maintainer wanted
Hi, Is anyone interested in taking the b2evolution blog engine webapp off my back? Steve Dibb has been doing almost all of the planet maintenance for the last eon, and I don't really have an easy environment to test new ebuilds etc. Thanks, Daniel -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
Piotr Jaroszyński wrote: I have updated the GLEP, hopefully it is less confusing now and hence the discussion will be more technical. As I still didn't get the ok to commit from our glep folks, read the most current version here: http://dev.gentoo.org/~peper/glep-0055.html http://dev.gentoo.org/~peper/glep-0055.txt Haven't read the previous discussion, apologies if this has been clarified already, but I think it would be good to answer the following question in the GLEP: Why (in terms of your GLEP) are you still allowing ebuilds to set EAPI inside the ebuild? It seems that one approach you might take is to move the EAPI selection into the filename and remove it from the ebuild itself, and it's not clear to me why your proposal isn't exactly that. Thanks, Daniel -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: maintainer-wanted bugcount
Markus Ullmann wrote: K, to sum it up then, everything stays like it is atm. I think that makes sense. Yes, it's unrealistic for us to be able to handle all of them, but I think that's a perfectly reasonable situation. It's common for open source projects to have an excess of feature requests; it's a natural imbalance given that there are significantly more users than developers in almost all cases. Daniel -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] More general interface to use flags
Marijn Schouten (hkBst) wrote:
Hi list,
the current interface to use flags, useq, usev, use_with, use_enable, as
defined in /usr/lib/portage/bin/ebuild.sh lacks generality. The common thing
is testing a use flag and possibly echoing a string, but there is no function
that implements this common behaviour.
I propose that we add such a function. Proposed name for the function is
ifuse.
So these modifications are just cleanups to portage internals and would
not affect the interfaces or behaviour of use/use_with/...?
I also propose to add the utility function ifv which is useful for writing
concise and clean code.
These additions would allow you to easily define your own function for
processing use flags in ebuilds and eclasses. One such example is
use_mime() {
local WORD=$(ifv $2 $2 $1)
ifuse $1 ${WORD};
}
for generating a string of ';'-separated mime-types based on use flags.
The explanation of this function is:
#set WORD to argument 2 or if that is empty to argument 1
#output ${WORD}; if use flag $1 is set (or if it starts with ! and is unset)
#otherwise don't output anything
I don't quite understand what this function does. What ebuild nastiness
does it replace, or what does it allow that was not previously possible?
(can you give an example?)
Thanks,
Daniel
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Resolving HAL vs. pciutils/usbutils
Robin H. Johnson wrote:
Heya,
So now this is not a flamewar.
Jakub was originally going to complain at me for the upstream usbutils
adding support for gzipped usb.ids files, but a group of us (myself,
dsd, jakub, leio, steev) had a discussion about it, and came up with a
solution that both ends the breakage for direct users (HAL and others),
and provides forward momentum.
So firstly, what's the real problem? The original complaint came up
because HAL expected the uncompressed file to exist as pci.ids, and
wasn't ready to look at pci.ids.gz. While this caused breakage, it was
only a warning sign that there was a deeper problem.
I don't feel strongly enough to make an objection to your commit, but I
think pciutils is doing the right thing, and despite me and Mike putting
a hours into getting a decent HAL patch together the response I got was
that as upstream they are simply not interested (no technical or
logical objections provided), so I don't feel you should be putting
workarounds in pciutils just to make HAL happy.
Especially because HAL really doesn't use pci.ids for anything useful. I
am attaching a HAL ebuild patch which is the approach I'm in favour of
and first mentioned several months ago. It does not require any HAL
patches or pciutils modifications. It stems from the fact that really
HAL doesn't really do anything useful with the ID-to-name mappings
provided in pci.ids. It makes that HAL bug disappear with the click of
the fingers. I didn't really get any proper answer why our HAL
maintainers weren't keen on this when I first mentioned it.
Daniel
--- hal-0.5.9-r1.ebuild.orig2007-10-31 10:34:34.0 +
+++ hal-0.5.9-r1.ebuild 2007-10-31 10:46:15.0 +
@@ -80,13 +80,6 @@ function notify_inotify() {
}
pkg_setup() {
- if ! built_with_use --missing false sys-apps/pciutils hal ; then
- if built_with_use --missing false sys-apps/pciutils zlib ; then
- eerror You MUST build sys-apps/pciutils without the
zlib USE flag
- die You MUST build sys-apps/pciutils without the zlib
USE flag
- fi
- fi
-
if use kernel_linux; then
kernel_is ge 2 6 17 || ewarn HAL requires a kernel version
2.6.17 or newer
@@ -147,6 +140,7 @@ src_unpack() {
src_compile() {
local backend=
local acpi=
+ local myconf=
# TODO :: policykit should have a pam useflag
append-flags -rdynamic
@@ -164,6 +158,15 @@ src_compile() {
acpi=--disable-acpi-proc --disable-acpi-acpid
fi
+ if [[ ! -e ${ROOT}/usr/share/misc/pci.ids ]]; then
+ myconf=--disable-pci-ids
+ elog It looks like you've built pciutils with the zlib USE
flag
+ elog meaning that your /usr/share/misc/pci.ids file is
compressed
+ elog and incompatible with HAL. You almost certainly won't
notice
+ elog any feature loss here, but if you do, just re-emerge
pciutils
+ elog without the zlib flag, then re-emerge hal.
+ fi
+
econf --disable-policy-kit \
--docdir=/usr/share/doc/${PF} \
--with-os-type=gentoo \
@@ -182,6 +185,7 @@ src_compile() {
$(use_enable selinux) \
--disable-console-kit \
${acpi} \
+ $myconf \
|| die configure failed
#$(use_enable pam console-kit)
Re: [gentoo-dev] Resolving HAL vs. pciutils/usbutils
Wulf C. Krueger wrote: The question is not if some software is doing the right thing or not but if our packages behave like they should for our users. There is also value in satisfying and not deviating away from upstream, as well as respecting values of upstream decisions (such as offering compressed IDs to save bandwidth and disk space). But yes, the correct software behaviour is useful too, and I wouldn't be pushing a solution that caused a degradation in user experience. Neither is the question if any of us are happy but if our *users* are happy when their installation process breaks because of that HAL bug. We don't make HAL, its upstream or anyone but our users happy. Our obligation is primarily to them. pciutils has an upstream too. I am attaching a HAL ebuild patch which is the approach ... that still potentially allows things to break because of animosities among ourselves. HAL handles the missing file condition at runtime if it was compiled with support for it. So, there will be no breakage under circumstances where the package was built for a different box. No issue here. We have a good solution, namely robbat2's, which will make sure things don't break for our users. IMO, that's the way to go because the other approaches make us look bad and are unworthy of a distribution that wants to be taken seriously. Things already work for the users with the hal useflag for pciutils, and things will also work with my patch in a slightly nicer/more robust way, without having to extend the HAL issue to the pciutils package. I'm going to drop out of this discussion here, just wanted to point out that there is both technical reasoning behind my suggestion, no technical flaws that I know of, and no degradation in user experience. Only in distant corner cases would someone notice a difference, and the fix is easy and documented by the ebuild messages. Daniel -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Resolving HAL vs. pciutils/usbutils
Doug Goldstein wrote: When HAL evaluated the usage of libpci the following issues were identified: 1) increased memory usage, to the point that HAL was not usable on the OLPC project I was only ever aware of concerns that memory usage might be high, but wasn't aware it caused specific problems. I went through the first 3 pages of google results for pciutils inurl:hal site:lists.freedesktop.org libpci inurl:hal site:lists.freedesktop.org and didn't see anything. Maybe it was discussed elsewhere. Anyway, if this did happen once, it doesn't seem to happen any more, see below. 2) ABI breakage between patch revisions (i.e. x.y.z and x.y.z+1 were not ABI compatible) This doesn't matter when you statically link against the library, as long as the API doesn't change. The API that is used in Mike's patch does not seem to have changed for a long time. (Nevertheless, see my notes under the following item -- this will be solved when the next one is solved.) 3) no shared library This is a fair point, but I thought it was never raised as an objection, I didn't think it was actually a blocker for acceptance. Especially given that parts of HAL already statically link against libpci. I just looked over the threads again and I now see this: http://lists.freedesktop.org/archives/hal/2007-June/008836.html I apologise, I must have missed that before. OK, so having a dynamic libpci is an outstanding requirement for the patch. I will follow up with pciutils upstream about the current state of that. 4) the library calls exit() when it encounters an error in parsing it's own pci.ids file which would kill the whole app using it. There might have been more. I don't remember. Refer to ML discussions and refer to IRC logs with me. I looked over them, I don't see any others. Now Mike (vapier) rectified #4 several pciutils releases ago by providing a callback function that we could define which would override the default exit() behavior. I still think it's sub-par to have an utility library call exit() by default but whatever. Yeah. You were told by me and the HAL ML that once #2 and #3 are rectified and if you could provide some basic memory usage information along with your patch (i.e. show #1 isn't true anymore) that we would happily accept your patch. You addressed #1 on the mailing list with a simple statement, which I will paraphrase. It doesn't use more memory on my machine. To which Danny K asked if you could provide some basic data behind that and you never did. I did: http://lists.freedesktop.org/archives/hal/2007-June/008852.html http://lists.freedesktop.org/archives/hal/2007-June/008861.html Anyway, apologies for the oversight on the shared library thing -- it appears it wasn't total silent rejection after all. I'll let you know where that leads. Thanks, Daniel -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-cluster/drbd: ChangeLog drbd-8.0.6.ebuild
Donnie Berkholz wrote:
cd ${S}
cp -R /usr/src/linux-${KV} ${WORKDIR}
emake -j1 KDIR=/${WORKDIR}/linux-${KV} O=${KBUILD_OUTPUT} || die
compile problem
This is not the way that linux-mod is intended to be used. You should be
setting MODULE_NAMES, BUILD_PARAMS, BUILD_TARGETS, etc. Then
linux_mod_src_compile and src_install will handle compilation and
installation of the module.
Look at coda-kernel for a simple example.
Daniel
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] Adding /etc/udev/rules.d/ to CONFIG_PROTECT_MASK
I like the idea of adding this to CONFIG_PROTECT_MASK. Matthias Schwarzott wrote: Only problem I see: What to do with people having custom modifications inside the default rules-files? I can't think of any cases where the user would have to do this (they can make custom modifications in their own files). Could we modify the rules files installed by udev to include a comment at the top warning that a default portage configuration will overwrite any changes that the user makes? Daniel -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] 2.6.22 stable plans
Donnie Berkholz wrote: so next time dsd (or whoever the ninja kernel maintainer happens to be at the time) says hey i plan on stabilizing Linux x.y.z and someone goes wait, you cant until we get closed source driver package foo working, the reply is of course blow it out your arse^H^H^H^Htalk to the package maintainer, this will not hold up stabilization efforts If we're gonna go with this policy here, I'm also going to adopt it for X so we don't get stuck in limbo as happened fairly recently. This is how it has been for a while, and not only closed source drivers. We have many open source kernel drivers/filesystems in the tree which regularly break with new kernel releases. When these packages break in this way, it is a bug in such packages, not in the kernel. [For those wondering why the kernel keeps changing, see Documentation/stable-api-nonsense.txt : it is by design, maintaining kernel code outside of the kernel is discouraged for this reason, solution is get it in the kernel] Maintainers of these packages got unhappy that they didn't really have warning when new kernels were going stable, so I started announcing that (and usually giving more notice on gentoo-dev than this time around, sorry about that). That helped, but trying to encourage maintainers to fix their stuff every few weeks gets old and some maintainers become less responsive. Kernels go stable anyway and so users complain. I now take it a step further, and create package regression tracker bugs for each kernel release. bug #184683 is the 2.6.22 one, a little smaller than usual. For each bug that gets added to the tracker, I comment on any patches that have been posted (e.g. that's the correct fix) or if there aren't already patches, I explain how to fix the code based on the compile error. This is work I'd rather not do (I really don't care about your package), but seems to work relatively well. There are times when after I 'approve' a patch, another developer asks me to commit it. I think that's a little unreasonable. I'm not prepared to go *that* far at the moment, especially as I usually can't test the package in question. The model seems to work relatively well. One associated challenge is making sure maintainers fix their packages in the stable tree (not only unstable) before stabilization takes place, but that has certainly been improving lately, e.g. Stefan did a great job fixing up many external wireless drivers this time around, and I didn't have to reopen any of the bugs :) All that aside, my advice for developers considering maintaining kernel code in portage outside of the kernel still remains as don't do it. Your package grows bugs overnight. It's a continual challenge trying to keep up, and it's a headache for me trying to poke you into action. Or, if you really must do this, never mark your package stable (that way I can ignore it). Daniel -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] 2.6.22 stable plans
Greg KH wrote: Is speakup finally dropped from the gentoo tree in this release? Yes Was there a reason for this? It no longer compiles, as the legacy way of accessing serial ports disappeared, serial is now a platform device. I can't see an easy fix. It may return in future, in a different form. I suggested some future direction here: http://speech.braille.uwo.ca/pipermail/speakup/2007-July/044137.html Daniel -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] 2.6.22 stable plans
Greg KH wrote: Ok, thanks for pointing me at this. I've already started discussing this with a few of the users on that list. I tried a number of years to get this code into shape enough to get into the main kernel tree. Looks like I'll try this again. Let me know if anything comes of it. I'm interested in helping development again, but don't presently have enough time to do the restructuring needed now. Daniel -- [EMAIL PROTECTED] mailing list
[gentoo-dev] 2.6.22 stable plans
On Thursday I plan to request that the x86 and amd64 arch teams mark the latest gentoo-sources-2.6.22 revision stable. We have no reported regressions for this kernel release. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] baselayout-2 stablisation plans
Roy Marples wrote: This is just a heads up for getting baselayout-2 stable. Next week I plan to put baselayout-2.0.0_rc1 into the tree without any keywords and it will be removed from package.mask (keeping the current alphas masked though). Arch teams will then be pinged on a bug to keyword baselayout-2. You should find someone from the GDP to write some user migration docs. The two things that spring to mind are having to use init scripts for device-mapper and crypto fs stuff (I can see lots of unbootable systems for those who don't realise this...) and having to compile the new splashutils *after* baselayout to keep fbsplash working. Thanks for all your work on baselayout-2! Daniel -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] baselayout-2 stablisation plans
Roy Marples wrote: I don't actually know how to set those up or what the migration path would be. Maybe devzero and strerror could document this as I understand they do this. I manage systems with a single RAID 0 stripe (not dmraid) managed by device-mapper. When upgrading baselayout, we also have to upgrade to a recent device-mapper version which provides the device-mapper init script. Then we must run: # rc-update add device-mapper boot If we don't, we get an unbootable system. Daniel -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] ML changes
Mike Doty wrote: All- We're going to change the -dev mailing list from completely open to where only devs can post, but any dev could moderate a non-dev post. devs who moderate in bad posts will be subject to moderation themselves. in addition the gentoo-project list will be created to take over what -dev frequently becomes. there is no requirement to be on this new list. I'm not keen on this idea. I like the traditional unmoderated mailing list scheme used in open source projects everywhere, including this one at present. The Gentoo development community is much more closed than the development communities of most other open source projects (for good reasons), and I wouldn't like to see it close up further. Moderation would be used to exclude certain discussion, but the real solution for that is just to teach people to ignore the idiots. (yep, not easy in some cases!) I'm also not sure that the proposal solves any problems -- I glanced over the last few weeks of mail and didn't see any that I would reject from a moderation queue. I do like the gentoo-politics idea that came up a few weeks ago, which was to move politics off gentoo-dev and to another list, but I'd view it from another perspective (and avoid the words 'politics'): make gentoo-dev for development topics only, and have another list for the rest. But, I suspect we'd come back to the same problem on both lists, where some people are too keen to talk and deviate too far away from technical discussion. Daniel -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] RFC: Unifying the behavior of the doc use flag and document it
Mart Raudsepp wrote: gtk+ documentation rebuilding can take as much as 30 to 60 minutes with the doc USE flag for example. The benefit is cross references to glib, pango and cairo documentation - upstream can not do that as they do not know where the other docs will be found on disk. Though I should see if they can not use relative paths somehow.. You might consider moving these docs to a separate package aimed at people developing using GTK+. gtk+ would then not install these documents at all. We did something similar with kernel docs (see sys-kernel/linux-docs) and there have been no complaints so far. Daniel -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [PMS] Version Naming Clarification
Doug Goldstein wrote: Currently in the tree we have sys-fs/ntfs3g. However the proper upstream name and name referenced in every single doc in the world is ntfs-3g. I tried to rename the package however, Portage does not let me since it is invalid naming. marienz and genone informed me it's invalid with PMS as well. The version I was trying to add is ntfs-3g-1.516. Logically Portage and PMS should only consider any data after the LAST - as the version information. Would this cause problems anywhere if we had the following? sys-fs/ntfs/ntfs-3g.ebuild and sys-fs/ntfs-3g/ntfs-3g-1.516.ebuild Daniel -- [EMAIL PROTECTED] mailing list
[gentoo-dev] New herd: kernel-misc
I have created a kernel-misc herd, plus corresponding mail alias and bugzilla account. metadata for the following packages has been updated: app-admin/addpatches app-doc/linux-device-drivers app-misc/fdutils app-misc/klive app-misc/zisofs-tools dev-libs/klibc net-misc/arpstar sys-apps/kexec-tools sys-devel/sparse sys-fs/avfs sys-fs/cloop sys-fs/ecryptfs-utils sys-fs/fuse sys-fs/gnomevfs-mount sys-fs/jfsutils sys-fs/lufis sys-fs/siefs sys-fs/sshfs-fuse sys-fs/unionfs sys-kernel/ksymoops sys-kernel/linux-docs sys-process/schedtool This herd is for kernel-related stuff that doesn't fall under the realm of core kernel. For example, eclass issues, bugs for the above packages, tracking external package regressions, etc. The kernel herd remains for handling bugs with the kernel itself. It's about time we separated the 2... Daniel -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Increasing contributions and interest via personal project aggregation
Donnie Berkholz wrote: I'm sure I'm not the only one with a number of projects I'll never get to, but I'd really like them to happen anyway. I suggest we create some sort of page that aggregates all of these personal projects together, so anyone can browse through them and look for stuff that sounds fun. I'd definitely throw in a few if there were some central place. Daniel -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [news-item] Paludis 0.24
I've tried to divide up the various things being discussed here. Regarding paludis: - The syntax change in question affects =paludis-0.24 - The old syntax is still accepted - A warning message is printed to the console by paludis when the old (deprecated) syntax is detected - The warning message includes basic instructions on how to fix the deprecated syntax. - The user isn't affected by the change in any other way - The syntax can't be fixed automatically Is the above correct? Regarding the GLEP: There's reasonable doubt whether the news item can be classified as critical news, and also whether it satisfies this sentence from the GLEP: News items must only be for important changes that may cause serious upgrade or compatibility problems. However, Ciaran (the primary GLEP author) tells us that the GLEP was written with the mindset to allow these kinds of news items, i.e. some of us are misinterpreting the text. Specifically, the news is useful/beneficial/interesting to all or almost all paludis users so it should be put in place regardless of importance: It's something that is of sufficient interest to those who will read the news item that a news item is warranted. I can understand that the system may have been dreamed up with this in mind, and this certainly isn't an unreasonable design, but I don't see the corresponding text in the GLEP. Mike already suggested that we set some news standards. I think we should go further: after discussion if we do decide this kind of article is valid news, then we should carefully reword some parts of the GLEP and maybe even rename it. Adding a few examples of valid and invalid items (plus explanations why) would be beneficial as well. Regarding elog: Some people have suggested that elog is a suitable way of providing the syntax change information here. The main argument against this is that the Portage implementation isn't good enough (or perhaps isn't good enough by default, or perhaps isn't good enough in the released versions). If we can agree that the concept of elog satisfies the requirements here, then we should be focusing on fixing that rather than arguing about a different news system which isn't even implemented in the latest released version of Portage, right? Portage's news implementation might even be worse than the elog implementation... Regarding the committed news item: I spoke to Alec on IRC. Even after doing so, I don't really understand why he committed this, but it sounds like he wanted to stir things up. He doesn't acknowledge that he had any particular power to make the decision in this situation. He is surprised that nobody approached him before complaining to the council (not that any complaints have been filed in any official sense to my knowledge). He was already aware that he violated the GLEP, which requires at least 72 hours before the news item gets committed. I think someone should revert this commit until discussion has settled and the GLEP wording has been refined. Corrections appreciated. Daniel -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Looking for help with 2.6 kernel maintenance
Hi, I'm looking to find one or more people to help out with gentoo-sources-2.6 maintenance (our primary supported kernel). I'm looking for someone with at least: - Interest in kernel stuff, or a desire to become interested - Time to put towards the tasks - Enthusiasm to ask lots of questions rather than let stuff sit around - Basic experience with bugzilla - Basic kernel experience (i.e. you can compile your own) Having knowledge of kernel internals or experience with kernel hacking are not requirements because if you have time, interest and ask a lot of questions then these will come anyway. A lot of the work doesn't involve technical stuff, plus I was certainly very clueless about all this when I originally got involved a couple of years ago. Being an existing Gentoo developer is not a requirement. Most of the work is done on bugzilla and via email. This may be a good opportunity to get involved with development and later become a Gentoo developer for those that are interested. It's an enjoyable task, you get to interact with a lot of very intelligent people upstream and you end up learning a lot. I still intend to continue working on gentoo-sources in large capacity, but would like to be able to have more time to spend on more aggressive regression fixing and upstream kernel development. Contact me offlist or on IRC if you are interested. Thanks, Daniel -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Linux 2.6.21 plans
Petteri Räty wrote: Why would the kernel have to go stable before the usual month dictated by policy? Yes there are usually security bugs but you did not mention that as a reason in your post. At last check this was a recommendation, not a policy, plus nobody objected timeframe-wise before. Also, as noted in my mail I anticipate this taking more than a week from the point where we ask arch teams to consider stabling. Daniel -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Linux 2.6.21 plans
Duncan wrote: I'm running (vanilla) rc7-git10 ATM, and have two possible regressions remaining here If reproducible on gentoo-soures-2.6.21, please file bug reports for them or they will get lost. Daniel -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Planning for automatic assignment of bugs
Robin H. Johnson wrote: Case 2 - Metadata contains a single maintainer -- - The herd field is not used. - The maintainer address is used as the bugzilla assignee. At least for some packages I'm involved with, this will result in me deleting myself from metadata.xml (but I'd rather not do so). I like these bugs to go to the herd, not me directly. I get the bug mail anyway (I'm in the herd) but sometimes other herd members who see the mail jump in and help resolve the bug, for which I'm very grateful. That aside, I like having myself in the metadata alongside the herd, to point out that I am the primary maintainer within the herd for the package in question. It is also useful for others so that when they have questions about the package, they know who to approach on IRC or whatever. Apart from those small concerns, I like the idea of what you are proposing. Thanks, Daniel -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Linux 2.6.21 plans
Hi, 2.6.21 was released today. Testing muchly appreciated as usual -- please file bugs and clearly mark them as 2.6.21 regressions if that is the case. There will probably be several packages unable to compile/load due to internal kernel API changes, as usual. Please make these block bug #176188 and please do treat these bugs with relatively high priority. I'm hoping that we'll be able to return to our usual release cycle of pushing to get 2.6.21 marked stable in 3 weeks time, plus a week for ironing out the final few issues. This means that we may be pushing for 2.6.21 stable on x86 and amd64 on May 17th. If important issues come up (which they may well do), this will obviously be delayed, but do keep this date in mind. Thanks, Daniel -- [EMAIL PROTECTED] mailing list
[gentoo-dev] app-misc/klive removal
klive isn't that useful and I don't have enough time to maintain it. There are several bugs kicking about. If nobody takes over, I'll package.mask it on April 14th and remove it on April 28th. Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: New ALSA maintainers
Steve Long wrote: This is perfectly reasonable where it is a card with drivers in both, but alas-drivers supports a broader range of hardware, eg the echo audio cards (guess who has one ;) which have never been available in-kernel. These were added to the kernel as of 2.6.18. But it is still an interesting point: how does bug handling work when the drivers are actually not in the kernel at all? I think the alsa herd would be expected to handle bugs here, although I'd readily help them out as I do for other external driver maintainers. I guess I'd like some assurance that as long as alsa-drivers supports hardware for which there are no kernel drivers, it will at least be available in the portage tree. Yes, I think we can promise that, provided that the drivers have some level of support upstream too. I did a quick check and it appears that right now, there are no drivers provided by alsa-driver which are not in the kernel source. It might be worth stripping duplicate drivers out of alsa-drivers altogether so that the two might even co-exist? Would eliminate the bug duplication in any event. This is something that can be considered later, although I have my doubts... Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New ALSA maintainers
Mike Pagano wrote: Just a user opinion here, but I find the need to use unstable alsa-driver to solve a bug every now and then. This procedure would be more complicated if I had to run a development kernel to solve a sound problem. And you'll still have that option. I hope you file bugs when these scenarios occur so that we can guarantee quality in our stable tree. Thanks, Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New ALSA maintainers
Ioannis Aslanidis wrote: The fact is that the bug has been around for quite a long time now: http://bugs.gentoo.org/show_bug.cgi?id=165679 This bug is exactly the kind that makes maintaining alsa-driver (and any other out-of-kernel module) a small nightmare. It's exactly the kind of bug that never exists when people use in-kernel drivers. Maybe I misunderstood your tone and actually you are supporting the changes I have suggested? Even so I'm not sure how this relates to Doug's problem? He didn't provide any details here, and was not involved on that bug. Thanks, Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New ALSA maintainers
Ioannis Aslanidis wrote: Well, to be honest, I am neither supporter nor detractor. I think that it's upstream that should go and fix themselves. It's them who have caused all this. The bug you linked to is a natural effect of maintaining kernel drivers outside of the kernel source tree. It is not the fault of the alsa-driver maintainers (either Gentoo or upstream people who push tarballs), since they don't control the in-kernel API's. It's not the kernels fault because the kernel does not claim to maintain a stable internal API, and it actually readily claims the opposite. This is not going to change. With reference to the problems an unstable internal API causes, kernel people will give you one answer and one answer only: get your code in the kernel. Problems like these simply do not happen there. So, in this particular case, if the alsa-driver portage package did not exist, the bug in question (plus a whole series of others in the same class) simply will not ever occur. This is a good thing. ALSA guys do not support in-kernel stuff. ALSA guys being upstream alsa-project.org people? That's not correct, they are the people who put the code in the kernel. ALSA guys being downstream gentoo maintainers? That's true, since there is a separate team who maintain the kernel. Kernel guys do not support alsa stuff. Upstream kernel guys? No, they support alsa, actually most of the bugs are handled by the alsa-project.org people who generally handle them very well. Downstream kernel guys (i.e. Gentoo kernel herd)? No, we support the sound subsystem and the ALSA drivers just like all other subsystems and drivers in the kernel. Thanks, Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New ALSA maintainers
Jakub Moc wrote: It not only doesn't work for me, Bug please! :) it doesn't work for majority of people that have responded on this thread. So, something's wrong there I guess? :) I don't regard this thread as quantifiable measure. Nevertheless, lets count the number of successes and failures on this thread so far: jakub: failure aslandis: failure cardoe: failure wltjr: success nightmorph: success seemant: success kloeri: success uberlord: success gentoodoo: 1 each way I'm not asking for more people to add experiences, and I'm not saying that in-kernel is any more reliable than alsa-driver. I'm just pointing out how easy it is to misinterpret the information on a thread, and how you cannot make the above statement. Maybe this wasn't a serious comment, in which case I apologise for taking it seriously. Email sucks for communication. Hmmm, I'm not entirely sure what are you responding to here? What I said was that ALSA upstream won't accept bugs about in-kernel drivers - now how's that related to whether you (or kernel upstream) support them or not? Sorry, I can see how my response wasn't clear. When I say I support I mean that I accept the bugs on Gentoo bugzilla and work them through til resolution. So, you're correct that me supporting something is not related to any decisions made upstream. However, many bugs which pass through my support follow a common pattern: I request lots of useful info, am not able to immediately solve the problem myself, so I instruct the user how to file the bug upstream. In most cases they do so, and I track the upstream bug. And it's these cases I'm referring to - I've never seen any upstream bugs rejected due to them using in-kernel drivers. Please understand that it wouldn't make much sense for them to reject it either. There is no difference personnel-wise between the people who release alsa-driver and the people who send patches into the kernel. If they were to refuse bugs from people who use kernel drivers then why do they spend a considerable amount of time regularly synchronising patches? Additionally - forcing people to upgrade kernel for their sound issues is not a solution for many of them. Kernel upgrades tend to break lots of stuff on every minor version bump (and it's not only external modules that upstream seems to plain hate and ignore mostly). Not exactly what users would like to see when all they are trying to get is working sound. Beyond the usual statements that we aren't forcing anything: I will not deny that there is some user convenience gained by having the drivers separated from the kernel. Conversely, such packages are maintenance nightmares and are susceptible to entire classes of bugs that they would not be otherwise, and these are often passed onto the user. Sometimes we are even forced to take drastic measures such as marking heavily experimental code stable. The problem I'm solving here, I am solving from a development perspective. We have duplicated code and duplicated effort, and one of the copies currently doesn't have any real manpower taking care of it. Plus it's lot easier (and faster) to get patches into external drivers than get them accepted into kernel. I'm not sure that it is any easier, because the process of patch submission (file a bug) is the same. It may be faster, but I don't think thats a big factor. We generally do a good job keeping on top of the kernel bug list and regularly doing bugfix kernel releases. Although it may be faster for maintainers to supply new packages like alsa-driver, it's not *that* much different. All of the complaints so far seem to be regarding that *handling bugs* is more convenient for certain use cases when supported ALSA drivers are provided by an out-of-kernel package. (for clarity: a kernel driver not working IS a kernel bug, even if you have alternative ways of getting that hardware working) There is some truth here. However, more importantly in my eyes, our development resources are thin and there are currently 0 people standing behind alsa-driver. Additionally our processes across the entire Gentoo tree are based on the assumptions that things work, and bugs are treated as exceptions. Sure, we accept that bugs exist, and there are plenty of them, and we look to improve our methods of handling them (I have certainly done this a lot for the kernel) but we don't revolve our entire system around the assumption that the packages in the stable tree have bugs. What I'm trying to say is that even though there are some downsides here, the overall process is improved given the resources we have. Even though I'm sure my personal opinion is clear, I don't have a strong stake in the ALSA herd. The real reason why alsa-driver is not getting any support behind it right now is that nobody is standing behind it. If someone wants to step up and take over maintenance of alsa-driver, and put the required amount of
Re: [gentoo-dev] New ALSA maintainers
Jakub Moc wrote: Bryan Østergaard napsal(a): Nobody is forcing anybody to use in-kernel drivers. Uhm... http://bugs.gentoo.org/show_bug.cgi?id=172490 Sorry, my comments on that bug are a little unclear. I am not suggesting removal of alsa-driver from Portage, neither I am suggesting that the documentation stops documenting alsa-driver, nor am I suggesting any other way of forcing people to move away from it. I am simply asking if the documentation team are willing to recommend the in-kernel version over the portage one, given that the in-kernel one is being properly maintained and the portage one is not. This is different from forcing someone to use in-kernel drivers. I will add a clarification to the bug. Thanks, Daniel -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] New ALSA maintainers
Hi, We have some new ALSA maintainers: beandog, chainsaw, phreak (and me helping out to start with) It's of course up to the maintainers to choose how they work, but the recommendations I have laid down have been that they focus on the userspace side: utils, tools, firmware, lib. I have suggested that herd support for the kernelspace side (alsa-driver) be slowly reduced, by redirecting users who file bugs against it to reproduce with the in-kernel drivers, and then let kernel handle the bug resolution. This will remove duplicated maintenance efforts. This will also mean no more stabling of -rc releases (and probably fewer of those in portage at all). alsa-driver won't be going away altogether, as it is still needed for 2.4 users (but we won't support them forever) and I think it may include a couple of drivers which aren't yet in the kernel tree. The alias for bugs is still [EMAIL PROTECTED] Daniel -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] 2.6.20 to go stable in 1-2 weeks
I'm planning to request the latest revision of gentoo-sources-2.6.20 go stable on x86 and amd64 in 1-2 weeks from now. Other arches will probably follow soon after. There are still a few new bugs with external modules: https://bugs.gentoo.org/show_bug.cgi?id=163825 I've commented on every one of these that I can. Please fix your packages in the stable tree asap. If they are unfixable, make pkg_setup bail out on 2.6.20 as a last resort. In terms of actual kernel bugs, there are no significant 2.6.20 regressions reported. There are a couple of smaller bugs which I will do my best to get solved before it goes stable. Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] 2.6.20 to go stable in 1-2 weeks
Warwick Bruce Chapman wrote: Will you be marking linux-headers-2.6.19 stable as well? I really think http://bugs.gentoo.org/show_bug.cgi?id=160381 needs some serious attention. linux-headers isnt anything to do with me or the kernel herd. I can't comment on when it will go stable. Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
Josh Saddler wrote: We should not have third-party projects be part of SOC I see 3 important points missing from the discussion so far: (not directed at any response in particular) 1. We mentored projects like Piotr's last year, it seemed to work OK and as far as I'm aware there weren't any objections or conflicts of interest or anything like that. 2. Google are paying *GENTOO* $500 per project. Be sure to consider this when you state that mentoring projects like Piotr's would be taking resources away from Gentoo. 3. We should ask Google for their opinion on this. They are, after all, running the scheme, PAYING US MONEY, and are the people who decide whether we get to participate in future years. I have asked Alec to inquire about this. It seems that the mentors are already decided about the strategy here -- prefer projects undoubtedly in line with Gentoo development, but let proposal quality be the ultimate factor. My personal opinion is that we shouldn't be so hard on proposals like Piotr's. After all we are an open source community, the whole scheme is about promoting open source, so we should try and be open in our processes. In this particular case, it hasn't been decided that Paludis can't ever become the package manager of choice, and even while it isn't the official package manager right now, it is already helping significantly with areas like technical QA. Daniel -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] gentoo-sources-2.4 removal
Unfortunately I didn't find any suitable candidates from the call for help that went out in the GWN recently. I have contacted all applicants explaining how they can improve their skills, build up a series of contributions, and become more likely developer candidates in the future. Unless something changes, gentoo-sources-2.4 will be put in package.mask on March 1st and removed from portage on March 31st. Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] amd64 help
Christian Faulhammer wrote: So, maybe we can discuss here another helping hand for amd64. Devs that work with a given software (not necessarily the maintainer) on amd64 architecture It seems like this should be discussed amongst the active amd64 developers internally first, and perhaps should do some kind of recruiting drive / call for help. Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [RFC] Ideas for projects...
Steve Long wrote: Daniel Drake wrote: Construction of a dynamic website for tracking kernel security issues. There are too many of them and too many kernels to do this through the normal GLSA process, and currently users are kept in the dark about fixed security issues. Who put's up the fixed security issues? Nobody, that's the point of this project. We currently don't have GLSA or any other form of security announcements for kernel packages. Tim had started developing a site for this (KISS) but it was never finished and had the large downside that it relies upon an operator duplicating lots of information from bugzilla and the ebuild tree into KISS. Such a system would be able to automatically pull a large proportion of the required information relatively easily. It would offer functionality to allow users to sign up for security announcements and fixes for their kernel(s) of choice, as well as feeding the same info into a mailing list for all kernels. If you can put it thru repoman (or some other script) it can be automated. It can't be pulled at that level. But as I said, yes, it can be automated, thanks for agreeing ;) The existing data which needs to be aggregated is mostly held on bugzilla. Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] Ideas for projects...
Chris Gianelloni wrote: Submit your ideas here, so we can discuss them. I will be choosing one idea that we think we can accomplish to test out the idea of Council-driven projects. Construction of a dynamic website for tracking kernel security issues. There are too many of them and too many kernels to do this through the normal GLSA process, and currently users are kept in the dark about fixed security issues. Tim had started developing a site for this (KISS) but it was never finished and had the large downside that it relies upon an operator duplicating lots of information from bugzilla and the ebuild tree into KISS. Such a system would be able to automatically pull a large proportion of the required information relatively easily. It would offer functionality to allow users to sign up for security announcements and fixes for their kernel(s) of choice, as well as feeding the same info into a mailing list for all kernels. Daniel -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] gentoo-sources-2.4 needs a maintainer (a real one)
Hi, A few weeks ago I posted that gentoo-sources-2.4 needs a maintainer. antarus stepped up but realised his fatal mistake and has now fled from the scene. If anyone is interested please step up, otherwise this will go through the usual mask/removal process. Recruiting a non-developer to take this is an option, provided the usual requirements are met. Maintaining a kernel is a big job, plus maintaining a 'dead' kernel tree like 2.4 is even worse and is not really that interesting. A maintainer needs to have interest and energy (which probably indicates a genuine requirement to run 2.4), I'm not interested in seeing this maintained-but-neglected. Please mention this in the next GWN. Thanks! Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] 2.6.19 going stable in 1 week
Rémi Cardona wrote: About that bug, has anyone filed anything for it in Gentoo or is it the kind of bug that creeps up anywhere and can look like something else is responsible for it? Now that the problem is understood, it can be reproduced trivially on any kernel and can easily result in filesystem corruption. Daniel -- gentoo-dev@gentoo.org mailing list
Re: OT - Good skills (WAS: Re: [gentoo-dev] Through the looking glass: Reflections on Gentoo)
Michael Sullivan wrote: I would like to help with coding/debugging packages for Gentoo. I have some programming experience on a very small scale. I have an Associates of Computer Science from a small community college, and I've never had a job working for a software company. You spode of good enough skills; I don't think I have good enough skills to help with Gentoo, but I'd like to. Where should I start? Just to expand on everything that has already been said, here is my input. It sounds like you don't have any specific area of interest in mind, but you are keen on the principles and want to contribute to the community. So, the first thing you need to do is pick something moderately specific to get involved in, since packages are divided by category and roles are divided by projects, etc. The choice is fairly arbitrary but go for one that you have some kind of knowledge and interest in. For example, if you once did a college project evaluating different kinds of encryption, you might choose to get involved with the crypto packages. If you have some kind of uncommon hardware which needs its own out-of-kernel driver, firmware, or userspace utility then look into packages in that area. If you have a large music collection and spend a lot of time keeping it organised, pick the media-sound package group. And realistically your initial choice might not hold for very long, but that's fine. As long as you pick an area to start in, and you see it through the recruitment process, then you'll have found some footing and can move around and branch out later. At the moment I spend a lot of time maintaining and fixing the kernel in Gentoo. I was not even doing anything comparable to this when I originally became a developer. I am currently also involved upstream developing drivers and fixing bugs in the mainline kernel sources, and I certainly didn't have any knowledge of how to go about this when I originally joined Gentoo development. At some point you'll start finding some bugs which you can diagnose if not solve fully (diagnosis is often harder than fixing up the code). Or you'll find a personal itch that you are capable of scratching, so you'll be motivated to get involved in a very specific project (and you won't have the what can I do problem you have now). If this makes any sense to you, send me a list of software or areas that you might be interested in offlist, and I'll look into getting you in contact with appropriate people. Daniel -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] openmosix maintainer needed
Hi, openmosix has been hardmasked for a long time: # Tim Yamin [EMAIL PROTECTED] (07 Aug 2006) # Security mask # Bugs #135167, #137623, #137626, #138617, #139321, # #139475, #139641, #140444, #141503, #142616, #142617 sys-kernel/openmosix-sources sys-cluster/openmosixview sys-cluster/openmosixtest sys-cluster/openmosix-user sys-cluster/openmosixwebview sys-cluster/openmosix-3dmon-stats It should be removed from portage, but as this is quite a big thing I'm expressing some haste before kicking it. Is anyone working on bringing this back up to date? Any strong objections to the actual removal (despite it being hardmasked already)? Thanks, Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Last rites for net-wireless/ipw2100 and net-wireless/ipw2200
Rémi Cardona wrote: On second thoughts, I'll raise a small objection to the removal. Latest gentoo version is 1.2.0 while the kernel (gentoo-sources-2.6.19-r2) says to contain 1.1.4. I know that difference isn't exactly huge, but still, it's a step backwards. The only changes from 1.1.4 to 1.2.0 which aren't related to the out-of-kernel build system are very small, will only affect a very small number of users (i.e. people who do wireless development) and are merged for 2.6.20. I don't think you will see any behavioural difference at all between 1.1.4 and 1.2.0 and I don't think this is a showstopper to removal. Daniel -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Linux 2.6.19 stabilization
Hi, I plan to get gentoo-sources-2.6.19 stable on x86 and amd64 around January 8th time. There are a couple of outstanding kernel issues to fix, and I hope to see the external kernel module tree in better shape: https://bugs.gentoo.org/show_bug.cgi?id=156669 this is your advance warning - fix your packages, and ensure they are fixed in the stable tree. Find me on IRC if you need help. Daniel -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] sys-fs/submount removal
Hi, After no response to my call for maintainers, submount will enter package.mask tomorrow for removal in 3 weeks. http://archives.gentoo.org/gentoo-dev/msg_141377.xml Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Portage feature addition
Alec Warner wrote: This is to prevent people from sticking a random unchecksum'd ebuild in your tree and then having portage source it for depend() metadata and then getting bitten by some global scope nasties. Is this really the correct solution to this problem? I can't see the use case: do people really download (potentially malicious) ebuilds, stick them in their overlay, and then *not* use them? Somehow I don't think that's true - people will generally download ebuilds, and use them (even if they fail during compilation, they will have been used in some form). If you start requiring people to create Manifests for these ebuilds, they will do so, and this has not changed the security implications of these untrusted ebuilds. Am I missing something? Daniel -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] sys-fs/submount needs a maintainer
Hi, submount is an external kernel module which provides automounting functionality. It is currently under kernel herd but nobody there has interest in this package. I have had to fix it repeatedly in order to compile with newer kernels, it's broken again for 2.6.19 and I've had enough. Upstream appears to be dead as well. If nobody steps up within a week it will go in package.mask for removal 3 weeks later. Suitable replacements for this package include the in-kernel automounter, hal, ivman. Daniel -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] gentoo-sources-2.4 needs a maintainer
Hi, With Tim gone there is nobody working on gentoo-sources-2.4. I'm not sure what's left in the patchset but on last check there were users depending on it. If anyone is interested please step up, otherwise this will go through the usual mask/removal process. Recruiting a non-developer to take this is an option, provided the usual requirements are met. Please mention this in the next GWN. Thanks! Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] /etc/udev/rules.d nightmare - orphaned files in /etc
Sven Köhler wrote: Have you ever thought about sollutions of that problem? It's not a real problem, that these files are orphaned - but they are neither removed nor renamed, so they stay in place and in one or the other way, they may start to disturb. Wasn't portage modified to remove unmodified config-protected files on unmerge a while back? If not, is this a sensible suggestion? Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Xbox-sources
Mike Frysinger wrote: and is unmaintained. says you :P Following up from IRC earlier: You're interested in maintaining this until a new maintainer is found. Are you prepared to handle the security bugs here? Alternatively we could either put it in hardmask until a maintainer is found, or we could slap a warning in the ebuild saying that it's not supported from a security perspective, or something along those lines. Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] 2.6.18 going stable in 1 week
Thomas Cort wrote: What package(s) are going stable in 1 week? I have no clue what you are writing about since you didn't mention it in your e-mail. I did a quick search and found the following 6 packages which have a version 2.6.18: gentoo-sources-2.6.18 linux-headers-2.6.18 suspend2-sources-2.6.18 usermode-sources-2.6.18 vanilla-sources-2.6.18 Sorry about that. I was referring to gentoo-sources, which is really the only truly supported kernel (excluding some arch-specific ones). You also neglected to mention which architectures are going stable. Are all arches going stable at the same time (in 1 week)? Will you still go ahead with the stable marking if http://bugs.gentoo.org/148429 is not resolved? x86 and amd64 immediately, and assuming they don't have showstoppers, ppc/ppc64/sparc usually follow up real quick. Yes, it will go stable even if some dependencies of bug 148429 are not fixed. These are *not* kernel bugs, they are bugs in the individual packages. However, I don't ignore them, I have already put many hours into fixing those bugs. I have been through every bug listed there and provided fixes/workarounds to all of them. I expect to have to spend even more time chasing up maintainers of the unfixed packages there. This is becoming a real problem for me as I'm having to waste excessive amounts of time on every kernel release fixing bugs in packages which are nothing to do with me. I'm considering dropping stable keywords from repeat offenders, but really there aren't any of those: external kernel packages are almost guaranteed to break every once in a while, and we simply have a large number of these packages which aren't given much attention by their maintainers. Any suggestions here are appreciated. Daniel P.S. The tone of your email didn't offend me, but that's probably because I completely agreed with it. Andrew is certainly right in that we should be really careful about how we write things. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: 2.6.18 going stable in 1 week
Christian Faulhammer wrote: Announce it here (or -core) which needs a fix and then just commit the fix if it is trivial and there has been no reaction. I think you didn't grasp the problem exactly. There are a large number of packages which build against the kernel and do not get much attention from their maintainers. To avoid too many sharp objects coming in my direction when a new kernel goes stable, I spend a lot of time providing fixes for these packages. The problem is that this (i.e. producing the fixes) is a big waste of time on my part, I'd rather work on real kernel stuff which is lagging behind. Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: 2.6.18 going stable in 1 week
Mike Pagano wrote: This seems to me like a good opportunity to engage the arch teams for some assistance. So the arch teams would be happy to handle package foo doesn't compile with 2.6.18 bugs, for example, bug 148381? Daniel -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] 2.6.18 going stable in 1 week
This is your 1 week warning.. fix any packages which don't compile and ensure the fix is also in the stable tree. Thanks. Daniel -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] cracklib, shadow, cracklib USE flag, cracklib in system
cracklib is a library which makes judgements on passwords. It tells you passwords weak as they are too short, based on a dictionary word, and stuff like that. It's a nice thing to have, is fairly standard, but is not a true requirement. Any thoughts on these changes: 1. Promote cracklib USE flag to global USE 2. Enable USE=cracklib by default in profiles/default-linux/make.defaults 3. Add cracklib USE flag to sys-apps/shadow. Right now shadow unconditionally depends on cracklib and includes cracklib support. 4. Remove cracklib from base/packages Thanks, Daniel -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] net-misc/bcm4400 going away
Hi, net-misc/bcm4400 is a kernel driver built as an external package through portage. The codebase which this package use has been discontinued upstream. The upstream replacement (which is not in Portage directly) is simply a copy of the in-kernel b44 driver code. For this reason we are suggesting everyone migrates to the b44 in-kernel driver (I guess net-misc/bcm4400 doesn't really have any users anyway...). bcm4400 will be removed in about 28 days. Bug #145525 Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Funding from Gentoo UK 2006 event
Roy Marples wrote: While the location was indeed good and in easy walking distance from the tube station, the room was packed - do you know if they have larger rooms? They do, see http://www.theresourcecentre.org.uk/voluntary_charges.pdf We were in seminar room 3. This was the largest one available when we booked, so be sure to get in early. Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Funding from Gentoo UK 2006 event
Lisa Seelye wrote: Is there any news on a 2007 event? This time, really, I promise I'll be in the country to attend! No, and you won't hear anything from me. I won't be in the country. Daniel -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Making procfs mount as nosuid,noexec by default
Hi, The local root exploit-of-the-week would have been unable to run if our users systems had /proc mounted with nosuid and/or noexec It would be worthwhile considering making this a default. What are people's thoughts? Additional testing of this change would be appreciated (just ensure that nothing breaks). To do it as a one off: # mount -o remount,nosuid,noexec /proc To make it more permanent, /etc/fstab has: proc/proc procdefaults0 0 Change to: proc/proc procnosuid,noexec 0 0 Thanks, Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] 2.6.17 kernel stabilisation plan
Daniel Drake wrote: Hi, I'm hoping to be able to mark 2.6.17 stable on or around July 11th. I'll give around a weeks notice here when that is to happen. Hopefully we'll use this for the 2006.1 release too. It will be a little later than planned, but this is your 1 week notice that 2.6.17 will go stable on July 17th. There are a couple of packages to fix in the stable tree which I will do my best to see fixed before this happens. Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Last rites for some CD/DVD-recording applications
Lars Weiler wrote: app-cdr/dvdrtools: Same reason. No need to use this fork of cdrtools-1.11... This is a lot more more than a add DVD writing support fork - they have changed much more than that, and they have an interesting list of objectives. It's a much saner version of cdrtools. Please don't remove it unless you have confirmed with upstream that they have lost interest and nobody is developing it. Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Portage: missing pieces
Molle Bestefich wrote: Same thing with a package called 'seamonkey': Same answer as you got on the -user list: use --tree But don't only look at the top section of the output. Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] SpanKY's Nominations for the Gentoo Council 2007
Mike Frysinger wrote: i guess i'll start off some mass nominations of random people off the top of my head who i think would do a good job ... there's a bunch more people i think would do a good job, but i'm going to cut my list short as it's already ridiculously long ... Thanks for the nomination. I don't have enough time especially as I'll be doing my first full-time placement for a year. Maybe I'd consider it in the future. Daniel -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] 2.6.17 kernel stabilisation plan
Hi, I'm hoping to be able to mark 2.6.17 stable on or around July 11th. I'll give around a weeks notice here when that is to happen. Hopefully we'll use this for the 2006.1 release too. If you find packages (e.g. out-of-tree drivers) in the stable tree which do not compile against 2.6.17 (but do compile against 2.6.16) then please file bugs making them block bug #137175. Packages in the stable tree which do not compile against 2.6.16 or older are also important but priority is given to not creating any regressions at this point... Testing of 2.6.17 is very much appreciated, please also file bugs against problems you have with the kernel itself :) Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] eclasses maintainers - raise your hands please
Diego 'Flameeyes' Pettenò wrote: Can gnuconfig_update calls go away from new ebuilds, then? Yes, because base/make.defaults includes FEATURES=autoconfig and no profile turns it off. Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] July Council Meeting: Requested Agenda Item
Christel Dahlskjaer wrote: I would like to ask that the Council discuss the current state and future of the GWN at their next meeting. This is an open project. The solution to the problems you raise is incredibly simple: Contribute on a regular basis, or find other people who will do so. Writing hugely demotivating emails, scaring away existing contributors, and wasting the council's time will not help at all. Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Dealing with /var/cache on unmerge
Mike Frysinger wrote: maybe give ebuilds a way to maintain a list of files that portage should nuke when unmerging the package ... Something similar to this would be useful for kernel ebuilds, as simply unmerging kernel source will leave a load of temporary and object files on the filesystem. Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] SATA disk slower as /dev/sda then as in /dev/hda
Mivz wrote: /dev/sda: Timing cached reads: 1424 MB in 2.00 seconds = 711.96 MB/sec HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device Timing buffered disk reads: 114 MB in 3.00 seconds = 37.95 MB/sec HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device Now I tryed a old Gentoo 1.4-rc1 livecd, cause this one loads the disk still as /dev/hda and not sda. After enabling dma, 32bit io and udma: hdparm -X66 -c1 -d1 It had a speed of 2560.00 MB/sec bufferd and 37,65 unbufferd. The unbuffered speed is identical, the cached read is the only difference. Cached reads are not a test of hard disk performance, this is a mostly useless benchmark (note that on that metric, your cdrom drive performs at the same speed as your hard disk...) Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Summer of Code students and Planet Gentoo
Donnie Berkholz wrote: Why a new domain? We've already got a blog setup at http://planet.gentoo.org/developers/ and could just add http://planet.gentoo.org/summerofcode/ or something. If you want something like this, why not (soc|summerofcode).gentoo.org/? The domain is already set up, and hosting them there avoids any controversy that might arise from hosting them at /developers. Setting up /summerofcode sounds like extra work on my part. In short, it doesn't matter where they are hosted - the point is that they are aggregated on the Gentoo-hosted Planet sites. I expect most of them will have external weblogs anyway. Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] et_EE locale and language of error messages
Harald van Dijk wrote: and as for unreadable error messages, getting German gcc output in a German locale is a feature, not a bug. I agree - but only when you use gcc on the command line, or in a Makefile, or in some other normal usage scenario. I think Stefan is suggesting just using the standard English locale *during portage merges* rather than as a system-wide thing. Does that change your view at all? Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
Stephen Bennett wrote: If noone has any strong reasonable objections, I'd like to add a Paludis profile to the tree. I think that this should be the decision of the Portage developers. If there is any burden other than the points you mentioned, it directly or indirectly falls on them. Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
Ciaran McCreesh wrote: Adding a new profile doesn't affect Portage unless Portage is told to use that profile. And anyone telling Portage to use *any* invalid profile is going to be in for a shock. I was more thinking along the lines of that there might be a lot of confusion if Paludis and Portage have varying feature sets, and do not maintain total ebuild compatibility both ways. We all know how keen our users are to try new stuff... Daniel -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] GUADEC 2006
http://guadec.org/GUADEC2006 Anyone going? Anyone staying in the GNOME village? I'll be there, with a friend. Daniel -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Looking for a new media-sound/easytag maintainer
Hi, Is anyone interested in taking over maintenance of easytag? I still use it, but am looking to free up some time for other things. It doesn't require much commitment: there aren't many bugs filed for it (none open at the moment either). Easytag 2.0 is just around the corner and will be the first GTK+ 2.x version to go stable (finally!). Daniel -- gentoo-dev@gentoo.org mailing list
