From Fedora Project Wiki
(09:02:18 AM) scop: hello
(09:02:22 AM) lutter: hey
(09:02:26 AM) racor: hi
(09:03:08 AM) rdieter: meeting? spot?
(09:04:37 AM) rdieter: who's here?
(09:05:50 AM) rdieter: Bueller?
(09:06:26 AM) scop: pong, sort of
(09:06:27 AM) ecik [n=ecik] entered the room.
(09:07:36 AM) rdieter: Sounds like we won't much done today.
(09:07:47 AM) rdieter: s/much/get much/
(09:09:13 AM) tibbs: Sorry, arranging my flight to fudcon.
(09:09:22 AM) tibbs: All done now.
(09:09:40 AM) scop: just a note, I went ahead and wrote up provides/obsoletes, and only after doing so, noticed that it was in "ratify" status in the todo
(09:09:51 AM) rdieter left the room (quit: Remote closed the connection).
(09:10:02 AM) scop: I thought it was supposed to be writeup material already for a while...
(09:10:29 AM) tibbs: I don't recall when it was presented to the other committees.
(09:11:02 AM) rdieter1 [n=rdieter1] entered the room.
(09:11:05 AM) scop: it was, and there was a discussion about when to remove "deprecated" provides later FCX+1 or FCX+2 or something
(09:11:12 AM) scop: ...on fedora-maintainers, IIRC
(09:11:31 AM) ***rdieter1 grumbles a bit more about his flaky home network
(09:11:41 AM) rdieter1 is now known as rdieter
(09:11:57 AM) tibbs: The policy is that if other committees have adequate time to object and don't, then the proposal moves from ratify to writeup.
(09:12:21 AM) tibbs: As long as it was formally presented and no objections were raised, we're good to go.
(09:12:31 AM) scop: I think it's kosher
(09:12:33 AM) tibbs: I just don't remember when that happened.
(09:13:16 AM) rdieter: anyone with topics to discuss?
(09:13:59 AM) scop: maybe a few words about language subpackage naming?
(09:14:19 AM) tibbs: I don't remember that being brought up before.
(09:14:33 AM) tibbs: Is there a pending discussion that I missed?
(09:14:49 AM) rdieter: scop: what did you have in mind?
(09:14:55 AM) scop: no, that was just out of the blue, doesn't have to be discussed right now
(09:15:06 AM) scop: the guidelines are IMO pretty clear that perl-foo, python-foo etc should be used, but there are some foo-perl, foo-python packages in the repo and new ones are being introduced
(09:15:23 AM) rdieter: Most folks seem to be using <pkg>-langpack-<lang>
(09:15:35 AM) tibbs: So which kind of language are we discussing?
(09:15:39 AM) tibbs: Human or programming?
(09:15:54 AM) rdieter: foo-perl/foo-python stuff likely simply needs to be fixed, unless there's (very) good reason to do otherwise.
(09:16:17 AM) rdieter: (sorry, I misunderstood, I think scop is talking about programming)
(09:16:23 AM) scop: mostly yes
(09:16:38 AM) racor: depends, foo-perl is something different than perl-foo
(09:16:56 AM) scop: one recent example: https://bugzilla.redhat.com/223618#c4
(09:17:04 AM) racor: foo-perl can be a perl-frontend to foo,
(09:17:22 AM) racor: while perl-foo would be the "foo" perl dist/module
(09:17:47 AM) scop: I disagree with "dist/module" having anything to do with it
(09:18:00 AM) Rathann|work left the room (quit: Read error: 113 (No route to host)).
(09:18:22 AM) rdieter: In this case perl-*, python-* is a no-brainer, these seem to be language bindings.
(09:19:04 AM) tibbs: I've always resolved this kind of thing in favor of not using %package -n.
(09:19:25 AM) scop: they are also "perl-frontend to foo", so I guess racor would see it differently?
(09:19:42 AM) racor: scop: Would you agree to perl-module being installed to /usr/lib/perl5?
(09:19:44 AM) tibbs: So if you're building a tarball that spits out language-specific subpackages, use %package perl, not %package -n %{name}-perl
(09:19:55 AM) scop: racor, I don't understand the question
(09:20:15 AM) rdieter: tibbs: isn't that eseentially the same thing?
(09:20:22 AM) racor: app-specific perl-modules may well live outside of /usr/lib/perl*
(09:20:26 AM) scop: rdieter, no, it's exactly the opposite
(09:20:30 AM) lutter: tibbs: I'd much rather all language bindings are prefixed; (perl-foo)
(09:20:32 AM) tibbs: Sorry, the latter should be %package -n perl-%{name}
(09:20:39 AM) lutter: makes it much easier to guess the name of the lang bindings for foo
(09:20:40 AM) rdieter: tibbs: better. (:
(09:20:49 AM) lutter: tibbs: phew
(09:20:50 AM) scop: ah, fooled me too ;)
(09:21:24 AM) tibbs: In other words, I'm disagreeing with lutter here.
(09:21:38 AM) rdieter: my take on the current guidlines are clear: use %package -n perl-%{name}
(09:21:48 AM) scop: rdieter++
(09:22:11 AM) lutter: tibbs: no you're not ;) .. we all want lang bindings to be called perl-foo, python-foo etc.
(09:22:13 AM) rdieter: now whether there is agreement whether this is a "good thing", well...
(09:22:13 AM) ***abadger1999 is here now
(09:22:18 AM) tibbs: I don't.
(09:22:27 AM) scop: anyway, seems that we do need to discuss this sometime and clarify guidelines as there are differing opinions and interpretations
(09:23:08 AM) abadger1999: lutter: tibbs has a "not" in his sentence.
(09:23:10 AM) rdieter: I'd say take further discussion to a wider audience (on the list)
(09:23:20 AM) lutter: abadger1999: yeah, just noticed that .. bummer
(09:23:48 AM) scop: FWIW, spot let obexftp-perl pass in the review, dunno if that can be taken as a statement of opinion
(09:24:01 AM) rdieter: doh.
(09:24:33 AM) abadger1999: scop: He didn't argue with you though. Could be he hadn't thought about it before.
(09:24:47 AM) scop: right, could be
(09:26:29 AM) rdieter: anyone willing to discuss: http://fedoraproject.org/wiki/PackagingDrafts/DesktopFiles ?
(09:27:24 AM) scop: OT, was there a meeting last week, BTW? had hardware problems (and still do) and couldn't participate
(09:27:34 AM) Rathann|work [n=rathann] entered the room.
(09:27:36 AM) rdieter: yep.
(09:28:28 AM) rdieter: (though I don't see any irc logs posted for it, not sure who suckered, err, volunteered to do that)
(09:28:57 AM) lutter: rdieter: looks reasonable to me ... I would replace a few of the 'need' with either should or must
(09:29:59 AM) scop: if I read it correctly, the new proposal sort of drops the requirement to add menu entries for GUI apps
(09:30:15 AM) rdieter: huh? (hope not), what makes you say that?
(09:30:18 AM) scop: it leaves it up to the packager
(09:30:36 AM) scop: old: "If a package contains a GUI application, then it needs to also include a properly installed .desktop file."
(09:30:48 AM) scop: new: "If a package contains an application you wish to appear in the Desktop menu, then it needs to also include a properly installed .desktop file."
(09:31:21 AM) rdieter: Fact is (imo, of course), if a packager doesn't want it in the menus, they shouldn't *have* to do it.
(09:31:37 AM) rdieter: I don't care if folks here insist on keeping the original intent, tho
(09:32:10 AM) rdieter: the big thing is simply adding the SHOUD/MUST for compliance with the desktop-entry-spec
(09:32:23 AM) tibbs: For example, do our wine packages install a menu entry for regedit or notepad?
(09:32:27 AM) scop: I think the original intent is fine
(09:32:33 AM) scop: tibbs, I think they do
(09:32:38 AM) tibbs: They're graphical apps, but I doubt they should clutter the menus.
(09:32:52 AM) abadger1999: What are the ramifications of f.d.o compliance?
(09:32:56 AM) abadger1999: tibbs: Yes, they do.
(09:33:11 AM) scop: IIRC wine solves the clutter by adding a separate menu "folder"
(09:33:13 AM) abadger1999: applications::wine::regedit
(09:33:16 AM) rdieter: abadger1999: one result would be non-stupid .desktop files. (:
(09:33:52 AM) abadger1999: I'm just wanting to know if it's going to spark controversy that we'll need to be able to justify.
(09:34:06 AM) rdieter: stupid examples: apps abusing Name vs. GenericName entries.
(09:34:34 AM) tibbs: rdieter: You're going to get a lot of resistance from the gnome people over that.
(09:34:43 AM) abadger1999: So... I take that as a yes ;-)
(09:34:47 AM) scop: isn't name vs genericname a result of some GNOME HIG or something?
(09:35:05 AM) scop: s/name vs genericname/name vs genericname "abuse"/
(09:35:05 AM) rdieter: I know, but they brought it on themselves by using an implementation counter to the desktop-spec.
(09:35:36 AM) tibbs: Perhaps, but we've already established that we're not allowed to require compliance with freedesktop.org standards and specs.
(09:35:50 AM) abadger1999: Err.. When it's for no benefit.
(09:36:04 AM) abadger1999: rdieter, does name/generic name abuse cause problems for kde?
(09:36:34 AM) scop: if spec compliant entries look like crap or confusing in gnome, then I'm afraid we just can't require it
(09:36:45 AM) rdieter: IMO, it causes problems for all desktops. If a user wants to run evolution, gaim, it's nowhere to be found in the menus (as-is)
(09:37:11 AM) f13: rdieter: not every thing, but things concerning the desktop packages should really get somebody from the desktop team to look over them, since it directly effects their packaging.
(09:37:14 AM) rdieter: scop: that's why I'm willing to settle for even a SHOULD guideline.
(09:37:43 AM) lutter: rdieter: have you talked to any of the gnome guys about it ?
(09:38:04 AM) abadger1999: rdieter: What I'm driving towards, is if kde can't work right with the abusing .desktop files then we have a case for enforcing spec compliance.
(09:38:08 AM) rdieter: lutter: not directly, f13 was going to run it by the desktop folks.
(09:38:16 AM) abadger1999: If kde looks fine then it's a change for no apparent benefit.
(09:38:25 AM) abadger1999: s/apparent/visible/
(09:38:30 AM) rdieter: abadger1999: it benefits kde.
(09:39:05 AM) lutter: rdieter: I would prefer if you (or f13) can get the gnome folks to agree
(09:39:32 AM) tibbs: They're violating the spec on purpose; there's little chance that they would agree.
(09:39:37 AM) rdieter: lutter: of course, but don't get your hopes up, since it requires them to actually *change* something.
(09:39:48 AM) rdieter: tibbs: ++
(09:40:36 AM) rdieter: And that sucks, I thought we're here to work toward getting things right, even if it is painful for some in the short-term.
(09:40:47 AM) abadger1999: rdieter: Then maybe we should look into something similar to java naming: .desktop files must comply with f.d.o specs. Since GNOME (a large and important part of our distro doesn't handle f.d.o correctly), we will allow gnome apps to use this format for generic name/name until we can patch the following programs: gnome-panel, (other menu creating apps in gnome)
(09:41:31 AM) rdieter: abadger1999: it's not just gnome, it's apps that the desktop team have use for "default" apps that are currently problematic.
(09:42:02 AM) abadger1999: i'm tempted to say those should be fied to comply with the standard.
(09:42:07 AM) abadger1999: s/fied/fixed/
(09:42:17 AM) rdieter: well, that's a big, duh! (:
(09:42:39 AM) rdieter: but that's just my lowly opinion. (:
(09:42:58 AM) abadger1999: Exempt gnome apps only.
(09:43:12 AM) scop: hm
(09:43:46 AM) scop: many KDE apps are visible in GNOME menus, too
(09:44:31 AM) rdieter: abadger1999: I'm more inclined to call this a SHOULD, instead of including any explicit exemptions.
(09:45:21 AM) abadger1999: When you come down to it, though, a SHOULD doesn't require anything.
(09:45:37 AM) rdieter: abadger1999: it's better than nothing.
(09:45:45 AM) abadger1999: You can mention it in the review but the packager can just ignore it.
(09:46:28 AM) scop: I tend to think that SHOULDs are things that can be skipped, but an explanation is required
(09:46:43 AM) abadger1999: A MUST with eemption should have a condition that states what functionality needs to be included for the exemption to go away.
(09:46:45 AM) scop: ie. not just ignored
(09:46:53 AM) rdieter: Would I prefer this be a MUST item? Absolutely. I just seriously doubt it would get the votes and/or not be vetoed.
(09:47:31 AM) abadger1999: I think the Packaging Committee has to agree whether it's good. But if so I think if it got vetoed we should take it to the Board.
(09:47:59 AM) tibbs: Well, first we should at least consult the gnome folks and get them to officially refuse to comply with the spec (and get their reasons for doing so).
(09:48:16 AM) rdieter: tibbs: fair enough.
(09:48:22 AM) scop: bear in mind that this is a thing that mostly affects the area of the desktop people, not packaging per se
(09:48:44 AM) tibbs: Perhaps they understand that it's not the best thing but have too much to fix all at once; you never know.
(09:48:58 AM) abadger1999: scop: But the "desktop people" we talk about within Red Hat are GNOME devs.
(09:49:14 AM) scop: abadger1999, yes, I'm aware of that :/
(09:49:39 AM) abadger1999: If desktop people is expanded to include community kde packagers we would have a different perspective.
(09:50:33 AM) tibbs: It's already been established that for Fedora, desktop == gnome.
(09:50:43 AM) abadger1999: tibbs: I disagree.
(09:50:49 AM) scop: abadger1999, but that wouldn't change the balance between if this is a thing that should be handled by desktop or packaging folks, no?
(09:50:50 AM) racor: tibbs: --
(09:50:52 AM) tibbs: Well, the mails were pretty clear.
(09:51:11 AM) racor: tibbs: RH != community
(09:51:33 AM) rdieter: racor: Fedora != RH either. (:
(09:51:36 AM) abadger1999: firefox != epiphany?
(09:51:38 AM) abadger1999: :-)
(09:51:55 AM) tibbs: racor: that's what I was saying as well, but reality intrudes.
(09:51:55 AM) scop: Kedora anyone? =)
(09:52:47 AM) rdieter: I think we've ran this one into the ground (for now), any other (votable) topics today?
(09:53:06 AM) racor: I have an item nagging me, but I am not sure if it's our business:
(09:53:16 AM) rdieter: (in the meantime, I'll ping fedora-packaging + fedora-maintainers for more feedback on .desktop files)
(09:53:19 AM) racor: packages accessing remote systems unattendedly and/or w/o opt-in
(09:53:20 AM) abadger1999: rdieter: Could we vote on the non-controversial changes?
(09:53:29 AM) abadger1999: (Or do we not have quorum?)
(09:53:54 AM) rdieter: abadger1999: I'm ok with a vote, if wew have the folks.
(09:54:13 AM) lutter: abadger1999: I really think the gnome guys should make some sort of statement about the proposal
(09:54:21 AM) ***spot is here now
(09:54:28 AM) ***spot snuck out of this mindless meeting
(09:54:32 AM) abadger1999: I count eight.
(09:55:07 AM) rdieter: abadger1999: which do you consider non-controversial?
(09:55:53 AM) tibbs: The part about desktop-file-install not being mandatory seems good to me.
(09:55:57 AM) abadger1999: Everything except f.d.o with the change that scop mntioned.
(09:56:00 AM) tibbs: More examples are always good.
(09:56:13 AM) rdieter: ok.
(09:56:20 AM) spot: umm, since i'm jumping in late, where is the draft?
(09:56:29 AM) abadger1999: http://fedoraproject.org/wiki/PackagingDrafts/DesktopFiles
(09:56:36 AM) spot: thx
(09:57:18 AM) rdieter: racor: I think your gripe is valid, and that should be pretty much a no-no.
(09:58:03 AM) rdieter: racor: heck, that's just common sense, not sure if it's worth explicitly mentioning in packaging guidelines.
(09:58:26 AM) spot: umm, why wouldn't we want d-f-i to be mandatory?
(09:58:38 AM) abadger1999: Because it's not necessary.
(09:58:55 AM) abadger1999: Many packages install the desktop file just fine.
(09:58:59 AM) ***rdieter doesn't care strongly either way, if the consensus is to keep in mandatory, so be it.
(09:59:06 AM) tibbs: You do lose the lint-like quality, though.
(09:59:26 AM) scop: "use d-f-i, or explicitly run d-f-validate during build"?
(09:59:31 AM) rdieter: tibbs: some of dfi's lint-like warnings/errors are wrong. (:
(09:59:42 AM) tibbs: For example, lots of packages are now warning about Applications, aren't they?
(09:59:54 AM) tibbs: rdieter: Those should then be bugs that need fixing.
(09:59:56 AM) spot: I think it is far easier to keep d-f-i as mandatory and ensure the correct desktop files get put in place than to try to build an ecosystem to check this
(09:59:56 AM) rdieter: scop: ++ , I think I like that.
(09:59:57 AM) scop: Applications is not a registered category in the spec
(10:00:28 AM) racor: rdieter: I think we can't avoid to: Think along "smolt" (Fedora spyware) and .... (gulp) firefox
(10:00:39 AM) rdieter: ok, I'm sold, MUST: use either d-f-i or d-f-validate on gui .desktop files.
(10:00:57 AM) scop: rdieter, also on ones installed in eg. KDE private locations?
(10:01:06 AM) spot: i still think that since we have no way to be sure that d-f-validate is being run
(10:01:07 AM) scop: I suppose some of those won't validate
(10:01:34 AM) tibbs: Perhaps rpmlint could run the validator on any desktop files in the installed package?
(10:01:36 AM) rdieter: scop: mostly because the validator's errors are simply wrong, but that's fixable.
(10:01:45 AM) tibbs: Or does anyone but me run rpmlint on the installed packages?
(10:01:46 AM) scop: tibbs, it already does
(10:01:53 AM) spot: tibbs: that works at review, but what about after review?
(10:02:08 AM) spot: requiring d-f-i ensures that we're getting the latest desktop file, always, forever and ever amen
(10:02:13 AM) tibbs: Nothing stops us from running rpmlint over the entire distro if we wanted.
(10:02:17 AM) tibbs: We just don't have the infrastructure.
(10:02:24 AM) scop: make rpmbuild run d-f-v in post-%install checks?
(10:02:45 AM) spot: we're trying to hack and abuse the ecosystem to get around a trivial action
(10:02:52 AM) scop: btw, http://lintian.debian.org/ for Fedora would be very nice
(10:02:53 AM) spot: d-f-i will never give us what we don't want
(10:03:12 AM) spot: it will sometimes be irrelevant, but it will always leave us safe.
(10:03:33 AM) rdieter: spot: so your suggestion is simply to keep d-f-i usage mandatory, and call it good?
(10:03:37 AM) spot: i honestly would rather see changes to d-f-i
(10:03:53 AM) spot: such that it checks for an existing desktop file and exits if it is identical
(10:04:12 AM) abadger1999: spot: k. That would be fine with me.
(10:04:22 AM) ***scop doesn't follow... rephrase?
(10:04:58 AM) scop: checks for an existing desktop file where?
(10:05:05 AM) scop: exits if what is identical?
(10:05:05 AM) spot: Why are we trying to make d-f-i not mandatory?
(10:05:50 AM) spot: We're using d-f-i to install the desktop file into the proper location and validate that it is functional.
(10:06:24 AM) rdieter: spot: no good reason, I'll update the proposal to not change d-f-i's mandatory'ness.
(10:06:39 AM) rdieter: sorry folks gotta run to take a little one to pre-school.
(10:07:02 AM) tibbs: d-f-t can be extra busy work if the package is already installing its desktop files properly.
(10:07:18 AM) tibbs: You have to remove them and then use d-f-i to put them back, even if nothing is changing.
(10:07:30 AM) rdieter: tibbs, true, but I think I appreciate spot's point of validation.
(10:07:38 AM) tibbs: So I can understand why some might want to get rid of that step.
(10:07:51 AM) rdieter: tibbs: afaik, no, you don't have to remove anything. You can use d-f-i on a .desktop file *in-place*
(10:08:05 AM) tibbs: Ah, OK. I thought there was a time when this didn't work.
(10:08:21 AM) rdieter: (maybe there was, but not now... (:)
(10:08:27 AM) tibbs: Will d-f-i fail the build if the file is bad enough?
(10:08:28 AM) spot: it certainly works now. :)
(10:08:33 AM) rdieter: tibbs: yes.
(10:08:37 AM) spot: tibbs: yep.
(10:08:53 AM) tibbs: Then it seems to be a useful step.
(10:09:30 AM) scop: its judgement of bad enough could use some tweaking though, but that's an implementation detail
(10:09:49 AM) rdieter is now known as rdieter_away
(10:10:05 AM) spot: scop: indeed, but thats tuning d-f-i, not making it less required. :)
(10:10:37 AM) scop: right
(10:11:00 AM) scop: I can live with d-f-i being mandatory
(10:12:18 AM) scop: spot, any comments wrt cases like obexftp-{perl,python} vs {perl,python}-obexftp in https://bugzilla.redhat.com/223618
(10:12:49 AM) scop: we discussed it a bit and there seem to be differing opinions/interpretations of the naming guidelins
(10:14:16 AM) spot: there is a fair amount of precedent for non-CPAN packages to use -perl
(10:14:25 AM) spot: and for CPAN packages to use perl-*
(10:14:32 AM) scop: don't get stuck with CPAN
(10:14:42 AM) spot: uuid-perl-0:1.5.1-2.fc6.i386
(10:14:42 AM) spot: libpreludedb-perl-0:0.9.11.1-2.fc7.i386
(10:14:42 AM) spot: graphviz-perl-0:2.12-2.fc7.i386
(10:14:42 AM) spot: perl-perlmenu-0:4.0-4.fc6.noarch
(10:14:43 AM) spot: netcdf-perl-0:1.2.3-2.fc7.i386
(10:14:43 AM) spot: pcsc-perl-0:1.4.4-3.fc7.i386
(10:14:45 AM) spot: tetex-perltex-0:1.3-1.fc6.noarch
(10:14:49 AM) spot: openbabel-perl-0:2.1.0-0.1.b4.fc7.i386
(10:14:51 AM) spot: claws-mail-plugins-perl-0:2.7.1-1.fc7.i386
(10:14:53 AM) spot: GraphicsMagick-perl-0:1.1.7-6.fc7.i386
(10:14:55 AM) spot: libprelude-perl-0:0.9.12.1-1.fc7.i386
(10:14:57 AM) spot: cyrus-imapd-perl-0:2.3.7-6.fc7.i386
(10:14:59 AM) spot: epylog-perl-0:1.0.3-5.fc7.noarch
(10:15:01 AM) spot: rrdtool-perl-0:1.2.15-9.fc7.i386
(10:15:03 AM) spot: nagios-plugins-perl-0:1.4.5-1.fc7.i386
(10:15:05 AM) spot: (sorry for the flood)
(10:15:07 AM) spot: (and ignore the tetex-perltex false positive)
(10:15:32 AM) scop: (and perl-perlmenu :))
(10:15:42 AM) spot: I think perhaps having the perl Provide is more important in these cases
(10:15:49 AM) spot: perl(obexftp)
(10:16:00 AM) tibbs: To me it's all about whether it's a subpackage of something like cyrus-imapd or mysql or somesuch.
(10:16:14 AM) tibbs: But then I suppose that doesn't have a lot of relevance except to packagers.
(10:16:31 AM) scop: what about ruby, python, tcl, java, etc? they don't have the Provide, at least not all of them
(10:17:14 AM) tibbs: That would be a deficiency in those packaging guidelines, wouldn't it?
(10:17:22 AM) spot: well, we can either mandate the namespace, or mandate the Provide
(10:17:36 AM) spot: which do you guys think will be less controversial? :)
(10:17:45 AM) scop: the Provide is useless unless something is made to use it
(10:17:57 AM) scop: with perl it's automatic, with many others it's nonexistent
(10:18:00 AM) abadger1999: Both cntroversial but namespace less so.
(10:18:24 AM) spot: the namespace leaves us with less load on yum as well
(10:18:34 AM) spot: anywhere we can eliminate extra Provides speeds up yum
(10:19:08 AM) spot: In the specific case of perl, perl packages use the perl() provides almost universally
(10:19:15 AM) scop: hey, by the way, now I remember a thing I have been meaning to bring up many times before but always forgotten
(10:19:16 AM) spot: because the provides are autogenerated
(10:19:38 AM) scop: does anyone see any downsides if rpmbuild would prune self-requires from all packages?
(10:19:42 AM) scop: (at build time, that is)
(10:19:59 AM) tibbs: What do you define as self-requires?
(10:20:22 AM) Rathann|work: tibbs: a case where Requires: == Provides:
(10:20:29 AM) scop: $ rpm -qR perl-URI | grep -F 'perl(URI'
(10:20:40 AM) Rathann|work: ah
(10:20:46 AM) Rathann|work: my bad then
(10:20:47 AM) racor: scop: No, I think this would work
(10:21:01 AM) spot: seems reasonable to me.
(10:21:15 AM) scop: the only case I can think of this being even potentially harmful is
(10:21:17 AM) tibbs: You don't lose much.
(10:21:26 AM) scop: if we have a package that requires virtual "foo"
(10:21:39 AM) Rathann|work: so what about my obexftp-perl vs perl-obexftp? (and same for python?)
(10:21:41 AM) scop: and provides "foo" itself, but we have several others providing "foo" too
(10:22:01 AM) scop: a depsolver could present a list of packages providing foo and let the user choose
(10:22:36 AM) spot: scop: yeah, that is a valid problem
(10:22:41 AM) abadger1999: I like perl-obexftp and python-obexftp but my opinion is kinda slushy.
(10:22:50 AM) racor: rathann: If this package install's it's perl module to /usr/lib/perl*, it must be perl-*
(10:23:01 AM) scop: I'm with abadger1999 on that
(10:23:22 AM) Rathann|work: scop, racor: will you file bugreports against packages which don't follow that rule?
(10:23:25 AM) ***lutter nods violently
(10:23:32 AM) racor: scop: I see perl-* tied to /usr/lib/perl*
(10:23:37 AM) spot: i've historically sided with the packager's ability to choose, but I can see the benefit of the universal namespace here
(10:23:38 AM) scop: Rathann|work, possibly, but this requires more discussion
(10:23:52 AM) spot: we also need to revisit whether the "python namespace exception" still applies
(10:23:53 AM) scop: Rathann|work, and it is not my intention to block obexftp on this
(10:24:06 AM) spot: aka: if the package has "py" in its name, it doesn't need the namespace
(10:24:14 AM) lutter: we shold probably grandfather existing packages in if we mandate the namespace (which I am all for)
(10:24:17 AM) Rathann|work: scop: but I want to avoid renaming packages later
(10:24:44 AM) Rathann|work: so I guess I'll go with perl-foo and python-foo
(10:25:05 AM) scop: well, if you want to be extra safe, use Provides
(10:25:13 AM) scop: not sure if it's worth it though
(10:26:36 AM) racor left the room (quit: "Dinner's waiting ....").
(10:28:18 AM) Rathann|work: ok thanks
(10:28:23 AM) ***Rathann|work goes home
(10:28:23 AM) ***scop needs to go too
(10:28:38 AM) ***spot goes back into his meeting of doooom.
(10:31:01 AM) scop left the room (quit: "Leaving").
(10:44:30 AM) ecik: are we going to update BuildRequires section of Packaging Guidelines?
(10:44:41 AM) ecik: it would be nice, if there were written something about mock
(10:54:50 AM) rdieter_away is now known as rdieter
(11:16:32 AM) jorge_ [n=jorge] entered the room.
(11:26:04 AM) rdieter: ecik: What would you suggest? (because it's not entirely clear from your comment)
(11:27:05 AM) ecik: rdieter, BuildRequires section mentions only about rpmdev-rmdevelrpms to find missing BRs
(11:28:46 AM) ecik: if we say about finding buildrequires, mock looks like a better solution to find them
(11:29:59 AM) rdieter: either way works, but I'd have to say using mock is harder (esp for newbies)
(11:31:34 AM) ecik: that's right, but we should show the another good way to check BRs
(11:31:44 AM) ecik: we could paste some text from MockTricks
(11:32:41 AM) rdieter: sounds reasonable, you willing to write it up and propose it to the committee? (:
(11:33:20 AM) ecik: doesn't sound like a big problem thus I can do it :)
(11:34:56 AM) rdieter: good man.
(11:44:11 AM) ecik: I should put it under PackagingDrafts?
(11:50:19 AM) rdieter: yup
(11:50:47 AM) rdieter: then send something to the fedora-packaging ml for review/comment.
(11:51:31 AM) ecik: ok
(12:10:05 PM) f13: rdieter: ping
(12:10:28 PM) rdieter: f13: yo
(12:10:32 PM) f13: rdieter: some feedback from .desktop proposal. Not every gui app should show up in the menu, things like gconf-editor, eog, evince, etc... they are purposfully left out of the menu
(12:10:47 PM) f13: rdieter: I think it would be better worded that any app that should show up in the menu requires a .desktop file.
(12:10:53 PM) rdieter: arg, that's what I said, but other folks here wanted otherwise...
(12:11:04 PM) f13: <@mclasen> it may be good to elaborate on the concept of installing a desktop file without making it visible in the menus
(12:11:07 PM) f13: <@mclasen> for the benefit of menu editing
(12:11:39 PM) f13: <@mclasen> it would also be good to write something down about the ideas behind GenericName vs Name,
(12:11:43 PM) f13: <@mclasen> and the relation to default apps
(12:11:46 PM) f13: <@mclasen> but I am not prepared to do that right now
(12:12:17 PM) rdieter: I think *purposely* leaving something out of the menus may also be a valid exception, which should/would require justification at review-time.
(12:12:50 PM) rdieter: Not sure if it's a case worth mentioning explictly... (I don't care strongly one way or the other).
(12:13:35 PM) rdieter: f13: thanks for the feedback, I'll take those comments to the list to see what others have to say.
(12:15:19 PM) f13: <@jkeating> mclasen: if we took the part out regarding every gui app having a .desktop file, would you be ok with this proposal going through, as an interim step toward something with even more information?
(12:15:23 PM) f13: <@mclasen> doesn't seem to contain anything particularly controversial afaics on quick reading
(12:15:27 PM) f13: <@mclasen> does it mention that .desktop files go in /usr/share/applications, normally
(12:15:30 PM) f13: <@mclasen> what about the ownership of that directory
(12:15:33 PM) f13: <@mclasen> and the resulting Requires
(12:15:35 PM) f13: <@mclasen> does every .desktop-file installing package require gnome-session for that directory ?
(12:15:39 PM) f13: <@mclasen> like we did for .pc files ?
(12:16:23 PM) tibbs: f13: Where is this coming from?
(12:16:31 PM) f13: <@mclasen> might also be worthwhile to mention that Categories are used to place the entries in suitable menus
(12:16:34 PM) f13: tibbs: internal IRC
(12:16:47 PM) f13: tibbs: our desktop guys use internal IRC and #fedora-desktop on gimpnet
(12:16:54 PM) f13: (since thats where most of gnome is)
(12:17:06 PM) f13: trying to manage 3 IRC servers gets to be a bit rediculous
(12:17:27 PM) tibbs: I can imagine.
(12:17:54 PM) rdieter: Hmm, nothing I type seems to be going through (at least I can't see it)
(12:17:59 PM) rdieter: ah, there it is again.
(12:18:24 PM) rdieter: re: /usr/share/appliations should be owned, but gnome-session is inappropriate, imo, maybe filesystem?
(12:18:27 PM) f13: hrm, seems the gnome-session may be a packaging bug
(12:18:39 PM) f13: rdieter: yeah, that was the suggestion I got internal too, make filesystem own it, or a filesystem like package.
(12:18:58 PM) f13: xdg-system perhaps? Are there other xdg type dirs and such that would be usefull to have desktop agnostic?
(12:19:21 PM) rdieter: f13++, add in /etc/xdg
(12:19:57 PM) rdieter: + /usr/share/mime-info
(12:20:00 PM) rdieter: + /usr/share/icons
(12:20:09 PM) f13: <@halfline> filesystem already owns /usr/share/applications
(12:20:19 PM) f13: maybe we should just make filesystem own them all.
(12:20:22 PM) f13: a worthwile RFE
(12:21:00 PM) rdieter: ok.
(12:21:06 PM) rdieter: I'll do it now...
(12:21:11 PM) f13: thanks
(12:21:42 PM) f13: rdieter: stil not sure if they all really GO in filesystem, or if they should go in a higher level package so that they aren't created for nonX systems. But *shrug*, not my call
(12:21:49 PM) f13: the RFE should sort it out
(12:23:12 PM) rdieter: imo, your suggestion of xdg-filesystem (or something like that) seems to make the most sense.
(12:23:19 PM) f13: yeah.
(12:23:26 PM) f13: more packages sucks more but *shrug*
(12:23:49 PM) rdieter: I don't care, as long as it's somewhere. (:
(12:29:15 PM) rdieter: http://bugzilla.redhat.com/224052, filesystem: +xdg-using directores
(12:35:09 PM) rdieter: f13: now I remember, folks wanted to keep d-f-i usage mandatory, to serve as a sort of lint for .desktp files
(12:36:16 PM) rdieter: .desktop files that don't validate need to be fixed.
(12:37:33 PM) f13: sure, thats for packages that have .desktop files. Which is different from making every gui package have a .desktop file.
(12:37:50 PM) f13: if it HAS one, it should be installed (whether or not it shows up in the menu).
(12:38:11 PM) rdieter: f13: .desktop files can have Hidden=true. (:
(12:39:16 PM) f13: yeah, should be pointed out the seperation between installed vs visible
(12:39:50 PM) rdieter: ok.