[gentoo-dev] Leaving Gentoo

2006-06-01 Thread Dan Armak
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


Re: [gentoo-dev] Gentoo: State of the Union

2006-04-29 Thread Dan Armak
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

2006-04-29 Thread Dan Armak
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

2006-04-29 Thread Dan Armak
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


Re: [gentoo-dev] Session/.desktop WM compatibility, DM unification

2006-03-29 Thread Dan Armak
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] Session/.desktop WM compatibility, DM unification

2006-03-27 Thread Dan Armak
On Monday 27 March 2006 16:55, foser wrote:
 On Mon, 2006-03-27 at 00:03 +0200, Dan Armak wrote:
 snip

  = 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?

2006-03-27 Thread Dan Armak
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


[gentoo-dev] Session/.desktop WM compatibility, DM unification

2006-03-26 Thread Dan Armak
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] Gratuitous useflaggery (doc and examples)

2006-03-04 Thread Dan Armak
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)

2006-03-04 Thread Dan Armak
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


Re: [gentoo-dev] Repoman and his automagic

2006-01-30 Thread Dan Armak
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] package.mask cleanups

2006-01-24 Thread Dan Armak
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] xorg-x11-7 emerge blocks

2005-10-24 Thread Dan Armak
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

2005-10-24 Thread Dan Armak
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 xorg-x11-7, and 
the OP apparently missed the ). Thus nothing to do with the modular X. It 
was also crossposted to gentoo-user. IMHO mostly any question about using 
portage correctly, which is suitable to gentoo-user, is not suitable to 
gentoo-dev.

Maybe I was too harsh in the tone of my reply. If so I apologize.

-- 
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


pgpsQA9OHH31h.pgp
Description: PGP signature


Re: [gentoo-dev] modular X - 7.0 RC1

2005-10-20 Thread Dan Armak
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

2005-10-20 Thread Dan Armak
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

2005-10-20 Thread Dan Armak
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

2005-10-20 Thread Dan Armak
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

2005-10-20 Thread Dan Armak
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

2005-10-20 Thread Dan Armak
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

2005-10-20 Thread Dan Armak
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

2005-10-20 Thread Dan Armak
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

2005-10-20 Thread Dan Armak
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

2005-10-20 Thread Dan Armak
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] Proposed change to base.eclass: patch || die

2005-08-06 Thread Dan Armak
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


[gentoo-dev] Proposed change to base.eclass: patch || die

2005-07-29 Thread Dan Armak
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] Re: RFC: qt.eclass

2005-07-02 Thread Dan Armak
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?

2005-07-02 Thread Dan Armak
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-develm=111934060916267w=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] Re: RFC: qt.eclass

2005-07-01 Thread Dan Armak
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

2005-07-01 Thread Dan Armak
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=x11-libs/qt-4.0 !x11-libs/qt-3.2.1
This depends on the fact that we don't actually have different-slotted 
versions of QT 3.2.1 in portage. If we still had eg qt 2.x, this would block 
it. So it's a temporary hack that'll only work for QT based on the fact that 
all qt 3.x versions have the same slot.

-- 
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


pgpbLY3fAf31a.pgp
Description: PGP signature


Re: [gentoo-dev] RFC: qt.eclass

2005-07-01 Thread Dan Armak
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

2005-07-01 Thread Dan Armak
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

2005-07-01 Thread Dan Armak
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

2005-07-01 Thread Dan Armak
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

2005-07-01 Thread Dan Armak
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] Re: RFC: qt.eclass

2005-06-30 Thread Dan Armak
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

2005-06-30 Thread Dan Armak
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

2005-06-30 Thread Dan Armak
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


[gentoo-dev] test, please ignore

2005-05-25 Thread Dan Armak
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

2005-05-25 Thread Dan Armak
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