Re: [gentoo-dev] package.mask cleanups
On Tuesday 24 January 2006 17:40, Diego 'Flameeyes' Pettenò wrote:
> On Tuesday 24 January 2006 16:23, Marcus D. Hanwell wrote:
> > All of the KDE stuff is the upcoming 3.5.1 release which we are working
> > on in p.mask until the official release. There *are* ebuilds for all this
> > stuff in the tree right now. So that has chopped the number of entries by
> > a fair margin, but for the script to be useful it should be able to
> > detect they have valid ebuilds.
>
> As KDE is way bigger than that is probably listing the packages that are
> still at 3.5.0 and didn't get a verbump.
> Dan probably did a for pkg in ${PORTDIR}/kde-base/*; do echo
> "=kde-base/$pkg-3.5.1*"; done >> ${PORTDIR}/profiles/package.mask or a
> variation on the theme, that's also why metadata.xml got listed, too.
Yeah... I'll be more careful next time.
--
Dan Armak
Gentoo Linux developer (KDE)
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951
pgpm7Fq8A1IJw.pgp
Description: PGP signature
Re: [gentoo-dev] Repoman and his automagic
On Saturday 28 January 2006 01:57, Alec Warner wrote: > Part of me does not want repoman to do automated tasks for developers, > and part of me wants a set of *well written* tools to aid developers in > their tasks. I mean when one commits say, all of kde, you don't want to > sit there and type in all that crap, you'd rather script it. However, I > don't see it as repoman's job to do that for you. I would like others > opinions on this though. There's one thing that'd help repoman scripting: the ability to work on several dirs at once. Just as I can run 'cvs up konqueror kmail', I want to run 'repoman konqueror kmail' - because running repoman 100 times in a package dir is slower than running it once in a category dir with 100 packages. If this request makes sense I'll open a bug if you want me to. -- Dan Armak Gentoo Linux developer (KDE) Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 pgpcpjmkGpoXM.pgp Description: PGP signature
Re: [gentoo-dev] Gratuitous useflaggery (doc and examples)
On Saturday 04 March 2006 17:15, Stuart Herbert wrote: > Hi Ciaran, > > On 3/4/06, Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > > Explanation: a USE flag for trivial stuff that isn't in /etc, doesn't > > slow anything down, doesn't introduce any dep bloat and generally > > doesn't change anything noticeable isn't a USE flag that's giving the > > user any meaningful choice or making things easier for arch teams. You > > do not get bonus points for using more USE flags. > > Another point of view are servers, where there's simply no need to > have docs installed on each and every box in a rack. There's no need > to install what a user doesn't need, and having doc and example USE > flags more widely supported means that Gentoo does a better job of > respecting the choice of users. I agree with Ciaran. IMO the convenience of having docs outweighs the modest amount of diskspace/clutter they need (average of 50 MB on my average server, when then rest of the installed packages take at least an order of magnitude more). If you're concerned about diskspace you can filter out /usr/share/doc entirely, so users do have the choice. The problem here is that the docs USE flag is off by default. Making more packages use the flag would install less docs. Has anyone actually complained that too many docs are installed by default? It's true that some users/situations don't need them, but most do, especially as long as we don't have separate server profiles. -- Dan Armak Gentoo Linux developer (KDE) Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 pgpIPKO8ctnLh.pgp Description: PGP signature
Re: [gentoo-dev] Gratuitous useflaggery (doc and examples)
On Saturday 04 March 2006 18:00, Carsten Lohrke wrote: > On Saturday 04 March 2006 16:43, Dan Armak wrote: > > If you're concerned about diskspace you can filter out /usr/share/doc > > entirely, so users do have the choice. The problem here is that the docs > > USE flag is off by default. Making more packages use the flag would > > install less docs. Has anyone actually complained that too many docs are > > installed by default? It's true that some users/situations don't need > > them, but most do, especially as long as we don't have separate server > > profiles. > > I have seen quite a few bugs about that and actually have filed one¹, > rotting in bugzilla, myself. I definitely do not care about a few hundred > KB documentation per ebuild, but some install a lot of documentation and > accumulated it's a lot of wasted space. Filtering out /usr/share/doc as a > whole is no choice, when you usually want it, but a fair share not. I agree that really large docs should be made USE-dependant. This is also consistent with Ciaran's orig post. -- Dan Armak Gentoo Linux developer (KDE) Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 pgp89TMpeXkxd.pgp Description: PGP signature
[gentoo-dev] Session/.desktop WM compatibility, DM unification
Hi all, Many WMs and DEs don't play nice with one another and don't always follow freedesktop.org rules. There's a bunch of open bugs (detailed below) and I'm sure I've missed some more. Also, different DMs (kdm, xdm, gdm, ...) have a lot of unique or, conversely, duplicated or forked scripts which aren't DM-specific and so should only exist once. I want to work on this, but cooperation between and changes to many WMs are required, so I'd like to hear from other people who are interested. These bugs all tend to get stuck, so I'm posting this to the list. Currently a user cannot easily switch WMs or DMs (or use several interchangeably) without doing a lot of manual work to carry along settings that can and should be neutral. (When I say WMs, I sometimes mean entire DEs like KDE/gnome - basically whatever gets a session entry in a DM. Gnome can switch its actual WM easily enough; that's not my point.) = Bugs overview (probably missed some): = #89870: long story, summary: .desktop files are installed in different places. KDE only reads the KDE ones, Gnome only the Gnome ones (and both use a small common set). So each DE doesn't benefit from the other's apps (.desktop files aren't just for menus but also for e.g. services/actions on mimetypes/etc). 'Lightweight' WMs with a menu are forced to choose one of the above to display. (And if you merge both, the result is currently very ugly.) #53517: xdm, kdm, gdm (don't know about entrance and such) each have their own set of a lot of configfiles: Xaccess, Xreset, Xservers, Xsession, Xsetup, Xstartup, Xwilling... Obviously bad. Today some files are shared / not duplicated (gdm <-> xdm, kdm <-> xdm), but the work is not complete. It seems gdm only has its own Xsession now, and if people confirm this I can work on getting rid of all of kdm's separate files as well. BUT I still need cooperation here because there might be some features in kdm's files which would need to be merged into the common (xdm?) ones. #26326: unifying scripts that run on X sessions startup/shutdown. A lot of non-WM-specific stuff, e.g. starting ssh/gpg agents, lives (often duplicated) in DM-specific or WM-specific scripts. #14872: unifying DM session scripts, handling of ~/.xsession, etc. The bug is closed but I think some things mentioned there haven't been fixed. Some other bugs which are assigned to specific teams like KDE would be fixed or helped along by a generic solution to the bugs above. = P.S. in some of the cases above, e.g. #89870, some people have said that KDE is the real problem because it installs several fdo-like trees (eg of .desktop files or of icons), no two of which can coexist, and all of which are outside the main tree in /usr. This may be true in some cases, but if the latest version of KDE somehow magically appeared in /usr, non-KDE users wouldn't be happy either (#89870 again). That's exactly why I want to hear others' opinions and what people would like to see. -- Dan Armak Gentoo Linux developer (KDE) Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 pgpJMOeaTUQ7R.pgp Description: PGP signature
Re: [gentoo-dev] Session/.desktop WM compatibility, DM unification
On Monday 27 March 2006 16:55, foser wrote:
> On Mon, 2006-03-27 at 00:03 +0200, Dan Armak wrote:
>
>
> > = Bugs overview (probably missed some): =
> >
> > #89870: long story, summary: .desktop files are installed in different
> > places. KDE only reads the KDE ones, Gnome only the Gnome ones (and both
> > use a small common set).
>
> This doesn't really fit in the WM/DM issue afaics. The fact just is that
> the alternative installations roots Gentoo KDE uses aren't dealt with in
> the eg. the menu config files.
It's not the only issue. Another issue is that non-KDE, e.g. Gnome, users (at
least the #89870 submitter, and it seemed to me some other commenters agreed)
don't want KDE apps in their menu. So even if there was just one KDE version
and it was installed in /usr, there would be a problem.
Cf the original #89870 bugreport and comments starting at #38.
Assume the install prefix problem is fixed somehow. What items are displayed
in each WM's menu?
Option 1: KDE only displays KDE apps, Gnome only Gnome apps. How do we decide
what is displayed in both ('neutral' apps)? Can the user edit the menu, and
include some things we don't include by default, in a WM-neutral way? What
should WMs other than KDE and Gnome display by default?
Option 2: always display everything. Problems: huge menu. KDE and Gnome and
others use different categorization. A change of the status quo, so user
community should get a chance to veto. And when using descriptions as primary
menu text (e.g. 'Text editor' instead of 'kwrite'/'gedit') some KDE and Gnome
programs have similar or identical descriptions, which looks bad to new
users.
Either way, not just menu items are involved but all .desktop files. E.g.,
mimetype descriptions/icons/handlers/action for graphical file managers. And
descriptions of various services, although I can't think of an example of
crossdesktop use offhand.
> GDM has had just its own Xsession for a long time iirc. I think most
> functionality provided by these other X* files are login manager (xdm?)
> specific. The one real issue is Xsession.
Can anyone comment regarding entrance or any other DMs?
> > #14872: unifying DM session scripts, handling of ~/.xsession, etc. The
> > bug is closed but I think some things mentioned there haven't been fixed.
>
> This is sort of the same as #26326 .
OK. I thought I saw something unique there but can't find it now, I was
probably wrong.
--
Dan Armak
Gentoo Linux developer (KDE)
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951
pgpTtDCymdz2H.pgp
Description: PGP signature
Re: [gentoo-dev] overlay support current proposal?
On Monday 27 March 2006 10:29, Paul de Vrieze wrote: > On Monday 27 March 2006 07:43, Ryan Phillips wrote: > > In actuality, Subversion does 98% of the commit in an initial > > transaction, and the blocking only occurs in the last 2% with the FSFS > > filesystem. It really isn't an issue and shouldn't prevent us from > > adopting it. > > Indeed, subversion first uploads the stuff, only then creates a new > revision. In any case one does not want multiple commits at the same time > in any case. For full portage the problems are more likely to be with svn > update. One can expect there will be a lot more updates than commits. As > the commits done are fairly small, those should not be an issue. Updates > work on the whole tree however. Initial checkouts are worse, because they > require the head to be reassembled (IIRC). Head checkout could be cached > though (but I don't think that's done currently). This thread [1] from subversion-users asked about update/checkout performance. The svn people answered that performance usually isn't constrained by reassembly time. Moreover, the older BDB repo format stores the complete latest revision, and checkouts aren't significantly faster than from FSFS. (Of course, if SVN working copies didn't contain two complete copies of the stored data plus some fat metadata, then reassembly time would likely affect checkout time.) [2] explains the SVN skip-deltas storage method. Disclaimer, I haven't run any huge-repo benchmarks myself, just pointing to possibly relevant data. [1] http://svn.haxx.se/users/archive-2005-04/0518.shtml [2] http://svn.collab.net/repos/svn/trunk/notes/skip-deltas -- Dan Armak Gentoo Linux developer (KDE) Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 pgpu7JXGFbMyT.pgp Description: PGP signature
Re: [gentoo-dev] Session/.desktop WM compatibility, DM unification
On Tuesday 28 March 2006 00:27, foser wrote: > I'm aware of the issues surrounding menus, but the spec gives a lot of > options. As said, we haven't dealt with it, because it is not a snag > that we hit currently. > > I think we can basically have several menu setups fit for different > tasks/DEs and either let loginmanagers choose on startup or users choose > on install. > > I don't know what the future plans are of KDE regarding it's slotting, > but if it intends to use syswide (fdo) specs like mime/icons the install > alternate root is going to be the main hurdle to tackle. If we make a system for selecting menu items. etc on a per-session basis, like you describe above, then I think we can easily support arbitrary additional install locations, specified in env.d or session files. I like the idea, now we need to actually design and build such a system :-) Do you think all fdo items should be controlled by it and not just menu items? Or should some things always be available (at least by default)? I'm in favor of making everything else available by default (services and so on) because 1) I think it's easier using fdo specs - menu files already support filtering and 2) the main complaint against having everything in the menus is clutter, and that's not as big a problem with e.g. filemanager context menus. -- Dan Armak Gentoo Linux developer (KDE) Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 pgpmwuMITbrjt.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo: State of the Union
On Friday 28 April 2006 20:14, Ryan Phillips wrote: > __Problem: Live Tree__ > > Having a live tree requires people to be perfect. People are not perfect > and requiring it is ridiculous. I love having commits in my local tree > within the hour, but having a stable and unstable branch makes a lot of > sense. > > CVS doesn't do branching nor tags very well... > > __Problem: CVS__ > > CVS is one of the worst application ever created. The portage tree needs > to move to subversion. A lot of the problems within the project would be > solved by using a better SCM system. The previous problems regarding the > Live Tree and Developer Growth would be solved, IMHO, by just switching. > Branches Work. Tags Work. Reverts work. Moves work. I don't see any > reason not to use it. It just plain works. > > Projects (gentoo/bsd, embedded, hardened) could choose to keep their own > branches of the portage tree and merge with trunk as needed. Projects > could stick to traditional solutions like profiles if they so wished. > > Some will probably ask who will merge between branches. We can do that > easily ourselves. If I think a package is good to go, then svn merge > -r1123:1124 to the branch. I'm very much in favor of moving to a new SCM, and I see how it could solve many problems. But I don't understand how it could remove the need for a live tree. Could you explain the new usage pattern you're suggesting here? If there's no live tree (or live branch), then every commit has to be merged from the 'incoming' branch or trunk where it is originally committed to the 'outgoing' branch which is directly used by users, even for ~arch chages. Is that really what you mean? And this becomes a lot worse if you want to replace (at least some) KEYWORDS with branches, and have to merge each change many times. Meanwhile, if no-one is using trunk (or the 'incoming' branch) directly (because it's not live), what is the benefit of leaving commits there for a few hours? It won't help you find most problems. Apart from having no live tree, though, I understand and like the model of having: - 'Incoming' (sandbox) branches where non-dev affiliates, and new devs, commit things which are then reviewed by a full dev/mentor and merged into trunk. - Branches replacing today's various overlays for devs (or projects, etc) and anyone else we might welcome on g.o infrastructure (given per-branch commit permissions). - Short-lived branches to replace things that are today package.masked. - Branches to replace various non-arch keywords and projects, like hardened stuff, some server/ultrastable tree proposals, ... -- Dan Armak Gentoo Linux developer (KDE) Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 pgp7hV8KLhwgg.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo: State of the Union
On Friday 28 April 2006 23:42, Ryan Phillips wrote: > svn > + Atomic Commits > + Merging/tagging/brancing is a simple "copy" operation >http://svnbook.red-bean.com/en/1.1/ch04.html > + lots of benefits >http://svnbook.red-bean.com/nightly/en/svn.intro.features.html >there is more I'm sure people can come up with > - 2x Drive space - No changeset/merge tracking If we have a lot of active branches and a lot of merging between them, changeset tracking could be a major plus. I've never used git but I've heard that it, and other distributed development-style SCMs, have changeset/merge tracking features that are really helpful. Could someone who's used them comment on this? -- Dan Armak Gentoo Linux developer (KDE) Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 pgpKK0WsRkHbd.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo: State of the Union
On Saturday 29 April 2006 15:21, Fernando J. Pereda wrote: > The commit marked with @ is a special comit called a 'merge'. > I hope that clarifies the merge tracking part. You just described what merging is. Svn can do that too with svn merge. But, if I merge changesets from branch A to B selectively, skipping some along the way, can I later ask git to: - list the changesets remaining in A that I haven't merged to B yet? - list the branches, from a given list, which have/haven't merged a given changeset? Those are things svn can't do. > > However I don't know what do you mean with 'changeset tracking'. I didn't mean that 'changeset tracking' is different from 'merge tracking'. -- Dan Armak Gentoo Linux developer (KDE) Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 pgprs6FwXYu3W.pgp Description: PGP signature
[gentoo-dev] Leaving Gentoo
Hi all, I'm leaving Gentoo. This isn't due to ill feelings or anything like that; I just have no time to work on Gentoo anymore, and have been 'dormant' for many months now. This isn't going to change anytime soon, and so there's no point in my keeping the account. I've enjoyed working on Gentoo over the years, and have learned a lot and met many interesting people... Take care everyone, and take care of Gentoo for me :-) Infra: please remove my accounts and cvs/ssh access, kde herd membership, and homedir. I'll unsubscribe myself from the lists as needed, but please unsubscribe me from the [EMAIL PROTECTED] and from -core, since I'm not sure how to do that myself. I'll be reachable by email at [EMAIL PROTECTED] I'd appreciate it if [EMAIL PROTECTED] email continues to be redirected for a little while, either to [EMAIL PROTECTED] or to where it currently goes via my ~/.forward. -- Dan Armak Gentoo Linux developer (KDE) Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 pgpGzYT5s5Pa6.pgp Description: PGP signature
[gentoo-dev] test, please ignore
Have been having trouble with the mailing lists... -- Dan Armak Gentoo Linux developer (KDE) Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 pgpKwfWYVHHcs.pgp Description: PGP signature
[gentoo-dev] Re: [gentoo-amd64] Re: KDE 3.4 visibility support disabled
On Thursday 26 May 2005 02:37, Duncan wrote: > Marcus D. Hanwell posted <[EMAIL PROTECTED]>, excerpted > > below, on Wed, 25 May 2005 17:48:20 +0100: > > I have just committed a fix to kde.eclass and kde-meta.eclass that > > disables visibility support in KDE 3.4 (thanks to FlameEyes for the > > patches). This was a new feature in KDE 3.4 which has caused at least one > > obvious bug, and possibly others that are less obvious[1]. > > [note the cross-posting] > > That isn't going to kill it for gcc-4.0.1-snapshots, right, only gcc-3.4? > I'll be rather unhappy if the speed increases I've been attributing to > that visibility support under gcc4, disappear! =8^( That's going to kill it everywhere, gcc4 included. The way KDE uses hidden visibility is itself broken - not gcc. Until that's fixed, we're disabling visibility support in kde. (There was a separate bug in gcc itself which got fixed, which may have confused some people...) -- Dan Armak Gentoo Linux developer (KDE) Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 pgpECtup7r5X8.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: qt.eclass
On Thursday 30 June 2005 22:37, Michael Sterrett -Mr. Bones.- wrote: > On Thu, 30 Jun 2005, Caleb Tennis wrote: > > Understandable, but I don't know any other way to do it. The function > > does nothing more than return a list of ebuild versions to make the > > depend happy. It doesn't rely on anything dynamic. > > > > $(qt_min_version 3.3) == "|| ( =x11-libs/qt-3.3.3 =x11-libs/qt-3.3.3-r1 > > =x11-libs/qt-3.3.3-r2 =x11-libs/qt-3.3.3-r3 =x11-libs/qt-3.3.4 ) > > Why use a function then? Why not just supply a variable in the eclass that > is put in the DEPEND? Because the function takes a parameter - the minimal version required from which to start the list in the ||. Any everyone who thinks functions inside $DEPEND are iffy should look at deprange() and deprange-dual()... /me hides -- Dan Armak Gentoo Linux developer (KDE) Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 pgp057Yns1Gpi.pgp Description: PGP signature
[gentoo-dev] KDE 3.4.1 keyworded stable on x86, amd64
Hi all, We finally have a stable-keyworded KDE 3.4.x. Enjoy :-) If you're using monolithic ebuilds (this include all 3.3.x ebuilds) consider moving to the split ones: http://www.gentoo.org/doc/en/kde-split-ebuilds.xml There are no explicit instructions for upgrading from the monolithic to the split ebuilds there (TODO) and apparently that confused some people, so I'll summarize: When upgrading from KDE 3.3.x, you can just emerge split ebuilds freely. When upgrading from KDE 3.4.x monolithic to 3.4.x split, it's easiest to first unmerge the monolithic ebuilds and then emerge the split ones. There are a few hours in between with nothing installed, so it's good for an overnight install. (You can do it for each monolithic package in turn.) -- Dan Armak Gentoo Linux developer (KDE) Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 pgptyCTW0s4aQ.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: qt.eclass
On Thursday 30 June 2005 23:36, Aron Griffis wrote: > Dan Armak wrote: [Thu Jun 30 2005, 04:06:03PM EDT] > > > Because the function takes a parameter - the minimal version > > required from which to start the list in the ||. > > Makes sense. > > > Any everyone who thinks functions inside $DEPEND are iffy should > > look at deprange() and deprange-dual()... /me hides > > They're definitely iffy. Try this at a bash prompt: > > DEPEND="$(exit 1)" > > See the problem? It didn't exit. That's what will happen if > a function in DEPEND fails: nothing. Except that yours will currently > stick this in DEPEND: > > !!! error: qt_min_version called with invalid parameter: \"$1\", > please report bug > Instead of 'exit 1', qt_min_version should use die. I use that in deprange and it does work inside $DEPEND. -- Dan Armak Gentoo Linux developer (KDE) Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 pgpFR8CXBg7se.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: qt.eclass
On Friday 01 July 2005 00:38, Aron Griffis wrote: > Dan Armak wrote: [Thu Jun 30 2005, 05:11:10PM EDT] > > > Instead of 'exit 1', qt_min_version should use die. I use that in > > deprange and it does work inside $DEPEND. > > Well, it's more visible, but it doesn't stop the emerge. I just put > DEPEND="$(die)" into an ebuild to test. Here is what happens. It > also gives you an idea of why putting functions into DEPEND is bad: > they get evaluated A LOT. (jump down for more message content) I see now that in my case, emerge aborted on die() due to a side effect: beta kchmviewer # emerge konqueror -pv These are the packages that I would merge, in order: Calculating dependencies waiting for lock on /dev/shm/aux_db_key_temp.portage_lockfile !!! ERROR: kde-base/konqueror-3.4.1 failed. !!! Function deprange-list, Line 426, Exitcode 0 !!! deprange(): unsupported parameters 1 2 - BASEVER must be identical !!! If you need support, post the topmost build error, NOT this status message. - !!! Problem in kde-base/konqueror dependencies. !!! too many values to unpack exceptions ...OK, so deprange() needs to signal errors out-of-band. Like setting a KM_ERROR variable which causes the eclass to abort later on. -- Dan Armak Gentoo Linux developer (KDE) Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 pgpTRjWP1GFKs.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: qt.eclass
On Friday 01 July 2005 12:15, Paul de Vrieze wrote: > On Thursday 30 June 2005 23:11, Dan Armak wrote: > > Instead of 'exit 1', qt_min_version should use die. I use that in > > deprange and it does work inside $DEPEND. > > Wouldn't this be a good time to implement actual dependency ranges in > portage. Wouldn't any time be a good time? :-) > Btw. I normally use the following hack that portage might > actually be made to understand: > > DEPEND="http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 pgpbLY3fAf31a.pgp Description: PGP signature
Re: [gentoo-dev] RFC: qt.eclass
On Friday 01 July 2005 11:55, Chris Bainbridge wrote: > On 30/06/05, Olivier Crete <[EMAIL PROTECTED]> wrote: > > On Thu, 2005-30-06 at 15:09 -0500, Caleb Tennis wrote: > > > I'm sorry, yes, that's what I do in this case. > > > > > > Also, the eclass is in portage if anyone is so inclined to see how > > > harmless it really i > > > > Why not just use =qt-3.3 since qt3 probably wont have any new major > > release ? > > This would seem like the easiest option. Is there any reason not to do > it this way? Sometimes we need to specify a minimal version or revision because something depends on specific fixes made there and needs to force a qt upgrade. -- Dan Armak Gentoo Linux developer (KDE) Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 pgpX6M6iKO26J.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: qt.eclass
On Friday 01 July 2005 16:56, Aron Griffis wrote:
> Dan Armak wrote: [Fri Jul 01 2005, 03:42:22AM EDT]
>
> > ...OK, so deprange() needs to signal errors out-of-band. Like setting a
> > KM_ERROR variable which causes the eclass to abort later on.
>
> Heh, doesn't work for the same reason you can't exit. It's
> a subshell.
>
> How about this?
>
> ebuild:
> DEPEND="some stuff"
> qt_min_dep "3.3"
>
> eclass:
> qt_min_dep() {
> if cool; then
> DEPEND="${DEPEND} new stuff"
> else
> die "..."
> fi
> }
>
Would work, but be against the general move to make the general ebuild section
purely declarative :-( I don't want to change a great deal of code merely to
catch incorrectly written ebuilds, when we can already print messages on
stderr.
I'd rather signal failure to code outside the subshell by touching a file in
$T.
--
Dan Armak
Gentoo Linux developer (KDE)
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951
pgpuioGFDf2I3.pgp
Description: PGP signature
Re: [gentoo-dev] Re: RFC: qt.eclass
On Friday 01 July 2005 18:14, Jonathan Smith wrote: > - gpg control packet > > Thomas de Grenier de Latour wrote: > > Btw, what's wrong with the `DEPEND="$(your_function)" || die` > > > > i've proposed? Using a return code seems to be the simplest way > > to signal a failure, no? > > calling a function in a global scope is a bad idea. it leads to lots of > unneccessary (and timely) computations Necessary in the case of kde split ebuilds. Take a look at kde-functions.eclass::deprange(). -- Dan Armak Gentoo Linux developer (KDE) Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 pgpY4Deq30kXt.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: qt.eclass
On Friday 01 July 2005 18:03, Thomas de Grenier de Latour wrote:
> On Fri, 1 Jul 2005 17:45:57 +0300
>
> Dan Armak <[EMAIL PROTECTED]> wrote:
> > I'd rather signal failure to code outside the subshell by
> > touching a file in $T.
>
> The ${T} directory does not exists when portage source an ebuild
> to get its metadatas, so I'm not sure that's a good idea.
>
> Btw, what's wrong with the `DEPEND="$(your_function)" || die`
> i've proposed? Using a return code seems to be the simplest way
> to signal a failure, no?
Sorry, I missed it the first time... Looks like a good way, yes (haven't
tested).
--
Dan Armak
Gentoo Linux developer (KDE)
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951
pgpw9chQK33m1.pgp
Description: PGP signature
Re: [gentoo-dev] Re: RFC: qt.eclass
On Friday 01 July 2005 23:19, Paul de Vrieze wrote: > On Friday 01 July 2005 17:14, Jonathan Smith wrote: > > Thomas de Grenier de Latour wrote: > > > Btw, what's wrong with the `DEPEND="$(your_function)" || die` > > > > > > i've proposed? Using a return code seems to be the simplest way > > > to signal a failure, no? > > > > calling a function in a global scope is a bad idea. it leads to lots of > > unneccessary (and timely) computations > > It also makes any attempts to parse ebuilds without using bash (our current > strategy) a lot harder (actually causing bash reimplementation) You mean you're actually doing that for portage-cvs? I didn't know that. Does 'our current strategy' refer to using bash or to not using it? Anyway, as far as portage goes, if we had version range deps support we wouldn't need functions in $DEPEND. -- Dan Armak Gentoo Linux developer (KDE) Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 pgpYA48zJK20i.pgp Description: PGP signature
Re: [gentoo-dev] /etc/env.d/46kdepaths belongs to arts.. error?
On Saturday 02 July 2005 15:12, Niklas Herder wrote: > Hi, > > I'm not sure if this is a bug or feature, so I haven't filed a bug yet... > > After some upgrading and maintenance, kdm wasn't found by the xdm script > on my box. > > After some investigations, I found that /etc/env.d/46kdepaths was gone. > When I checked on another computer what package that file belongs to, it > turned > out that the missing package was arts, which I don't use. When building with USE=-arts kdelibs installs this file instead. If you built with USE=arts and then unmerged arts your system is broken anyway and you need to remerge kdelibs with the updated USE. > > Isn't this a bit weird? Shouldn't the paths belong to kdebase or some > other more > basic kde package? Arguably a separate, slotted ebuild whose job would be just to install this file would be nicer... At least arts is going away with kde 3.x :-) -- Dan Armak Gentoo Linux developer (KDE) Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 pgpu82yBy3Wjv.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: qt.eclass
On Saturday 02 July 2005 14:43, foser wrote: > On Fri, 2005-07-01 at 18:33 +0300, Dan Armak wrote: > > > calling a function in a global scope is a bad idea. it leads to lots of > > > unneccessary (and timely) computations > > > > Necessary in the case of kde split ebuilds. Take a look at > > kde-functions.eclass::deprange(). > > So you create functions to do things portage really should do ? Wouldn't > pushing the portage team to finally implement a major feature like > depranges be a better idea ? They said a major feature like dep version ranges would never be in a stable portage 2.0.x, so I wrote deprange() as a temporary stop-gap measure because there was no other feasible way to write the split kde ebuilds. The request is in bug 33545. Maybe I didn't push them enough :-/ > > The gnome team has been dealing with these things forever, but we have a > preference for a global solution instead of inventing our own wheel. I've a preference for that too, I just wasn't up to writing a patch for portage at the time. Maybe I should try to do that now, depending on their answer to my new comment in 33545... -- Dan Armak Gentoo Linux developer (KDE) Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 pgpZleaWmRJ97.pgp Description: PGP signature
Re: [gentoo-dev] Re: /etc/env.d/46kdepaths belongs to arts.. error?
On Saturday 02 July 2005 18:47, Duncan wrote: > Dan Armak posted <[EMAIL PROTECTED]>, excerpted > > below, on Sat, 02 Jul 2005 15:33:34 +0300: > > At least arts is going away with kde 3.x :-) > > I read the rumors on that about a year ago, I'd guess, and have been > trying to keep up with it. Unfortunately as I've been the de facto point > man on a couple of newsgroups (one aka the Gentoo amd64 list, tho there > are Gentoo KDE devs there now), because I just seemed to know more about > it than anyone else, I've heard essentially /nothing/ on it since then. I'm hardly a reliable source on this, I can only repeat what I've seen on the kde-devel and kde-core-devel mailing lists, and I've probably missed some relevant posts there. Other kde@ people should add to what I say here... > > Back then, there wasn't even a solid proposal as to what would replace > ARTS' various functions. The best solution seemed to be the desktop.org > common solution, only nobody knew what it would look like or when that > would be ready for practical deployment (if ever) either. gstreamer and > other possible partial solutions came up as well. Just plain ALSA's nice, > but Linux-only, so that doesn't work to well. JACK's nice and certainly > cures the latency issues so common in ARTS and other sound daemons of the > era, but it has its own issues -- not /enough/ latency for smooth play on > some kernels and in some instances. I say aRts is going away because it's nearly or entirely unmaintained for a long time now and has been declared dead many times in many forums. AFAIK it's not been decided yet what to replace it with beyond what you already wrote here. > So... what has happened since then, where are we now in the journey, does > whatever look to be ready for KDE's use, and how many more KDE 3.x > releases before KDE 4.0 comes out? (Last year they were talking a quick > 3.4 and then buckling down for 4.0, but now I read about a 3.5 around the > corner. More?) I know there's a new thingy called kdemm, but it's just a framework IIRC; it will still need a sound daemon doing mixing and output behind the scenes. The daemon is what hasn't been decided on yet, but maybe kdemm will support a choice of several (I've no idea if that'll happen). > If there are any informative URLs I've missed, either about KDE 4.0 sound, > or the current KDE roadmap, pointing me to those will be fine. No idea. There don't tend to be many things on static webpages about kde HEAD development and plans. > The latest > release plan I see is still for 3.4.0 and dated from late last year! I guess that page will be updated sometime before the 3.5 release cycle actually starts with alpha1... There's a 3.5 feature plan at http://developer.kde.org/development-versions/kde-3.5-features.html, and a recent short m/l thread about the release plan starts at http://lists.kde.org/?l=kde-core-devel&m=111934060916267&w=2, which isn't conclusive but is nearly so. > It's > still talking about 3.4 being the last feature release of the 3.x series, > but as I said, I now see talk of a 3.5 before 4.0. 3.5 is a made decision. It should be released somewhere this autumn. There was talk about it being an apps-only release, with kdelibs focusing on QT4 porting and KDE4 development and having few or no new features, but that's been dropped apparently and KDE4 coding will start on a really big scale only after 3.5. > At least Qt-4.0 is out > now, so KDE-4.0, based on it, shouldn't be /too/ far away. The thread referenced above gives July 2006 as a tentative target date. -- Dan Armak Gentoo Linux developer (KDE) Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 pgpUo5FI8JjRJ.pgp Description: PGP signature
Re: [gentoo-dev] RFC: qt.eclass
On Saturday 02 July 2005 22:41, Gregorio Guidi wrote: > First, a new eclass for Qt4 ebuilds should really be called qt4.eclass, > with another one, qt3.eclass, to be used to port the current Qt3-based > ebuilds. Dealing with more than one major version in a single eclass is a > pain; this is mostly true for the kde eclasses, but still applies to Qt. > In fact, we need to introduce a new clean eclass for KDE4-based > applications, so starting from scratch with a kde4.eclass and a qt4.eclass > makes a lot of sense. [...] > An application based on Qt4 should look just like this: > > inherit qt4 > > HOMEPAGE=... > SRC_URI=... > ... [...] > This proposal is meant for Qt, but it should be read as a proposal for both > Qt and KDE: we can have a kde4.eclass and a kde4-info.eclass that work in > the same way. I know you know this, but for other readers, this is exactly the design of the current kde.eclass+kde-functions.eclass :-) At least it was until they gathered up a huge amount of special cases and backward support. Today a typical kde ebuild still looks as simple as that, but sometimes you need to know how to work around some sensitive points (like the recent bug where the eclass fails to disable the broken visibility support...), and for kde-base you also need to know deprange() and some other tricks. Although the notation PATCHES="$FILESDIR/foo.diff" didn't catch on well enough for some reason. Other than me, most people seem to prefer to override src_unpack just to call epatch... So if we ever get a chance to cleanup the existing kde3 eclasses they'll look just like that, and might even share some code with the new kde4 eclasses (which should be separate due to kde4's completely new build system). (Mmm GLEP 33...) -- Dan Armak Gentoo Linux developer (KDE) Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 pgpaiG8rxHKRN.pgp Description: PGP signature
Re: [gentoo-dev] use.desc and use.local.desc cleanup
On Wednesday 06 July 2005 01:36, Sven Wegener wrote: > Unused global flags: > usepackagedmakefiles Removed, even if the functionality comes back we won't be using a USE flag as it triggers unnecessary rebuilds with emerge --newuse. -- Dan Armak Gentoo Linux developer (KDE) Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 pgpiEBoknwyLH.pgp Description: PGP signature
Re: [gentoo-dev] *DEPEND mismatches
On Wednesday 06 July 2005 03:00, Sven Wegener wrote:
> I want developers to take a look at the list and see if packages they
> maintain are listed. I'm aware that the list is quite large and still
> contains a lot of false positives. I can whitelist packages for DEPEND
> or RDEPEND either general, based on eclass usage or for a specific
> package. If you are sure that your package has a safe mismatch, I can
> add it to the whitelist. But please one after the other, this is just an
> initial test.
DEPEND.blacklist of net-wireless/wireless-tools is incorrect.
kde-base/kwifimanager compiles against iwlib.h.
Please whitelist for REPEND only:
media-video/transcode
app-admin/sudo
app-dicts/dictd- (used by app-dicts/dictd-dicts)
media-libs/media-gst-plugins-* (packages DEPEND on media-libs/gstreamer and
RDEPEND on plugins for it)
kde-base/artsplugin-* (packages DEPEND on kde-base/arts and RDEPEND on plugins
for it)
kde-base/kdebase-data (datafiles only useful at runtime)
kde-base/kde{base,multimedia,pim,sdk}-kioslaves
app-crypt/qca-tls (QCA plugin; things DEPEND on qt, RDEPEND on qca-tls)
kde-base/kdebase-startkde is essentially a -meta ebuild and should be listed
for RDEPEND-only usage.
Also, if you're whitelisting individual ebuilds, these deps are correct (more
or less everything you had listed for kde-base, but I went and checked what I
wasn't sure about anyway):
kde-base/kappfinder, kde-base/kdebase
RDEPEND.only: kde-base/kicker
kde-base/kaudiocreator, kde-base/kdemultimedia, kdemultimedia-kioslaves
RDEPEND.only: media-libs/flac, media-sound/lame (uses cli tools not
libs)
kde-base/kcontrol, kde-base/kdebase
RDEPEND.only: kde-base/kcminit, kde-base/kdebase-data, kde-base/kdesu,
kde-base/khelpcenter, kde-base/khotkeys (runtime dynamic loading of libs)
kde-base/kdeaccessibility, kde-base/kttsd:
RDEPEND.only: app-accessibility/festival, app-accessibility/epos,
app-accessibility/flite, app-accessibility/freetts (use cli tools)
kde-base/kdebase-kioslaves, kde-base/kdebase
RDEPEND.only: kde-base/kdialog
kde-base/kdegraphics-kfile-plugins, kde-base/kdegraphics
RDEPEND.only: app-text/xpdf
kde-base/kdelirc, kde-base/kdeutils:
RDEPEND.only: app-misc/lirc
kde-base/kdesktop, kde-base/kdebase
RDEPEND.only: kde-base/kcheckpass, kde-base/kdialog
kde-base/kdvi, kde-base/kdegraphics
RDEPEND.only: app-text/tetex, app-text/ptex, app-text/cstetex,
app-text/dvipdfm
kde-base/kghostview, kde-base/kdegraphics
RDEPEND.only: virtual/ghostscript
kde-base/konqueror-akregator, kde-base/kdeaddons
DEPEND.only: || ( kde-base/konqueror kde-base/kdebase )
RDEPEND.only: || ( kde-base/akregator kde-base/kdepim )
kde-base/kontact-specialdates
RDEPEND.only: kde-base/kmail (only to send mail with)
kde-base/kpovmodeler, kde-base/kdegraphics
RDEPEND.only: media-gfx/povray
kde-base/krdc, kde-base/kdenetwork
RDEPEND.only: net-misc/rdesktop
kde-base/ksirc, kde-base/kdenetwork
RDEPEND.only: dev-perl/IO-Socket-SSL
kde-base/quanta, kde-base/kdewebdev
RDEPEND.only: kde-base/kfilereplace, kde-base/kimagemapeditor,
kde-base/klinkstatus, kde-base/kommander, kde-base/kxsldbg, app-text/htmltidy
--
Dan Armak
Gentoo Linux developer (KDE)
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951
pgpaesvm1X32t.pgp
Description: PGP signature
Re: [gentoo-dev] No automatic RDEPEND=DEPEND for ebuild and eclass anymore
On Thursday 07 July 2005 02:40, Sven Wegener wrote: > For the ebuild part the plan is to remove the automatic RDEPEND=DEPEND > setting from portage. What's the timeline for this? Are we talking about a change in portage-cvs (which itself is supposed to be released when?) or in the next 2.0.x rev? -- Dan Armak Gentoo Linux developer (KDE) Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 pgp60vvanNBxY.pgp Description: PGP signature
[gentoo-dev] Proposed change to base.eclass: patch || die
Hi all,
base.eclass (which inherited by many other eclasses) has an src_unpack
supporting patching from patchfiles listed in $PATCHES. However, today, if
patching fails the process doesn't abort. So I propose:
==
--- base.eclass 11 Jul 2005 15:08:06 - 1.27
+++ base.eclass 29 Jul 2005 13:45:39 -
@@ -35,11 +35,11 @@ base_src_unpack() {
cd ${S}
for x in $PATCHES; do
debug-print "$FUNCNAME: autopatch: patching
from ${x}"
- patch -p0 < ${x}
+ patch -p0 < ${x} || die "Patchfile $x failed
to apply"
done
for x in $PATCHES1; do
debug-print "$FUNCNAME: autopatch: patching
-p1 from ${x}"
- patch -p1 < ${x}
+ patch -p1 < ${x} || die "Patchfile $x failed
to apply"
done
;;
all)
This will make some ebuilds fail which accidentally rely on non-applying
patches, which is the correct thing to do IMHO. Objections?
--
Dan Armak
Gentoo Linux developer (KDE)
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951
pgp3JxWxcL9Pi.pgp
Description: PGP signature
Re: [gentoo-dev] Proposed change to base.eclass: patch || die
On Friday 29 July 2005 16:57, Diego 'Flameeyes' Pettenò wrote: > On Friday 29 July 2005 15:56, Dan Armak wrote: > > base.eclass (which inherited by many other eclasses) has an src_unpack > > supporting patching from patchfiles listed in $PATCHES. However, today, > > if patching fails the process doesn't abort. > > Why can't we just use epatch? We can. It's just that base.eclass existed long before epatch, so it doesn't use it :-) Anyway, the effective change would be to die if patching fails (and support patchlevels != 0), so my orig question stands. -- Dan Armak Gentoo Linux developer (KDE) Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 pgp1TSvWrd5Iy.pgp Description: PGP signature
Re: [gentoo-dev] Re: Proposed change to base.eclass: patch || die
On Friday 29 July 2005 17:58, Duncan wrote: > Diego 'Flameeyes' Pettenò posted > <[EMAIL PROTECTED]>, excerpted below, > > on Fri, 29 Jul 2005 16:11:46 +0200: > > On Friday 29 July 2005 16:05, Dan Armak wrote: > >> Anyway, the effective change would be to die if patching fails (and > >> support patchlevels != 0), so my orig question stands. > > > > epatch already takes care of failing, that's why I was thinking about > > that > > > > :) > > More on the point... what about replacing the current base.eclass code > with appropriate calls to epatch? This would mean changes/fixes to epatch > would automatically propagate, while continuing to maintain compatibility > by keeping the base.eclass functionality around. Well as I wrote in my previous reply, I see no objection. I wanted to make sure this is OK with all base.eclass users, beyond kde.eclass. -- Dan Armak Gentoo Linux developer (KDE) Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 pgpa2Zp1GeNXy.pgp Description: PGP signature
Re: [gentoo-dev] Proposed change to base.eclass: patch || die
On Friday 05 August 2005 12:34, Diego 'Flameeyes' Pettenò wrote: > On Friday 29 July 2005 15:56, Dan Armak wrote: > > base.eclass (which inherited by many other eclasses) has an src_unpack > > supporting patching from patchfiles listed in $PATCHES. However, today, > > if patching fails the process doesn't abort. > > About this, there are still problems about committing a change on > base.eclass to use epatch instead of patch? (so that it also takes care of > recognize the right strip option) I don't think there are any problems. I've been using a modified base.eclass that died if patching failed for the last few weeks, so I know the packages I have installed don't have failing patches. Since this thread started I've modified it to use epatch and so far that's worked OK. So I think we can commit this (with epatch, that is). Can I consider the thread so far a consensus to let me do it? BTW, I've managed to lost all my mail from Thursday, so if there was something relevant in this thread could someone please forward it to me. -- Dan Armak Gentoo Linux developer (KDE) Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 pgp57yoBzRYYI.pgp Description: PGP signature
Re: [gentoo-dev] modular X - 7.0 RC1
On Thursday 20 October 2005 09:11, Donnie Berkholz wrote: > Metabuilds should be forthcoming shortly. I'd appreciate input on > http://dev.gentoo.org/~spyderous/xorg-x11/metabuilds.txt and in > particular from people on the GNOME and KDE teams. KDE doesn't have any special requirements. It doesn't use any kind of X11 build tool (what is there other than imake?). It does use some X apps like xmessage, xset etc. After you commit your metaebuilds we'll update the deps as needed. The only metaebuild we'll need to depend on is -libs. However, consider this usecase: user (who's used to the old docs) installs new stage3, types 'emerge kde', runs kdm... oops, no X server... To keep the current behaviour, the kde metaebuild (and gnome and the other WMs) would have to depend on xorg-x11, which strictly speaking is unnecessary. Opinions? How can we educate the users to manually 'emerge xorg-x11'? Personally I'm in favor of updating the docs, making a big announcement on all channels, and preparing a nice bug to close duplicates against. We'll also need to educate them about xorg-x11 not installing fonts any longer. The way I understood your metabuilds.txt, 'emerge xorg-x11 kde' would result in an unusable system without any fonts at all... -- Dan Armak Gentoo Linux developer (KDE) Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 pgp4odBqw3E5B.pgp Description: PGP signature
Re: [gentoo-dev] modular X - 7.0 RC1
On Thursday 20 October 2005 17:23, Mike Williams wrote: > On Thursday 20 October 2005 14:26, Dan Armak wrote: > > To keep the current behaviour, the kde metaebuild (and gnome and the > > other WMs) would have to depend on xorg-x11, which strictly speaking is > > unnecessary. Opinions? How can we educate the users to manually 'emerge > > xorg-x11'? Personally I'm in favor of updating the docs, making a big > > announcement on all channels, and preparing a nice bug to close > > duplicates against. > > > > We'll also need to educate them about xorg-x11 not installing fonts any > > longer. The way I understood your metabuilds.txt, 'emerge xorg-x11 kde' > > would result in an unusable system without any fonts at all... > > As a fairly average joe user when it comes to all things X, I feel it would > be best to keep the current X USE flag behaviour, i.e. a full working > Xserver. The same goes for xorg-x11, or virtual/x11. That's not the meaning of the flag. Its meaning is 'enable optional X11 support'. Usually (almost always) this means client X support. For apps that really have optional support for the xorg-x11 server, a new USE flag might be introduced. > KDE needs some X libs, so obviously must always depend on them, but having > the X USE set should call in a complete working server. > > For packages that can work with, or without X, and should give the option > to have a full server, or not, perhaps a new USE flag is needed? Xlibs? No. That would change the meaning of the X USE flag. We could add a new USE flag, but we shouldn't rename existing ones. In any case, the decision of optional clientside X support (the X USE flag today) should be completely separate from the decision of installing a local X server. -- Dan Armak Gentoo Linux developer (KDE) Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 pgprzCe3AR5xn.pgp Description: PGP signature
Re: [gentoo-dev] modular X - 7.0 RC1
On Thursday 20 October 2005 17:28, Luca Barbato wrote: > Dan Armak wrote: > > On Thursday 20 October 2005 09:11, Donnie Berkholz wrote: > > To keep the current behaviour, the kde metaebuild (and gnome and the > > other WMs) would have to depend on xorg-x11, which strictly speaking is > > unnecessary. Opinions? How can we educate the users to manually 'emerge > > xorg-x11'? Personally I'm in favor of updating the docs, making a big > > announcement on all channels, and preparing a nice bug to close > > duplicates against. > > > > We'll also need to educate them about xorg-x11 not installing fonts any > > longer. The way I understood your metabuilds.txt, 'emerge xorg-x11 kde' > > would result in an unusable system without any fonts at all... > > a useflag could solve the issue as well a all inclusive metaebuild for X. To solve this issue it would have to be an on-by-default flag, i.e. 'noxserver'. I know some people are strongly against nofoo flags. Also, we'd have to include RDEPEND="!noxserver? ( x11-base/xorg-x11 )" in every ebuild in the tree being updated to depend on x11-base/xorg-libs. Or an eclass to the same effect. This would be easily forgotten in new ebuilds, and then we'd get inconsistent behavior. -- Dan Armak Gentoo Linux developer (KDE) Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 pgpS1CZ3STx48.pgp Description: PGP signature
Re: [gentoo-dev] modular X - 7.0 RC1
On Thursday 20 October 2005 09:11, Donnie Berkholz wrote: > Metabuilds should be forthcoming shortly. I'd appreciate input on > http://dev.gentoo.org/~spyderous/xorg-x11/metabuilds.txt and in > particular from people on the GNOME and KDE teams. Don't forget a new virtual/x11-libs. And we'll need to update the entire tree to depend on that instead of virtual/x11. -- Dan Armak Gentoo Linux developer (KDE) Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 pgpsblqYpO4Ie.pgp Description: PGP signature
Re: [gentoo-dev] modular X - 7.0 RC1
On Thursday 20 October 2005 20:37, Donnie Berkholz wrote: > I'd prefer that people don't come to depend on metabuilds at all. OK, we can do this. > See > http://dev.gentoo.org/~spyderous/xorg-x11/porting_to_modular_x_howto.txt. That file says there won't be any x11-related virtuals anymore. Are you sure no package uses it in the sense of 'any X server' instead of 'any X client libs+headers'? > Couple of ideas here. > > 1) We do as you suggest, and make people emerge xorg-x11 > 2) KDE could add a USE=X and dep X? ( xorg-server ) (2) is bad for several reasons: Firstly, as I said in my other replies, this would change the current meaning of the X USE flag. The original meaning would stay without a flag. Today it means 'enable support for clienside X11'. You want to make it mean 'install X11 server'. If I'm building a headless box without an X11 server, but I do want to emerge KDE and run it over ssh -Y from another box, I need two useflags to specify this. But even if we introduce a new USE flag 'Xserver', on by default where X is on by default, and used as you describe above, the problems I describe below will remain. Secondly, there can be more than one X11 server (kdrive, etc). Depending on xorg-server is bad. If anything, we should introduce a virtual/x11-server. Thirdly, it's a 'convenience dep': whether xorg-server is installed or not won't affect the behavior of KDE in any way (given a working DISPLAY setting). Finally, it requires that extra change to (ideally) all X11 client apps. It's not intuitive, and so easy to forget when writing new ebuilds. > We will still install some fonts, but not all, and I'll note that in the > metabuilds text. Which ones? Selected how? I'm asking because I don't want to work too hard on deciding which fonts KDE should depend on :-) -- Dan Armak Gentoo Linux developer (KDE) Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 pgp2gseUnt2ln.pgp Description: PGP signature
Re: [gentoo-dev] modular X - 7.0 RC1
On Thursday 20 October 2005 20:58, Matthijs van der Vleuten wrote: > On 10/20/05, Dan Armak <[EMAIL PROTECTED]> wrote: > > To solve this issue it would have to be an on-by-default flag, i.e. > > 'noxserver'. I know some people are strongly against nofoo flags. > > What about an off-by-default 'xserver' flag? It wouldn't solve the problem at hand. Without any flag at all, the user needs to 'emerge xorg-x11' manually to get eg KDE to run locally. With an off-by-default flag, he needs to set it on manually, _before_ installing KDE, to get an xorg-x11 server. As long as he needs to do something manually, explicitly, it should just be an 'emerge xorg-x11', which after all is a very simple operation. -- Dan Armak Gentoo Linux developer (KDE) Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 pgpZhlrR5O2af.pgp Description: PGP signature
Re: [gentoo-dev] modular X - 7.0 RC1
On Thursday 20 October 2005 20:43, Donnie Berkholz wrote: > - gpg control packet > > Dan Armak wrote: > | On Thursday 20 October 2005 17:28, Luca Barbato wrote: > |>a useflag could solve the issue as well a all inclusive metaebuild for X. > | > | To solve this issue it would have to be an on-by-default flag, i.e. > | 'noxserver'. I know some people are strongly against nofoo flags. > > Or, you could just activate it in the base profile. True. I forget - why can't we solve the problem of all nofoo USE flags this way? Or is the (remaining) problem only with local flags? -- Dan Armak Gentoo Linux developer (KDE) Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 pgphCVeSxtMql.pgp Description: PGP signature
Re: [gentoo-dev] modular X - 7.0 RC1
Your mua or some gateway has inserted really ugly linebreaks in the text you quoted. I tried to make it prettier. On Thursday 20 October 2005 21:17, Donnie Berkholz wrote: > I'm not aware of any. The only similar thing I'm aware of is a few > incredibly broken packages that require Xvfb at build time. > > If there are packages that need to run any X server at build time, > they're even more broken. Agreed. > | Firstly, as I said in my other replies, this would change the current > | meaning of the X USE flag. The original meaning would stay without a flag. > | Today it means 'enable support for clienside X11'. You want to make it > | mean 'install X11 server'. If I'm building a headless box without an X11 > | server, but I do want to emerge KDE and run it over ssh -Y from another > | box, I need two useflags to specify this. But even if we introduce a new > | USE flag 'Xserver', on by default where X is on by default, and used as > | you describe above, the problems I describe below will remain. > Does it really mean that? How about all of the X USE flags in font > ebuilds? They mean basically what I'm saying. Until today we've only had a single xorg-x11 ebuild. So all the ebuilds today have DEPEND="X? (virtual/x11 )", which includes an X server. But they only really need the clientside libs+headers and so (I argued) what they /really/ mean is 'enable support for clientside X', because the presence of the server doesn't affect them in any way. But forget about what the flag is supposed to mean today. How can my scenario above be resolved without using two useflags? > | Secondly, there can be more than one X11 server (kdrive, etc). > | Depending on xorg-server is bad. If anything, we should introduce a > | virtual/x11-server. I'm just explicitly noting that you didn't comment on this. > | Thirdly, it's a 'convenience dep': whether xorg-server is installed or > | not won't affect the behavior of KDE in any way (given a working DISPLAY > | setting). > > Right, the intent is to basically say "I'm part of the 90% of users who > has X installed locally and wants things to just work." They will just work if they just 'emerge xorg-server'. Just as they need to manually 'emerge KDE' and probably 'emerge openoffice' and mplayer and mozilla and lots of other things. They have to do all this when installing a new system anyway, so my opinion is that adding an extra manual emerge instruction to the handbook isn't any more bother to them and makes things a lot easier for us. Gentoo has a tradition of minimalism in the system package list and so on. It's against the usual and correct Gentoo behavior, IMHO, to install (big!) stuff by default just because 90% of the users want it. A desktop sub-profile or meta-ebuild would be a better tool for this. > |>We will still install some fonts, but not all, and I'll note that in the > |>metabuilds text. > | > | Which ones? Selected how? I'm asking because I don't want to work too > | hard on deciding which fonts KDE should depend on :-) > > Selected arbitrarily by the x11 team based on requirement, common use > and prettiness factor. Probably font-misc-misc, font-bh-ttf, > font-adobe-utopia-type1 and maybe some others that are brought to my > attention. Which other new font ebuilds were included in the monolithic xorg-x11 ebuild? media-fonts/font-*? -- Dan Armak Gentoo Linux developer (KDE) Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 pgpEsH9UUQYhR.pgp Description: PGP signature
Re: [gentoo-dev] modular X - 7.0 RC1
On Thursday 20 October 2005 21:48, Kevin F. Quinn wrote: > On 20/10/2005 21:16:47, Dan Armak ([EMAIL PROTECTED]) wrote: > > On Thursday 20 October 2005 20:58, Matthijs van der Vleuten wrote: > > > On 10/20/05, Dan Armak <[EMAIL PROTECTED]> wrote: > > > > To solve this issue it would have to be an on-by-default flag, i.e. > > > > 'noxserver'. I know some people are strongly against nofoo flags. > > > > > > What about an off-by-default 'xserver' flag? > > > > It wouldn't solve the problem at hand. > > > > Without any flag at all, the user needs to 'emerge xorg-x11' manually to > > get eg KDE to run locally. With an off-by-default flag, he needs to set > > it on manually, _before_ installing KDE, to get an xorg-x11 server. As > > long as he needs to do something manually, explicitly, it should just be > > an 'emerge xorg-x11', which after all is a very simple operation. > > Maybe I'm being stupid, but I don't understand why a user would need to > emerge xorg-x11 manually when doing 'emerge kde'. Surely somewhere in > kde's dependency graph the X server is called up in RDEPEND? An X server > is clearly a run-time dependency. > > Like, konqueror RDEPENDS on qt which RDEPENDS on xorg-xserver, or whatever. No, KDE (like all X11 apps) only needs the client X11 libs and headers. It can then contact a remote X11 server over the network. Now that the client libs and headers are available in separate ebuilds, there's no reason for KDE to depend on the server ebuild, so it won't. -- Dan Armak Gentoo Linux developer (KDE) Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 pgpraj7ORy1M1.pgp Description: PGP signature
Re: [gentoo-dev] modular X - 7.0 RC1
On Thursday 20 October 2005 23:06, Chris Gianelloni wrote: > > Selected arbitrarily by the x11 team based on requirement, common use > > and prettiness factor. Probably font-misc-misc, font-bh-ttf, > > font-adobe-utopia-type1 and maybe some others that are brought to my > > attention. > > Nnn! No Type1 bloat! :P To preserve existing behavior we can use the type1 USE flag. The monolithic xorg-x11 ebuild does that. The same can be done with truetype fonts. -- Dan Armak Gentoo Linux developer (KDE) Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 pgphj0o2pbrMB.pgp Description: PGP signature
Re: [gentoo-dev] ${PORTDIR}/profiles/package.use
On Thursday 20 October 2005 23:47, Petteri Räty wrote: > Every once in a while I see people wanting to use nosomething use flags. > Why don't we have a package.use like we already have a package.mask > file? This would make it possible for developers to turn on use flags by > default in a way that would not cruft the base profiles for every local > use flag. Because implementing https://bugs.gentoo.org/show_bug.cgi?id=61732 would be a lot more cool :-) Besides, if the effect on portage's behavior is the same, what's the difference? -- Dan Armak Gentoo Linux developer (KDE) Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 pgpTs5nYvcPsY.pgp Description: PGP signature
Re: [gentoo-dev] xorg-x11-7 emerge blocks
Don't post such questions here. Go to the gentoo-user mailing list, the forums, or irc. This list is for discussion of Gentoo development. -- Dan Armak Gentoo Linux developer (KDE) Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 pgpEFSPN6DOwL.pgp Description: PGP signature
Re: [gentoo-dev] xorg-x11-7 emerge blocks
On Monday 24 October 2005 19:24, Ferris McCormick wrote: > On Mon, 2005-10-24 at 18:48 +0200, Dan Armak wrote: > > Don't post such questions here. Go to the gentoo-user mailing list, the > > forums, or irc. This list is for discussion of Gentoo development. > > Actually, this is a discussion of X-modular, and up to now, all > X-modular posts have come here (it is very much a -dev issue; the > X-modular suite is masked, unless something has changed quite recently.) It was a matter of misunderstanding emerge output (block by http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 pgpsQA9OHH31h.pgp Description: PGP signature
Re: [gentoo-dev] xorg-x11-7 emerge blocks
On Tuesday 25 October 2005 01:45, Ferris McCormick wrote: > Well, maybe so. However that missing '<' is kind of important Indeed - and it has nothing to do with modular X. There are other ! , and when > playing with X-modular, the portage output really looks like the modular > packages are blocking the non-existent xorg-x11-7. It's not a "matter of > using portage correctly" because portage is misreporting the (phantom) > problem. > > As I recall, it looks like this (for example): > x11-base/xorg-server-xxx [B x11-base/xorg-x11-7] > which without that little '<' is, shall we say, wrong. Example output from the OP: [blocks B ] Since (so far as I > know) it arises only in the X-modular context, this is the right place for > the question. (With '<' it's true but irrelevant, but portage is being > misled into believing xorg-x11 is required. R. Hill addressed that issue > in another post.) > > Or maybe it arises elsewhere too? # find /usr/portage -name '*.ebuild' | xargs grep -He '!\w*<' gives lots of results. xorg-x11-7 is probably the only case where the max version being blocked (7) doesn't exist. But that doesn't stop one from understanding the < blocking dep. -- Dan Armak Gentoo Linux developer (KDE) Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 pgpddJLITyViD.pgp Description: PGP signature
