Re: [gentoo-dev] [RFC] New eclass for x11 packages
On Wednesday 10 March 2010 15:13:40 Tomáš Chvátal wrote: As last step i fixed issue with circular dependencies. So please speak-up now because if no complains are sent, i will add this eclass in 5 hours into main tree. For the eclass see attachment. Tomas 5 hours? :o -- Cheers Dawid Węgliński
Re: [gentoo-dev] [RFC] Remove cups from default profile to solve circular deps
On Friday 05 March 2010 17:12:23 Roy Bamford wrote: That's not a new install as per the handbook. Neither are you a new user as you have a premade make.conf and world file and some experience with Gentoo. Put yourself in the place of a brand new Gentoo user doing his/her first install. It needs to just work out of the box, one way or another, without forums posts or calls for help in #gentoo about circular dependences. That's not just cups - thats all circular dependencies. Brand new gentoo user goes throu handbook - reads set up USE variables in make.conf and does it according to his/her needs following use.*.desc. If gentoo was new to me i *would* enter cups as i use printers often at work. -- Cheers Dawid Węgliński
Re: [gentoo-dev] [RFC] Remove cups from default profile to solve circular deps
On Wednesday 03 March 2010 22:51:10 Ben de Groot wrote: On 3 March 2010 19:45, Mart Raudsepp l...@gentoo.org wrote: I don't believe we should selectively cripple one GUI toolkit with not having proper printing support out of the box on a desktop profile, while others do, just because maintainers are lazy. I'm not talking about selectively disabling cups. My proposal is to no longer enable the cups useflag in the base profile. I don't think cups should be part of the base profile, and as a result cascading to the desktop profile. And a lot of people seem to agree. Users can always enable that functionality when they need it. It is not something that is necessary for running a desktop system. Cheers, How is that going to fix circular dependency problem? What will you do if every user add cups to USE in make.conf? Say we don't support cups turned on by default? I hope no. Removing this flag from profile will not fix any problem but hide it. -- Cheers Dawid Węgliński
Re: [gentoo-dev] Marking bugs for bugday?
On Sunday 28 February 2010 00:14:36 Mark Loeser wrote: Ben de Groot yng...@gentoo.org said: Its been pretty much dead. We need more developer involvement so users can actually talk to them and help resolve issues. If we can't get enough developers to participate then we should just stop trying to do it instead of putting on such a poor showing. I would like to be involved but not in the current disorganized form. Our #gentoo-bugs channel topic still refers to the thoroughly outdated bugsday.g.o page, and I can't edit either of them. I can modify the channel topic for you. I should have a login for the bugsday.g.o page somewhere, if not...I'm sure we can get one. welp transfered #gentoo-bugs to you last time when i asked him, so you are now the owner. But every developer can change topic by /msg chanserv topic #gentoo-bugs -- Cheers Dawid Węgliński
Re: [gentoo-dev] News item: MySQL 5.1 bump
On Monday 15 February 2010 23:15:02 Robin H. Johnson wrote: On Mon, Feb 15, 2010 at 11:06:37PM +0100, Dawid Węgliński wrote: On Monday 15 February 2010 22:21:36 Robin H. Johnson wrote: This is my last blocker for getting MySQL 5.1 series into ~arch status. itle: MySQL 5.1 unmasking Is there an upgrade path for databases itself? The official upgrade docs are: http://dev.mysql.com/doc/refman/5.1/en/upgrade.html My unofficial recommendation is just doing a backup before and running 'mysql_upgrade' after. I'd like to see this link in news item. Thanks. ;) -- Cheers Dawid Węgliński
Re: [gentoo-dev] [rfc] layman storage location (again)
On Friday 15 January 2010 20:44:43 Alex Legler wrote: /var/lib/layman do well? +1 -1, /usr/local/layman? -- Cheers Dawid Węgliński
Re: [gentoo-dev] [rfc] layman storage location (again)
On Saturday 16 January 2010 00:33:15 Jorge Manuel B. S. Vicetto wrote: On 15-01-2010 21:25, Dawid Węgliński wrote: On Friday 15 January 2010 20:44:43 Alex Legler wrote: /var/lib/layman do well? +1 -1, /usr/local/layman? Wouldn't that break the rule that /usr/local is reserved for users / admins? From the alternatives, /var/lib/layman doesn't sound right. If /var/cache/layman doesn't work, what about /var/spool/layman instead? Or just leave it up to user with elog message... Or ask him first to set variable in /etc/make.conf? -- Cheers Dawid Węgliński
Re: [gentoo-dev] GPG Infrastructure for Gentoo (Was Council Meeting)
On Monday 30 November 2009 22:18:21 Richard Freeman wrote: Antoni Grzymala wrote: How about getting back to GLEP-57 [1]? Robin Hugh Johnson made an effort a year ago to summarize the then-current state of things regarding tree and package signing, however the matter seems to have lain idle and untouched for more than a year since. One concern I have with the GLEP-57 is that it is a bit hazy on some of the implementation details, and the current implementation has some weaknesses. I go ahead and sign my commits. However, when I do this I'm signing the WHOLE manifest. So, if I stabilize foo-1.23-r5 on my arch, at best I've tested that one particular version of that package works fine for me. My signature applies to ALL versions of the package even though I haven't tested those. I may be wrong - then please correct me. You don't sign every package versions but Manifest. Thus you somehow prove every file checksum is correct. If there were any changes made on server side, those checksums would be incorrect according to your signed Manifest. Currently any change may be fixed by whoever it is by the same command ebuild foo digest. Now, if we had an unbroken chain of custody then that wouldn't be a problem. However, repoman commit doesn't enforce this and the manifest file doesn't really contain any indication of what packages are assured to what level of confidence. That's what should be discussed - forcing developers to sign their commits and implementing this support in package managers. If we want to sign manifests then the only way I see it actually providing real security benefits is if either: 1. The distro does this in the background in some way in a secure manner (ensuring it happens 100% of the time). 2. Every developer signs everything 100% of the time (make it a QA check). The instant you have a break in the signature chain you can potentially have a modification. If somebody cares enough to check signatures, then they're going to care that the signature means something. Otherwise it only protects against accidental modifications, and the hashes already provide pretty good protection against this. That's not really true. I see tips like if you have digest incorrect, run ebuild foo.ebuild digest very often. Really small group of people care about broken digests. :( -- Cheers Dawid Węgliński
Re: [gentoo-dev] RFC: qt4-r2.eclass - new eclass for Qt-based apps
On Monday 30 November 2009 00:19:49 Ben de Groot wrote: 2009/11/29 Dawid Węgliński c...@gentoo.org: On Sunday 29 November 2009 16:59:10 Ben de Groot wrote: As soon as existing ebuilds in the tree are ported over to qt4-r2, the old qt4.eclass will be removed. As far as i remember we don't remove eclasses. Probably you meant deprecated, but not removed? I hate leaving old cruft around, so I definitely meant removed. If that is against policy, can you refer me to a document that specifies said policy? Cheers, Sorry, i was not up to date with this. http://devmanual.gentoo.org/eclass-writing/index.html -- Cheers Dawid Węgliński
Re: [gentoo-dev] QA is unimportant?
On Monday 09 November 2009 17:30:27 Patrick Lauer wrote: Unmaintained stuff is unmaintained If i can recall my recruitment process, i remember one sentence which was like if you touch any package, you are responsible for it. Please don't hide behind your great job that you are doing here (we all appreciate it) and admit you are wrong. QA (not the QA team itself, but policies we have here) is important and talking excuse me my mistakes because i do things others do not doesn't really matter. -- Cheers Dawid Węgliński
Re: [gentoo-dev] [RFC] Splitting desktop profile to KDE and GNOME
On Monday 26 October 2009 21:06:04 Rémi Cardona wrote: Le 24/10/2009 15:42, Maciej Mrozowski a écrit : If you have any comments, suggestions, important notices regarding this change, please keep discussion in gentoo-desktop mailing list. IMHO, we shouldn't even have desktop/server subprofiles to begin with. I've always considered Gentoo to be an opt-in distro where after a successful install, you end up with a bash prompt and a _means_ of installing new packages. Finding out what USE flags mean and do is part of the Gentoo experience. If we were doing spin-off distros like Ubuntu and Fedora do, then subprofiles would be fine, but we're not. So hmm, let me make few hypothetical statements. You see package foo-libs/baz has USE=pic that is not set by default in profile. It's well documented in metadata.xml which says disable optimized assembly code that is not PIC friendly. So as an ordinary user you set it in your make.conf because it may be helpful. Then you want to install another package with USE=pic but you note this useflag for this package means Force shared libraries to be built as PIC (this is slower). Of course you don't want your programs run slower, do you? So you disable useflag in make.conf or package.use. This situation may lead user to reinstall half of his system, because some packages with USE=- pic force foo-libs/baz[-pic] and foo-libs/bar[-pic] too. You end up with nothing after some time spent on reading metadata.xml, recompilling foo, bar, baz... just because you were forced to have a choice. IMO profiles are very good solution for every user. Especially for those that don't know what every use flag means and they (profiles) should have at least base useflags set. And if base, why not most of useful? They are only option. User can alwasy disable it (eg. -kde if he wants gnome, -gnome if he wants kde or - both if he uses openbox). My $0,02. -- Cheers Dawid Węgliński
Re: [gentoo-dev] [RFC] Splitting desktop profile to KDE and GNOME
On Tuesday 27 October 2009 00:26:38 Zeerak Waseem wrote:
But instead of just giving the user the answer, wouldn't it be more
appropriate, as far as understanding useflags and their uses goes, to give
users lists of useflags and what they do. Ie a list of base use flags for
say, kde, and also what basic useflags to disable, and a suggestion to
read the descriptions of the useflags to add what's necessary. As the
handbook currently does. I think with the documentation, one should have
enough information to assess what useflags are desired for one's system.
And then I'd suggest looking at the packages and the need for various use
flags individually, if you want to. But the documentation provides basic
useflags for running your system.
But again, this is just my take on it :-)
No. Handbook doesn't provide information on every useflag. For this you have
use{.local.,.}desc in PORTDIR/profiles/. And again, if you missread my previous
post - there's no way to standarize *every* useflag and tell user flag foo
does
bar. It's developer who should decide on behalf of user what's the best
configuration. And user has always choice to disable some useflags and create
his own configuration for his requirements.
--
Cheers
Dawid Węgliński
Re: [gentoo-dev] [RFC] Splitting desktop profile to KDE and GNOME
On Tuesday 27 October 2009 01:34:55 Dawid Węgliński wrote:
On Tuesday 27 October 2009 00:26:38 Zeerak Waseem wrote:
But instead of just giving the user the answer, wouldn't it be more
appropriate, as far as understanding useflags and their uses goes, to
give users lists of useflags and what they do. Ie a list of base use
flags for say, kde, and also what basic useflags to disable, and a
suggestion to read the descriptions of the useflags to add what's
necessary. As the handbook currently does. I think with the
documentation, one should have enough information to assess what useflags
are desired for one's system. And then I'd suggest looking at the
packages and the need for various use flags individually, if you want to.
But the documentation provides basic useflags for running your system.
But again, this is just my take on it :-)
No. Handbook doesn't provide information on every useflag. For this you
have use{.local.,.}desc in PORTDIR/profiles/. And again, if you missread
my previous post - there's no way to standarize *every* useflag and tell
user flag foo does bar. It's developer who should decide on behalf of
user what's the best configuration. And user has always choice to disable
some useflags and create his own configuration for his requirements.
s...@best configurat...@best minimal configuration@
--
Cheers
Dawid Węgliński
Re: [gentoo-dev] openrc-0.5.1 arrived in the tree
On Wednesday 14 October 2009 02:41:51 Branko Badrljica wrote: Mike Frysinger wrote: i really dont buy this argument, but ignoring that, poor admin policy is no excuse. blindly accepting all unstable versions of a package instead of pinning a specific version and then expecting a stable system isnt going to happen. Thomas is absolutely right here. Well, if eh is absolutely right, then I won't argue anymore. But just as an notice, I didn't expect STABLE but at least DOCUMENTED system ? Is that too much to ask ? sapphire ~ # qlist openrc | grep doc /usr/share/doc/openrc/net.example /usr/share/doc/openrc/net.default And even if I did a mistake of keywording openrc-0* instead of openrc-0.4-r3, do I really deserve such knife in the back ? Knife, eh? The worst thing could happen to you i lack of net connection. And who should write documentation for new code ? Unreasonable users that find it not working or perhaps authors ? While I recognise the fact that Gentoo is not commercial distro, I want also some recognition for value of my time as a passive tester. Upstream already provides such a documentation as you can see above. Gentoo provides migration guide. I believe doc team will update use flag description as soon as it's possible. But that's all has been already said. -- Cheers Dawid Węgliński
Re: [gentoo-dev] Anyone interested in maintaining the Gentoo Handbooks?
On Saturday 03 of October 2009 18:17:36 David Abbott wrote: I always use the x86 Quick install guide [1] I did an amd64 install using it and can not recall changing anything. And i don't use any guide nor handbook any more, because i know what to do step by step. That doesn't mean handbook should be dropped out for new users. How about each arch maintaining their own Quick install guide and for more in depth questions point users to irc or the forums and put the handbook in the archives for historical reference if no one wants to keep it current. No. Wee only need to aply some patches to current handbook and everything would be ok. The point is only doc team plus i believe few devs too have write access to /doc/ section. [1] http://www.gentoo.org/doc/en/gentoo-x86-quickinstall.xml
Re: [gentoo-dev] rfc: jpeg upgrade news item
On Tuesday 22 of September 2009 18:24:11 Ulrich Mueller wrote: On Tue, 22 Sep 2009, Petteri Räty wrote: media-libs/jpeg-7, perhaps? Yes there should be such a restriction to avoid hitting people who have already upgraded. I don't think that there should be a version restriction. People may have upgraded but not have followed the advice in the news item. Ulrich If they had upgraded, they also probably have it fixed already.
Re: [gentoo-dev] Stabilization of Python 3.1
On Sunday 20 of September 2009 00:32:28 Dale wrote: ~arch is for testing ebuilds, not the upstream package So it would be OK to mark something stable even tho portage itself doesn't work with it? Sorry, this makes no sense to me. I run stable for the most part and having a package that portage depends on that is not stable just sounds a little like putting the cart before the horse. See some of the other replies as to why this is a not so good idea. Dale :-) :-) You mix it up. Portage works with python 3.1. If an user switches to python 3.1 as the main interpreter, it's possible that his own scripts won't work. Marking it stable sometine in november give's some time to ebuilds maintainers to fix their python based apps just like it's done with gcc stabilization. So marking python 3.1 stable and telling users port your own apps/scripts to current python sounds good to me.
Re: [gentoo-dev] Enough about GLEP5{4,5}
On Monday 08 of June 2009 22:41:12 Patrick Lauer wrote: [snip] Thanks for your useless statistics. -- Cheers Dawid
Re: [gentoo-dev] openswan compile issue with glibc-2.10
On Monday 01 of June 2009 22:10:47 Timur Aydin wrote: Today I have tried to merge openswan-2.4-14 into my ~x86 system. The compilation failed because of a name clash: Hi Timur. Mind to report this issue on bugs.gentoo.org with patch attached there? Also don't forget to check if the bug wasn't reported before! -- Cheers Dawid Węgliński
Re: [gentoo-dev] Gentoo Council 2009/2010 - Nominations are now open
On Monday 01 of June 2009 06:25:06 Jorge Manuel B. S. Vicetto wrote: Hello fellow developers and users. I nominate: Betelgeuse Calchan peper darkside tanderson Cardoe signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Baselayout 2 stabilisation todo
On Saturday 23 of May 2009 10:53:49 Tobias Klausmann wrote: Hi! On Fri, 22 May 2009, Dawid Węgliński wrote: Haven't tested it yet on my box, but i'd like to know if openrc handles 801.2Q support. Near as I can tell, it does (some lines shortened for brevity): [r...@sareth ~]# eix -Ic openrc [I] sys-apps/openrc (0.4.3...@05/15/2009): OpenRC manages the services, startup and shutdown of a host [r...@sareth ~]# ip addr sh [...] 2: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 [...] link/ether 00:1e:0b:46:50:ba brd ff:ff:ff:ff:ff:ff 3: eth1: NO-CARRIER,BROADCAST,MULTICAST,UP mtu 1500 [...] link/ether 00:1e:0b:46:50:b8 brd ff:ff:ff:ff:ff:ff 4: eth0@eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 [...] link/ether 00:1e:0b:46:50:ba brd ff:ff:ff:ff:ff:ff inet 192.168.2.166/28 brd 192.168.2.175 scope global eth0.381 inet 192.168.2.164/28 brd 192.168.2.175 scope global secondary eth0.381 inet 192.168.2.165/28 brd 192.168.2.175 scope global secondary eth0.381 5: eth0@eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 [...] link/ether 00:1e:0b:46:50:ba brd ff:ff:ff:ff:ff:ff inet 192.168.3.102/24 brd 192.168.3.255 scope global eth0.146 6: eth0@eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 [...] link/ether 00:1e:0b:46:50:ba brd ff:ff:ff:ff:ff:ff inet 10.104.22.1/24 brd 10.104.22.255 scope global eth0.271 [r...@sareth ~]# grep -v '^#' /etc/conf.d/net routes_eth0_381=(default via 192.168.2.161) config_eth1=( null ) config_eth0=( null ) vlans_eth0=381 146 271 config_eth0_381=( 192.168.2.166/28 192.168.2.164/28 192.168.2.165/28 ) config_eth0_146=(192.168.3.102/24) config_eth0_271=(10.104.22.1/24) Regards, Tobias Thank you very much Tobias!
Re: [gentoo-dev] Baselayout 2 stabilisation todo
On Friday 22 of May 2009 12:17:17 Christian Faulhammer wrote: Hi, I'd like to collect some things we need to do before Baselayout 2 and OpenRC can go stable. Up to now I have: * eselect 1.1 stable (current RC3) for the support in the rc module * a newer splashutils stable * documentation updates (http://bugs.gentoo.org/213988, thanks Jeremy) What else? As some of you might foresee, this can be as hard as a major GCC stabilisation, so it must be well-planned and organised. V-Li Haven't tested it yet on my box, but i'd like to know if openrc handles 801.2Q support.
Re: [gentoo-dev] RFC: Deprecating EAPI0
On Saturday 21 of March 2009 21:53:16 Patrick Lauer wrote: On Saturday 21 March 2009 21:21:47 Ciaran McCreesh wrote: On Sat, 21 Mar 2009 18:37:12 +0100 Patrick Lauer patr...@gentoo.org wrote: To make our lives easier I would suggest deprecating EAPI0 and migrating existing ebuilds over some time to EAPI1 or higher until EAPI0 can be obsoleted at some point in the future. Uh. Why? Because, as you have noticed before, developers get confused which eapi has which features available. And eapi1 is a superset of eapi0, so we don't have to rewrite tons of things. Spend more time to teach them. It's easier to developers make sure they do things ok than users spending their time to figure out what's wrong. Personally i don't like the idea of deprecating EAPI0 since it may break many servers. Eg. our border router at work isn't upgraded regulary. I spent much time lately to upgrade it with problems like portage vs. bash and so. So the last thing i'd like to see now in portage is implementing your proposal. Introducing a policy encouraging moving things that definitely aren't in the least bit likely to be a system dep on a bump, sure. Making 1 or 2 the default for new packages, sure. But rewriting existing things? That's just an accident waiting to happen. What kind of accident do you expect to happen? Patrick
Re: [gentoo-dev] Re: LC_ALL=C Set by default for portage
On Sunday 08 of March 2009 23:50:08 Ryan Hill wrote: You do realize that many people don't speak any English, and therefore wouldn't be filing bugs anyways? They just want to use their computer. I'm not sure they will appreciate you forcing a language they don't speak on them any more than I would like to suddenly see all my build errors in Myanmar. Plz fix the bug [1] [1] - http://bugs.gentoo.org/show_bug.cgi?id=166730
Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
On Tuesday 24 of February 2009 23:21:23 Petteri Räty wrote: Let's try something new. I would like to get opinions from as many people as possible about GLEP 55 and alternatives listed here in order to get some idea what the general developer pool thinks. Everyone is only allowed to post a single reply to this thread in order to make it easy to read through. The existing thread should be used for actual discussion about the GLEP and the alternatives. This should be a useful experiment to see if we can control ourselves :) My notes so far: 1) Status quo - does not allow changing inherit - bash version in global scope - global scope in general is quite locked down 2) EAPI in file extension - Allows changing global scope and the internal format of the ebuild a) .ebuild-eapi - ignored by current Portage b) .eapi.ebuild - current Portage does not work with this c) .eapi.new extension - ignored by current Portage All of this are ok for me, though the first shot is my preffered one since it's the most human readable and the rest would be mostly seen as the package version. 3) EAPI in locked down place in the ebuild - Allows changing global scope - EAPI can't be changed in an existing ebuild so the PM can trust the value in the cache - Does not allow changing versioning rules unless version becomes a normal metadata variable * Needs more accesses to cache as now you don't have to load older versions if the latest is not masked a) new extension I don't see this as the best solution. b) new subdirectory like ebuilds/ - we could drop extension all together so don't have to argue about it any more - more directory reads to get the list of ebuilds in a repository Nah. Scanning portage tree in this place would be more painful than it's currently. c) .ebuild in current directory - needs one year wait Regards, Petteri
Re: [gentoo-dev] bash-4.0 regression heads up (escaped semicolons in subshells)
On Sunday 22 of February 2009 00:27:10 Mike Frysinger wrote:
looks like bash-4.0 has broken semicolon escaping in subshells. this comes
up when using find's -exec like we do in a few places in eclasses:
ls=$(find $1 -name '*.po' -exec basename {} .po \;);
shift you can work around the issue in a couple of ways:
- quote the semicolon:
';')
- use backticks
`find \;`
i'll tweak the eclasses to use quoting for now
-mike
FYI. Not only find's semicolons are affected. It also happens in case ;;
construction.
--
Cheers,
Dawid Węgliński
Re: [gentoo-dev] bash-4.0 regression heads up (escaped semicolons in subshells)
On Sunday 22 of February 2009 23:39:11 Mike Frysinger wrote:
On Sunday 22 February 2009 17:30:09 Dawid Węgliński wrote:
On Sunday 22 of February 2009 00:27:10 Mike Frysinger wrote:
looks like bash-4.0 has broken semicolon escaping in subshells. this
comes up when using find's -exec like we do in a few places in
eclasses: ls=$(find $1 -name '*.po' -exec basename {} .po \;); shift
you can work around the issue in a couple of ways:
- quote the semicolon:
';')
- use backticks
`find \;`
i'll tweak the eclasses to use quoting for now
FYI. Not only find's semicolons are affected. It also happens in case ;;
construction.
embedded case statements in $(...) subshells have always been broken.
bash-4.0 is supposed to fix that. if you have some code that is broken,
please post it so i can push it upstream.
-mike
It wasn't me who experienced that, but a user:
13:50 diabel- dir /usr/share/doc/wxGTK-2.8.9.1-r3
13:50 diabel- /var/tmp/binpkgs/x11-libs/wxGTK-2.8.9.1-r3/temp/environment:
line 2989: błąd składni przy nieoczekiwanym znaczniku `;;'
13:50 diabel- /var/tmp/binpkgs/x11-libs/wxGTK-2.8.9.1-r3/temp/environment:
line 2989: `;;' * * ERROR: x11-libs/wxGTK-2.8.9.1-r3 failed.
All it states is syntax error near double semicolons.
Re: [gentoo-dev] `paludis --info' is not like `emerge --info'
On Wednesday 18 of February 2009 23:22:12 Jeroen Roovers wrote: In short, `paludis --info' is not a replacement, and when `emerge --info' is asked for in a bug report, post *that*. Hi Jeroen. If you ask me to post a emerge --info you will get very, but very outdated info. Not much useful. Keep that in mind :). Cheers, Dawid Węgliński
Re: [gentoo-dev] QEMU Sick!
On Thursday 22 of January 2009 00:28:40 Mateusz Mierzwinski (me.matheos.org) wrote: [[snip]] You should use more exclamation marks. Going to Funtoo! Good night, sleep tide... Enjoy. * qemu requires gcc-3 in order to build and work correctly * please compile it switching to gcc-3. * We are aware that qemu can guess a gcc-3 but this feature * could be harmful. * * ERROR: app-emulation/qemu-softmmu-0.9.1-r3 failed. * Call stack: * ebuild.sh, line 49: Called pkg_setup * qemu-softmmu-0.9.1-r3.ebuild, line 40: Called die * The specific snippet of code: * die gcc 4 cannot build qemu * The die message: * gcc 4 cannot build qemu * * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/home/matheos/buildpkgs/tmpdir/portage/app-emulation/qemu-softmmu-0.9.1-r3 /temp/build.log'. * The ebuild environment file is located at '/home/matheos/buildpkgs/tmpdir/portage/app-emulation/qemu-softmmu-0.9.1-r3 /temp/die.env'. * Go to bugs.gentoo.org
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog use.local.desc
On Friday 02 of January 2009 22:53:36 Robin H. Johnson wrote: On Fri, Jan 02, 2009 at 01:40:09PM -0800, Alec Warner wrote: How hard would it be to change permissions on the ,v file for this and just run the use.local.desc updater as a user with different privileges? It does have different permissions. It's the directory permissions that matter however. I already tried the file permissions. If we want to truly block it while not affecting commits to the rest of the directory, we need to add CVS ACLS, which I've been meaning to do, but just never got around to. CVS does (the short version): 1. Take a file-based lock (#A) for the target ,v file. No writes permitted, reads are permitted. 2. Build the new version of the ,v in the temp space. 3. Copy the new version to a different name in the target directory. 4. Upgrade lock #A, no reads permitted now. 5. unlink the old ,v file (the kernel checks the directory permissions, not the file perms). 6. rename the new file into place. 7. Release lock #A. What about creating a hook that checks if commited file is the one in question and fails the commit, if true? I don't know much about cvs hooks, however in svn it would be simple to setup.
Re: [gentoo-dev] Proposal: disable python and perl USE flags in profile
On Monday 08 of December 2008 11:34:21 Maciej Mrozowski wrote: Following advise from https://bugs.gentoo.org/show_bug.cgi?id=250179, I'm bringing it here. Hm, i totally don't agree with the original comment from the bug. Many people get use of those two flags without even noticing it. There is bunch of good soft, that take advantages of perl modules or python bindings/wrappers. For servers it may be nagios-plugins with bunch of perl scripts for hosts monitoring or at least nice DBD::mysql. So, maybe it's better to disable such flags on your system if you don't like them - that's why you are using Gentoo, aren't you? -- Cheers, Dawid Węgliński
Re: [gentoo-dev] Re: Some support for Sunrise Overlay :-)
On Monday 24 of November 2008 09:21:33 Nikos Chantziaras wrote: Tiziano Müller wrote: Nikos Chantziaras wrote: I was told to try sunrise with some of my ebuilds. There's a reason I didn't, and I suspect it's the same other people also don't go to sunrise. There's no good way of contributing an ebuild. There's no bugzilla or website where I can upload the ebuild. All I'm told is to go to IRC. I would as well might have been required to go to McDonald's. Well, sunrise is not about uploading a package just somewhere but about having it reviewed and corrected such that it follows basic guidelines. Since this process requires bi-directional communication, IRC is a good (low-latency) way to do that. I disagree. IM does not provide for communication that can be looked-up, which is important. I post something, many people will look at it and some of them will reply. That is not possible with IM. A mailing list is also sub-optimal. A forum or bugzilla is needed where information/communication is stored and can be categorized and looked up. The previous speeker just told you sunrise cooperates with Gentoo bugzilla. :-) Anyway, if IRC is not an option for everyone (i agree it may not be), mailinglist would be good. This way any informations could be archived for next contributors. :) Cheers.
Re: [gentoo-dev] kerberos USE flag
On Friday 31 of October 2008 19:17:45 Doug Goldstein wrote: Marius Mauch wrote: On Fri, 31 Oct 2008 10:52:59 -0400 Doug Goldstein [EMAIL PROTECTED] wrote: Someone remind me again why we have the kerberos USE flag enabled by default? AFAIK it was added so that the default profile provides support for joining a Windows domain (same for the ldap flag). So let's use EAPI=1 in just the samba ebuild and do +kerberos in there. samba needs USE=ads ldap to join NT domain.
Re: [gentoo-dev] kerberos USE flag
On Friday 31 of October 2008 19:41:26 Doug Goldstein wrote: Dawid Węgliński wrote: On Friday 31 of October 2008 19:17:45 Doug Goldstein wrote: Marius Mauch wrote: On Fri, 31 Oct 2008 10:52:59 -0400 Doug Goldstein [EMAIL PROTECTED] wrote: Someone remind me again why we have the kerberos USE flag enabled by default? AFAIK it was added so that the default profile provides support for joining a Windows domain (same for the ldap flag). So let's use EAPI=1 in just the samba ebuild and do +kerberos in there. samba needs USE=ads ldap to join NT domain. heh. You beat me to the punch. I was just about to say that samba doesn't have a kerberos USE flag. So any objections to me nuking this USE flag pronto? I'd be +1 to drop kerberos useflag, and probably make use of eapi1 in nfs-utils and such, where kerberos would be more apropriate.
Re: [gentoo-dev] Announce: red5 overlay available for testing
On Friday 24 of October 2008 01:05:19 Enrico Weigelt wrote: Hi folks, YFYI, I've written a bunch of ebuilds for red5 and its deps: svn://anonymous:[EMAIL PROTECTED]/public/red5/gentoo-overlay cu Yay, thanks! Because of lack of ebuilds for red5 i had to run it on debian. :( But now, i'm able to migrate it to gentoo. Awesome! :D
Re: [gentoo-dev] Keyword policy for non standard things
On Wednesday 22 of October 2008 11:54:39 Alistair Bush wrote:
Dawid Węgliński wrote:
Hello fellow developers and users.
I'd like to know your opinion of bug #243050 [1]
01:18:59 cla @| If user bothers to patch his kernel, he can
bother to add proper package.keyword line, imo.
++
01:21:52 hparker @| Or maybe get the patches added to
gentoo-sources
or ++
maybe we can get the pm's to implement this as EAPI=999,999,999.99
I suggest a syntax of virtual/kernel:::user_patched
As far as i understand what Donnie said yesterday on irc, these patches are
going to be merged in 2.6.28, so problem in this case should be fixed in near
future. But this doesn't resolv global issue that happens for packages
requiring users input (such as patching kernel themself).
Most devs i was talking with would mark the bug as INVALID until kernel (here
{gentoo,vamilla}-sources support package in question.
On a more serious note, How can we confirm a package is stable when we
can't confirm the kernel it depends on is?
We can't, also security team wouldn't support it:
Adding a new kernel source into the tree is not recommended by the Gentoo
Security Team. Unless it is a kernel source you think could be used by a wide
number of users, please end your consideration here and simply use an
overlay. If you do believe that it is, you must be willing to become the
security maintainer.
I would have no problem with gentoo-sources also including a use flag(s)
( or not ) and having it add patches to support software we have within
the tree. I have no say in that tho.
Alistair
[gentoo-dev] Keyword policy for non standard things
Hello fellow developers and users. I'd like to know your opinion of bug #243050 [1] 01:18:02 Chainsaw @| cla: I think I don't have the hardware to test it. 01:18:32 cla @| I have it, my question is if we should keyword packages, that are supposed to run on patched kernels. 01:18:59 cla @| If user bothers to patch his kernel, he can bother to add proper package.keyword line, imo. 01:21:52 hparker @| Or maybe get the patches added to gentoo-sources 01:22:26 cla @| This is an option too. [1] - https://bugs.gentoo.org/243050
Re: [gentoo-dev] Projects without a homepage, and valid contents of HOMEPAGE (per bug 239268)
On Sunday 05 of October 2008 12:44:20 Robin H. Johnson wrote: I'm in favour of allowing the variable to empty, because I'm a lazy upstream, and I haven't even made a basic webpage for some of my projects (diradm, localshell, readahead-list, etc). lol +1 for allowing empty $HOMEPAGE
Re: [gentoo-dev] Testing is not a valid reason to package.mask
On Friday 03 of October 2008 04:14:54 Jeroen Roovers wrote: On Thu, 2 Oct 2008 17:56:39 -0700 Alec Warner [EMAIL PROTECTED] wrote: If pmask is not for testing...what is it for? The name says it all - to prevent people from automatically emerging stuff, even when ACCEPT_KEYWORDS=~arch is set. First you try for the new version: # emerge -va www-client/opera which doesn't work (it gives you the current version!). Then you try with a specific version: # emerge -va =www-client/opera-9.6* which gives you a good reason to either unmask or not unmask: !!! All ebuilds that could satisfy =www-client/opera-9.6* have been masked. !!! One of the following masked packages is required to complete your request: - www-client/opera-9.60_pre2440 (masked by: package.mask) /keeps/gentoo/portage/profiles/package.mask: # Jeroen Roovers [EMAIL PROTECTED] (26 Aug 2008) # www-client/opera snapshots are masked. Please read # http://my.opera.com/desktopteam/blog/ - www-client/opera-9.60_pre2436 (masked by: package.mask) - [...] If it merely says that the masking is for testing (and especially if testing takes many months and apparently takes place in secret) the whole point is lost on the people who have come so far and still want to press on - they'll simply ignore your warning against testing. Same way one may see masked by missing keyword note and interprete as not for your arch... So a quick note in p.mask can say it is for testing purposes, so user can choose either to install it or not. There are various valid reasons, but testing means you want to expose stuff, not hide it. There's simply no way you'd package.mask something, and at the same time explain you want it tested. Because you're preventing most ~arch systems from getting automatically widely exposed to the stuff you're intending to get tested. I don't think it's ok. ~arch isn't training ground. It's supposed to work, so asking arch teams to keywords packages that are not supposed to work isn't good. Even saying that it would kill puppies would be more valid. Just be honest and tell people what is going on. Tell them that if they use Opera snapshots, they shouldn't care about losing mail or experience frequent crashes while browsing. Anything really, just don't tell them you're testing or you find yourself excluding them from the party with a really bad excuse. This is the place i agree with you. Anyway i think package still should be p.masked with good explanation of why it is masked. -- Cheers, Dawid Węgliński
Re: [gentoo-dev] Bug wrangling
On Monday 08 of September 2008 22:22:12 Joe Peterson wrote: Christian Faulhammer wrote: everyone working on bugs, please add all people from metadata.xml to the assignee or cc field, I regularly have to search for bugs where a team and I maintain a package because only the team has been added. Second, please use full atoms (cat-egory/package) in the Summary field, so searching is easier. Sorry if this answer can be found elsewhere, but if one has a proxy maintainer (i.e. not a Gentoo dev) for a package, can/should this person be added to metadata.xml? Is there a special tag for this? I can certainly see this being helpful (so that person automatically gets on the cc list at least). Thanks, Joe Yes, and usually that's how it's done. Eg eix' metadata.xml says: maintainer email[EMAIL PROTECTED]/email nameMartin Väth/name /maintainer
Re: [gentoo-dev] What are blocks used for?
Wednesday, 16 of April 2008 11:07:20 Mateusz A. Mierzwiński wrote: Markus Rothe pisze: Mateusz A. Mierzwiński wrote: Yes, You have right but I have thinking about something like OPTION for emerge or switch to enable that function. Emerge could provide two options of working - with replace and with sending error. Maybe switch like --force-install? This is not a thread about a specific implementation of PMS. This thread is about adding specs to PMS that allow implementations (i.e. paludis or portage etc.) to do it right. -markus Yeah! Right... You know what? I think that this thread is about making Gentoo unstable, unusable and user non-friendly. Bad things are happend in Gentoo and I freezing distfiles and gentoo stages on my disk. Destroy that distro as much as You can. See yourself at DistroWatch what place have Gentoo today? Couple months ago it was 7-th place, and now? People are escaping from Gentoo - tell me Why? Maybe because bad programing practices and adding something that is not needed, and most needed things are sent back to archive of sick people complains? Try to hear others, not only Your pride... Cześć Mateusz. Myślę, że źle rozumiesz założenia pomysłu, który został zaproponowany przez Ciarana. Zrozum, że chodzi o to, żeby menadżer pakietów potrafił rozwiązywać problemy pakietów wzajemnie się blokujących i podawał użytkownikowi informację dlaczego taki blok istnieje i jak się go pozbyć. Nie twierdzę, że nie masz racji, nie twierdzę też, że ją masz. Ale patrząc na cały temat jesteś jedyną osobą, która twardo się przeciwstawia pomysłowi nie podając żadnych argumentów. Ponadto, bez obrazy, ale poziom Twojego języka nie jest być może na tyle dobry, żeby inni Cię mogli zrozumieć (robisz błędy gramatyczne itp.). Postaraj się przeczytać tę dyskusję ponownie i zrozumieć założenie pomysłu. Tu [1] masz adres do archiwum. [1] - http://archives.gentoo.org/gentoo-dev/msg_e7f929ecc22ca5bf67fc80e78e5aaa16.xml -- Cheers Dawid Węgliński signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] Major changes to the Gnome2 Eclasses
Tuesday, 18 of March 2008 07:43:35 Rémi Cardona wrote: Bo Ørsted Andresen a écrit : On Tuesday 18 March 2008 00:42:02 Gilles Dartiguelongue wrote: Now, basically, if the portage metadata or QA people could tell me a way to figure *all* the ebuilds that inherit gnome2 *and* have a pkg_preinst() function somewhere (either in the ebuild or in an eclass somewhere) I'd really appreciate it, as I really don't want to read through thousands of ebuilds to figure it out. Here is my brute force method: Wow.. :p +1 :) Gilles, I'll ping you later so that maybe we can come up with a good list based on your silly oneliners ;) $ inquisitio --repository gentoo --all-versions --compact --keys INHERITED \ --matcher exact gnome2 | cut -d' ' -f2 | tee gnome2-inherited.list [...] While inquisitio may not be faster it is certainly more reliable. Another option is to rely on the metadata cache in an rsync tree where INHERITED is the tenth line in each entry. Bo, what is inquisitio, who wrote it? Where can I get it? USE=inquisitio emerge -va paludis /me mumbles that Gentoo needs better QA tools, or at least to publicize the ones we already have :) Thanks Rémi -- Cheers Dawid Węgliński signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-gfx/inkscape: ChangeLog inkscape-0.46-r1.ebuild
Sunday, 16 of March 2008 21:10:12 Arfrever Frehtes Taifersar Arahesis wrote:
2008-03-16 20:39:50 Rémi Cardona napisał(a):
Christian Faulhammer a écrit :
Don't install COPYING.
Could repoman have a QA warning for COPYING inside DOCS= and dodoc ?
Repoman already has such QA warning in case of dodoc:
RepoMan scours the neighborhood...
ebuild.minorsyn 1
${CATEGORY}/${PN}/${PF}.ebuild: Useless dodoc 'COPYING' on line:
${LINE_NUMBER}
Not if COPYING file is inside $DOCS and is installed in the loop.
--
Cheers
Dawid Węgliński
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-gfx/inkscape: ChangeLog inkscape-0.46-r1.ebuild
Sunday, 16 of March 2008 23:58:45 Mart Raudsepp wrote:
On P, 2008-03-16 at 23:29 +0100, Jeroen Roovers wrote:
On Sun, 16 Mar 2008 21:51:12 +0100
Dawid Węgliński [EMAIL PROTECTED] wrote:
Not if COPYING file is inside $DOCS and is installed in the loop.
Doing something like this would work as well (and go equally unnoticed):
local DOCS=foo bar COPYING baz
dodoc ${DOCS}
Well, this DOCS deal is coming through gnome2.eclass, and that's how all
of the packages using that eclass are supposed to install DOCS.
I suppose we could also add a QA warning into the eclass for COPYING?
Something like:
if [[ ${DOCS/COPYING/} != ${DOCS} ]]; then
ewarn QA: Don't install COPYING file.
fi
should be enough. ;)
--
Cheers
Dawid Węgliński
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] Bugzilla enhancements wrt AT work
Saturday, 15 of March 2008 17:37:15 Torsten Rehn wrote: Two weeks ago, dirtyepic suggested making some modifications to how ATs and developers interact using Bugzilla [1]. +jakub scel: basically... instead of KEYWORDREQ/STABLEREQ +jakub create keywording and stabilization components +jakub and use flags accordingly there +jakub bugzilla already has the features, why not use them +jakub also, nuke things like TESTED and STABLE +1 -- Cheers Dawid Węgliński signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Kerberos Maintainence
Sune Kloppenborg Jeppesen pisze: On Monday 10 December 2007 15:41:47 Doug Klima wrote: [snip] Short version, we need a Heimdal and MIT-KRB5 maintainer. Preferably 2 since Heimdal and MIT are different. Did we get any maintainers for these packages? metadata/herds is still empty. If we don't get any maintainers I think we should consider Gentoo Kerberos for the future. As far as i know, Opfer knows someone who will take it. Cheers -- Dawid Węgliński -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: openswan mit Kernel 2.6.24
Mateusz Mierzwinski pisze: Hallo, Please write in English, not everybody speaks German. Christian Faulhammer pisze: Hallo, Dirk Spiekermann [EMAIL PROTECTED]: Die IPSec-tools und Openswan habe ich schon neu emerged. Auch die neue Option Authenc support im Kernel habe ich aktiviert. OpenSwan ist mittlerweile in Version 2.4.11 (nicht in Portage) erschienen, eventuell ist die Version angepasst. V-Li Disregard this message, Christian got used to Forward posts from gentoo-de ML :) -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-irc/mistbot: mistbot-0.9.ebuild metadata.xml Manifest ChangeLog
Dnia 29-10-2007, Pn o godzinie 23:03 -0700, Donnie Berkholz napisał(a):
On 22:45 Mon 29 Oct , Dawid Weglinski (cla) wrote:
Revision ChangesPath
1.1 net-irc/mistbot/mistbot-0.9.ebuild
file :
http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-irc/mistbot/mistbot-0.9.ebuild?rev=1.1view=markup
plain:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-irc/mistbot/mistbot-0.9.ebuild?rev=1.1content-type=text/plain
src_compile() {
ebegin Change build.conf to fit needs
if ! use xml; then
sed -e '/^MODS\ +=\ rss$/d' -i build.conf || die sed failed
fi
if ! use nls; then
sed -e '/^NLS = nls$/d' -i build.conf || die sed failed
fi
if ! use debug; then
sed -e '/^DEBUG = debug$/d' -i build.conf || die sed failed
fi
if ! use ssl; then
sed -e '/^SSL = ssl$/d' -i build.conf || die sed failed
fi
sed -e 's/^#ONCE\ =\ yes$/ONCE\ =\ yes/' -i build.conf || die sed
failed
What's up with some of these escaping spaces, and others not?
echo CXXFLAGS=${CXXFLAGS} build.conf
echo CXX=$(tc-getCXX) build.conf
echo PREFIX=/usr build.conf
ebegin compiling source
emake all-oneGo || die emake failed
if use doc; then
ebegin generate documentation
make doc || die make doc failed
fi
}
src_install() {
make install DESTDIR=${D} || die make install failed
Any particular reason 'emake' isn't used here or in the 'make doc' call?
Thanks,
Donnie
Fixed, thanks
Cheers
--
,-.
| Dawid Węgliński |
| [EMAIL PROTECTED] |
| cla @ irc.freenode.net |
| GPG: 295E72D9 |
`-'
signature.asc
Description: To jest część listu podpisana cyfrowo
Re: [gentoo-dev] Last rites: www-client/planet
Dnia 09-10-2007, wto o godzinie 20:56 -0600, Steve Dibb napisał(a): # Steve Dibb [EMAIL PROTECTED] (11 Aug 2007) # Old, unmaintained, pending removal www-client/planet punted Anything to use instead? Cheers -- ,-. | Dawid Węgliński | | [EMAIL PROTECTED] | | cla @ irc.freenode.net | | GPG: 295E72D9 | `-' signature.asc Description: To jest część listu podpisana cyfrowo
Re: [gentoo-dev] Guys, I need your assistance here
Dnia 20-09-2007, czw o godzinie 13:15 +0200, Arturo Garcia napisał(a): On Thursday 20 Sep 2007, George Shapovalov wrote: Thursday, 20. September 2007, Arturo Garcia Ви написали: Hi all, [...] You know, it would be helpfull to know at least a number of the bug you refer to ;). http://bugs.gentoo.org/show_bug.cgi?id=187971 Sorry for bringing this kind of crap to gentoo-dev but I had nowhere else to go. Actually you do. This should have gone to the gentoo-project mailing list. This is what we have created it for, isn't it? If the issue is not resolved there then I believe there is a whole entity that is supposed to deal with stuff like that. Well, I am not in gentoo-project, but alrightie. I will subscribe there. Also, if there are technical aspects to that discussion then those may or should be done here. Nope, just looking for devs with access. And the bug has been reopened and reassigned, so all happy now. Arturo. Bug number? I'm curious, because i'm working with jokey to make p.g.o up. Cheers -- ,-. | Dawid Węgliński | | [EMAIL PROTECTED] | | cla @ irc.freenode.net | | GPG: 295E72D9 | `-' signature.asc Description: To jest część listu podpisana cyfrowo
Re: [gentoo-dev] Last rites: x11-wm/ion2
Dnia 11-09-2007, wto o godzinie 18:36 -0700, Chris Gianelloni napisał(a): On Tue, 2007-09-11 at 17:54 -0700, Josh Saddler wrote: Mike Doty wrote: Matti Bickel wrote: Hi, as previously mentioned, ion2 is currently broken (bug #167468) and going away in favour of the soon to be stable x11-wm/ion3. It will be p.masked and removed in 30 days unless someone speaks up and solves the issues surrounding slotted lua among others (see the bug for details). didn't we yank ion from the tree because of upstream license problems? That's what I'd thought, too: http://forums.gentoo.org/viewtopic-t-559010.html Did something change? Has upstream stopped being stupid? Is he an actual human being now? Or is someone forking the code (but retaining the ion3 name)? Ehh... the Last Rites was for ion2, not ion3... as previously mentioned, ion2 is currently broken (bug #167468) and going away in favour of the soon to be stable x11-wm/ion3. So in favour of ion3 right? -- ,-. | Dawid Węgliński | | [EMAIL PROTECTED] | | cla @ irc.freenode.net | | GPG: 295E72D9 | `-' signature.asc Description: To jest część listu podpisana cyfrowo
Re: [gentoo-dev] gentoo-commits list lives!
Dnia 11-09-2007, wto o godzinie 03:55 -0700, Robin H. Johnson napisał(a): dn: uid=cla gecos: Dawid Weglinski IRL: Dawid Węgliński Display Friendly Code Numerical Code Description ę #281;Lowercase e-cedille ń #324;Lowercase n-acute Thanks -- ,-. | Dawid Węgliński | | [EMAIL PROTECTED] | | cla @ irc.freenode.net | | GPG: 295E72D9 | `-' signature.asc Description: To jest część listu podpisana cyfrowo
[gentoo-dev] Gentoo Bugday Monthly reminder
Greetings everybody! As welp is still unavailable, it's my pleasure to tell you all *It's a Bugday!* As always join #gentoo-bugs on irc.freenode.net to participate in all the fun bugfixing :) Regards, -- ,-. | Dawid Węgliński | | [EMAIL PROTECTED] | | cla @ irc.freenode.net | | GPG: 295E72D9 | `-' signature.asc Description: To jest część listu podpisana cyfrowo
Re: [gentoo-dev] New developer: Davide Italiano (dav_it)
Dnia 27-08-2007, pon o godzinie 19:02 +0300, Petteri Räty napisał(a): Here follows the usual insults and introductions of our newest addition Davide dav_it Italiano. /me opens a beer Welcome! -- ,-. | Dawid Węgliński | | [EMAIL PROTECTED] | | cla @ irc.freenode.net | | GPG: 295E72D9 | `-' signature.asc Description: To jest część listu podpisana cyfrowo
Re: [gentoo-dev] Version Formatting Issues
Dnia 19-08-2007, nie o godzinie 16:03 +0200, Florian Philipp napisał(a):
Hi!
I'm trying to create my very first ebuild and I've run into some problems.
The source is in a tarball called dLAN-linux-package-v3.tar.gz. Now I don't
know how to rename it properly to fit into our versioning scheme.
If i try to build it as it is, econf doesn't find configure.
Probably name of unpacked directory is different, so you should change
the source directory for your package variable (${S})
http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2chap=1#doc_chap2
Also you may be interested in joining #gentoo-dev-help irc channel
rather than posting to this mailing list.
Cheers
Thanks in advance!
Florian Philipp
--
,-.
| Dawid Węgliński |
| [EMAIL PROTECTED] |
| cla @ irc.freenode.net |
| GPG: 295E72D9 |
`-'
signature.asc
Description: To jest część listu podpisana cyfrowo
Re: [gentoo-dev] New Developer: Jason Smathers (jsin)
Dnia 19-08-2007, nie o godzinie 19:36 +0200, Christian Heim napisał(a): It's my pleasure to introduce to you Jason Smathers (also known as jsin on IRC), our latest addition joining the net-ftp herd. Jason is joining us from Avon (that's supposed to be in Indiana) where he's his own boss as a freelance engineer and IT consultant. When Jason isn't around computers he's either enjoying films or literature. His remaining free time he's spending with his wife and his (not-yet-born) firstborn daughter. So please welcome Jason as a new fellow developer among us ! Regards, Christian Welcome :) -- ,-. | Dawid Węgliński | | [EMAIL PROTECTED] | | cla @ irc.freenode.net | | GPG: 295E72D9 | `-' signature.asc Description: To jest część listu podpisana cyfrowo
Re: [gentoo-dev] Porting app-portage/maintainer-helper to GTK+
Dnia 15-08-2007, śro o godzinie 13:09 -0400, Luis Francisco Araujo napisał(a): Count me in! o/ And don't forget we play in one team ;-) -- ,-. | Dawid Węgliński | | [EMAIL PROTECTED] | | cla @ irc.freenode.net | | GPG: 295E72D9 | `-' signature.asc Description: To jest część listu podpisana cyfrowo
Re: [gentoo-dev] Re: net-im/pidgin protocols
Dnia 23-07-2007, pon o godzinie 13:38 +0200, Christian Faulhammer napisał(a): Eric Polino [EMAIL PROTECTED]: Would it be possible to have all the protocols for net-im/pidgin turned on by default. We often get people coming to #pidgin looking for help as to why they can't get MSN or some other protocol working. It most often is because they haven't enabled the given protocol USE flag. Without doubting the decision made about the msn USE flag, here are some quotes from a bug report: I am not sure if it's a bug ... anyway, at least on AMD64 you have removed MSN protocol. Right now I am avoiding an upgrade because the flag has been marked as not usable.[...] [Some discussion later] If I see (-msn%*) and as far as I know it means that you are removing the protocol. [Editor's note: (-msn%) means that the USE flag has been removed and was not enabled] [Even more bitching] Otherwise, if this was not the case, it's not written anywhere that this flag is incorporated oh, yes I know it is in the Changelog, and I have read it before filing this bug, but come on ... that's not the point. In this case, you should do like skype, i.e.: emerge pidgin (msn) (yahoo) (icq) spell tcl tk -avahi -bonjour ... and so far and so on ... and you should not delete/remove the flag in the way you did. Licq still uses msn flag so I user may understand that licq is the only software supporting MSN. That's why we do have ChangeLogs and --changelog switch to let users know about changes. V-Li Regards -- ,-. | Dawid Węgliński | | [EMAIL PROTECTED] | | cla @ irc.freenode.net | | GPG: 295E72D9 | `-' -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] ML changes
Dnia 14-07-2007, sob o godzinie 14:03 -0700, Christina Fullam napisał(a): [ .. ] -core stays private. I really dont see the need to change IMO. -project (call it what you will) would be for the off topic, non development emails that we so commonly see. this list would be optional for all developers. -dev (no preference for the name) would be for development discussion for devs and non-devs alike. everyone would all start out on a whitelist. any developer could opt to move a dev or non-dev to the moderated list (meaning their emails would be delayed allowing for moderation or simple release after a given time period). The check and balance for this would be that if any developer was found to be moderating someone unnecessarily, that developer themself would be moved to the moderated list by devrel for a time period without any access rights to change anything further themselves. Repeat offenders would be reviewed by devrel for further action if needed. this list would be required for all developers. I agree w/ that. I dont think for a moment that it is only non-devs causing this excessive amount of email which often results in flaming/trolling. I do agree that everyone should be bound by the same rules. Thoughts? -- Kind regards, Christina Fullam Gentoo Developer Relations Lead | GWN Author -- ,-. | Dawid Węgliński | | [EMAIL PROTECTED] | | cla @ irc.freenode.net | | GPG: 295E72D9 | `-' signature.asc Description: To jest część listu podpisana cyfrowo
Re: [gentoo-dev] Are you guys for real?
Dnia 14-06-2007, czw o godzinie 19:13 +1200, Kent Fredric napisał(a): Once somebody has learnt the truth, most find they can only deny it for so long. :) I agree a lot of the discussions turn into bitchfests, You are feeding such discussions. and it seems many of our developers are going out of their way as of late to stir the pot, but its well known that a small minority of whiners gives the majority a bad name( not to go into politics, but take a look at muslims christians in modern media, its always the extremists who are out there making the rest of them look bad by carrying their name ) Developers do their job anyway. Just take a look at packages.gentoo.org and visit bugzilla. Then end this stupid thread. Thanks -- ,-. | Dawid Węgliński | | [EMAIL PROTECTED] | | cla @ irc.freenode.net | | GPG: 295E72D9 | `-' signature.asc Description: To jest część listu podpisana cyfrowo
Re: [gentoo-dev] Living in a bubble [gentoo-proctor] Warning^2
Dnia 06-06-2007, śro o godzinie 18:32 +0200, [EMAIL PROTECTED] napisał(a): Ciaran McCreesh wrote: [EMAIL PROTECTED] wrote: Just stop claiming others are insane, abusive power-trippers just because you did not abide by a rule and got your punishment for it. I'm claiming it because plenty of other people agree. You *did* see the response that the proctors got from various Gentoo developers, right? What I saw was a response to what you as one of the I-will-reply-anyway guys caused, and I bet if people had just stayed quiet for 24 hours the thread would have died out rather quickly. The replys by other devs seem to be allmost exclusivly be based on the fact, that people like you did not take their time calming down, or if they were calm anyway, take their time to do whatever for 24 hours. Why to stop the topic? IMO it *is* important, and we should make a correct decision. You blame beejey. Ok, blame him about what he said, but paradoxically he uncovered that whole mess, that noone was talking about before. ++ for I-will-reply-anyway guys -- ,-. | Dawid Węgliński | | [EMAIL PROTECTED] | | cla @ irc.freenode.net | | GPG: 295E72D9 | `-' signature.asc Description: To jest część listu podpisana cyfrowo
Re: [gentoo-dev] New project: Gentoo Artwork
Ciaran McCreesh napisał(a): On Thu, 26 Apr 2007 19:03:02 -0600 Steve Dibb [EMAIL PROTECTED] wrote: Sweet. Are you gonna bring back those Gentoo icons that mysteriously disappeared? :) The ones with the copyright problems? I'm out of topic i think. Could you amplify, please? -- ,-. | Dawid Węgliński | | [EMAIL PROTECTED] | | cla @ irc.freenode.net | | GPG: 295E72D9 | `-' -- [EMAIL PROTECTED] mailing list
[gentoo-dev] New project: Gentoo Artwork
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there As a fresh developer i would like to introduce you all new subproject I have just started. It is Gentoo Artwork Project. Its official webpage is under [1]. Project consists of two members so far, so this is why we enlist everyone who would like to help us in creating artwork gentoo-related stuff. Do not forget to visit us in #gentoo-artwork. :) @ GWN - could you guys write about us in the next version of gwn please? [1]. http://www.gentoo.org/proj/en/desktop/artwork/index.xml Regards - -- ,-. | Dawid Węgliński | | [EMAIL PROTECTED] | | cla @ irc.freenode.net | | GPG: 295E72D9 | `-' -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGMTMwUPEOwClectkRArg9AJ9lPMdusghERBp7oQGmKPAwWjkCgwCeP7sf WRXsn5+RuqCbF2KLSoKKd58= =kQhB -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] New project: Gentoo Artwork
Jeroen Roovers napisał(a): On Fri, 27 Apr 2007 01:18:08 +0200 Dawid Węgliński [EMAIL PROTECTED] wrote: As a fresh developer i would like to introduce you all new subproject I have just started. It is Gentoo Artwork Project. Its official webpage is under [1]. Hey, there is no (fresh) artwork to see anywhere yet!?1one ;) Yeah, not yet. I'm starting with Gentoo/OpenBSD logo as a request of this project leader. @ GWN - could you guys write about us in the next version of gwn please? [EMAIL PROTECTED] is probably what you could have CC'd this to, but it's never to late to forward it. Thanks :) Kind regards, JeR -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] get pci info in Linux?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bilanchuk Vitaly napisał(a): emerge pciutils and use lspci. This question would be better asked in our user oriented support channels like #gentoo or gentoo-user mailing list. I'm sorry. I need get info using C/C++. I know lspci using 4 methods in Linux - linux_sysfs, linux_proc, intel_conf1, intel_conf2 (man 8 lspci). But: linux_sysfs - using /sys system; linux_proc - using /porc system; intel_conf1, intel_conf2 - i don't know how it work; Who now how get this information using C/C++ without using lspci? Or, how works intel_conf1 and intel_conf2 methods that using by lspci? I think You should ask on some C/C++ help channel or mailing list. - -- ,-. | Dawid Węgliński | | [EMAIL PROTECTED] | | cla @ irc.freenode.net | | GPG: 46E89CD0 | `-' -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGC/gm8nXYuEbonNARAsw9AKCh8kXcFjTehu0z6YJIYdNcoAHvUgCfTnSh G9Ees8zSLQ6AoXHAE5FE5lI= =Iuzr -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] {Guide,Project,Foo}XML too confusing for many devs?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 José Luis Rivero (yoswink) napisał(a): Alec Warner escribió: So this is getting pretty long winded; my basic question is do you as a developer find writing web pages to be confusing or difficult? Is there not a good tutorial for learning our webpage XML syntax? Do you find that you bump up against restrictions in the DTD or other problems that prevent you from expressing yourself properly? Do you have any idea how to actually go about extending GuideXML (or the other XML's we provide) Have you ever tried? Could we improve training with regards to any of this? Alec, as an alternative and if you don't want to waste your time fighting with guideXML or learning how to use it, feel free to send a request with data in plain text (and commenting the restrictions you found) to gentoo-doc list and maybe you'll find a volunteer who can create the page for you. I'm quite sure that somebody from docs-team (user or dev) will help you but, if nobody appears, I will do it. I can do it, just let me know on mail / irc (see signature) Once you've created the page, maintain it is quite easy. Regards. - -- ,-. | Dawid Węgliński | | [EMAIL PROTECTED] | | cla @ irc.freenode.net | `-' -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGCC6M8nXYuEbonNARAp7VAKChEEwmJnraSzGKyxp2qVaSMyCmQQCgqden EtiB8JB59r1rQ9bWNcvyqZg= =MdXD -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New developer: Bernard Cafarelli (voyageur)
Christian Heim wrote(a): It's my pleasure to introduce to you Bernard Cafarelli (also known as voyageur) our latest addition joining the NX herd. Bernard is joining us from Paris, France (Issy-Les-Moulineaux to be exact, but as Bernard also said, it's less known than Paris) where he's currently working as a software engineer for a company in the VoIP software environment. Bernard is proficient in two programming (C/C++) and two scripting languages (PHP/perl). When Bernard isn't in front of his computer(s), he enjoys swimming and underwater diving. To relax his head, he tries to read some good science-fiction books or going to the movies with some of his friends. Please welcome Bernard as a new fellow developer among us ! Welcome Bernard -- Dawid Węgliński [EMAIL PROTECTED] jid: [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
