| === tritium_ is now known as tritium | ||
| === asac_ is now known as asac | ||
| === ubottu changed the topic of #ubuntu-meeting to: Calendar: http://fridge.ubuntu.com/event | Logs: https://wiki.ubuntu.com/MeetingLogs/ | 24 Jul 14:00 UTC: Java Team | 24 Jul 16:00 UTC: Ubuntu Mobile | 25 Jul 20:00 UTC: MOTU | 28 Jul 14:00 UTC: Maintainer scripts | 31 Jul 14:00 UTC: Mentoring Reception | 31 Jul 16:00 UTC: Ubuntu Mobile | ||
| === RoAk is now known as RoAkSoAx | ||
| === davmor2 is now known as davmor2_lunch | ||
| === davmor2_lunch is now known as davmor2 | ||
| * pitti waves | 13:42 | |
| Hobbsee | heya pitti! | 13:43 |
|---|---|---|
| * pitti hugs Hobbsee | 13:44 | |
| Hobbsee | :D | 13:44 |
| seb128 | hey | 13:58 |
| * mvo_ waves | 13:58 | |
| MacSlow | hey seb128, mvo | 13:58 |
| * Keybuk laughs evily | 14:01 | |
| kwwii | hi | 14:01 |
| pitti | Keybuk: *phear* | 14:02 |
| MacSlow | ? | 14:02 |
| Keybuk | MacSlow: how to confuse Ken: ring him and speak german ;) | 14:02 |
| MacSlow | yeah :) | 14:02 |
| MacSlow | I can do that too | 14:02 |
| Keybuk | ok, so let's get going | 14:02 |
| * pitti <- happy; just figured out how to finally get a working PackageKit integration into jockey \o/ | 14:02 | |
| Keybuk | how is everybody? sprint-flu hopefully dying off now? | 14:02 |
| pitti | never had it, fortunately | 14:03 |
| * mvo_ feels a lot better, almost normal | 14:03 | |
| seb128 | me neither | 14:03 |
| * MacSlow still suffers a bit from not enough sleep during Istanbul and London | 14:03 | |
| * seb128 hugs mvo | 14:03 | |
| MacSlow | but the sunny weather currently helps | 14:03 |
| Keybuk | I've put together an agenda for today | 14:03 |
| Keybuk | https://wiki.ubuntu.com/DesktopTeam/Meeting/2008-07-24 | 14:03 |
| Keybuk | did I miss anyone's items? | 14:04 |
| Keybuk | okay, guess not | 14:04 |
| Keybuk | only outstanding action was for mpt, who is busy with LP 2.0 | 14:04 |
| Keybuk | so we'll carry that over | 14:04 |
| Keybuk | mvo: proxy setting location | 14:05 |
| mvo_ | ok - currently the system-service backend sets /etc/apt/apt.conf | 14:05 |
| mvo_ | however I wonder if it should also do something like /etc/environment or /etc/profile | 14:05 |
| mvo_ | what are your opinions on this? | 14:05 |
| Keybuk | did you talk to gustavo about what Landscape will use? | 14:06 |
| mvo_ | I mailed him, but he did told me yet, what location they are going to use | 14:06 |
| mvo_ | we could of couse just standardize on one like /etc/default/proxy | 14:06 |
| Keybuk | pitti: do you have a strong opinion? | 14:07 |
| pitti | I was just checking, I thought /etc/profile was a conffile | 14:07 |
| pitti | but it's not | 14:07 |
| pitti | but /etc/environment sill sounds better to me | 14:07 |
| pitti | mvo_: for proxy, a default file works as well, but then you need to change all our shell and DE session programs to read it | 14:07 |
| pitti | and /etc/environment is already evaluated, no? | 14:08 |
| mvo_ | pitti: indeed, this is why I would prefer the (slightly more dogy) /etc/environmnet approach | 14:08 |
| pitti | we speak about setting $HTTP_PROXY and $HTTPS_PROXY, right? | 14:08 |
| mvo_ | pitti: yes | 14:08 |
| pitti | mvo_: why is it dodgy? | 14:08 |
| * pitti doesn't see anything wrong with it? | 14:08 | |
| seb128 | isn't /etc/default/locale supposed to be used to set the locale? | 14:09 |
| seb128 | I though environment was a pam thing | 14:09 |
| pitti | we have /etc/default/locale nowadays (I never understood why), but /e/e still sets $PATH | 14:09 |
| mvo_ | my understanding is that its not a real shell file but something that pam reads (we had a similar dicussion about gdm iirc). I don't remember the details unfortunately | 14:09 |
| seb128 | pitti: environment is a pam thing and some people refuse to abuse it for other things because it's not meant for that | 14:09 |
| seb128 | ask cjwatson for details | 14:09 |
| pitti | then it shouldn't be called 'environment' | 14:09 |
| Keybuk | cjwatson: care to weigh in? | 14:10 |
| pitti | ok, might be better then, if Colin has a strong opinion | 14:10 |
| mvo_ | I personally think that if it is still there, we can and should use it. if it is not meant to be used, we should get rid of it :) | 14:10 |
| cjwatson | seb128 mischaracterises my opinions slightly | 14:10 |
| pitti | I just don't understand why it's wrong to put environment variables in /etc/environment :) | 14:10 |
| seb128 | pitti: well, he had for the gdm discussion IIRC | 14:10 |
| cjwatson | /etc/environment should not be treated as if it were a shell script | 14:10 |
| pitti | right | 14:10 |
| cjwatson | its quoting rules may differ | 14:10 |
| seb128 | cjwatson: I didn't try to summarize your opinion there but rather what I understood of the discussion and mentioned that we should rather ask you for clarification | 14:11 |
| cjwatson | I don't see anything exceptionally wrong with setting default environment variables there, and using pam_getenv to retrieve them when one is outside a PAM context | 14:11 |
| cjwatson | seb128: ok | 14:11 |
| Keybuk | why did the locale stuff move out of there? | 14:11 |
| mvo_ | excellent, thanks cjwatson - then I will just just that | 14:11 |
| cjwatson | Keybuk: an exceedingly long and tedious argument over gdm | 14:11 |
| seb128 | gdm is using /etc/default/locale nowadays and not the pam_getenv thing for the record | 14:12 |
| Keybuk | ok, sounds like there's a consensus ? | 14:12 |
| pitti | seb128: so GNOME sessions don't use the $PATH set there? | 14:12 |
| Keybuk | pitti: if I were to guess, I'd say that sessions do but gdm itself doesn't | 14:13 |
| cjwatson | the point of /etc/default/locale was to have gdm itself read it | 14:13 |
| pitti | hmkay; well we'll hardly need http proxies in gdm | 14:13 |
| cjwatson | http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=214898 | 14:13 |
| ubottu | Debian bug 214898 in locales "Create /etc/default_locale containing the selected locale" [Wishlist,Closed] | 14:13 |
| seb128 | pitti: the gdm config has its own PATH definition | 14:13 |
| pitti | unless the new gdm has a browser built in, of course :) | 14:13 |
| Keybuk | ok | 14:14 |
| Keybuk | * Integration of guest login (pitti) | 14:14 |
| pitti | assume we'll have a backend service which starts a guest session and cares about the privilege stuff | 14:14 |
| pitti | where would we like to expose this functionality in the UI? | 14:14 |
| pitti | so far my idea is an additional f-u-s-a entry | 14:14 |
| Keybuk | I understood that the spec called for this to be in f-u-s-a | 14:14 |
| pitti | but we should offer it somewhere else, too | 14:14 |
| Keybuk | that's certainly where Mark thinks it should go | 14:15 |
| Keybuk | should we? | 14:15 |
| pitti | right, but people might have removed that | 14:15 |
| pitti | it shuold also be accessible through the "switch user" dialog or screen, IMHO | 14:15 |
| pitti | but the log out dialog, as it is, already has too many buttons | 14:15 |
| Keybuk | we don't have a dialog like that though? switch user goes back to gdm | 14:15 |
| seb128 | it should be in the gdmflexiserver list and in fusa imho | 14:16 |
| mvo_ | the gdm face-browser comes as a natural place in mind | 14:16 |
| pitti | Keybuk: I mean the three-buttoned "log out $user" dialog | 14:16 |
| Keybuk | mvo_: breaks the spec; the requirement is for a logged in user to allow someone else to be a guest | 14:16 |
| pitti | mvo_: yeah, but I doubt that we'll get the new gdm for intrepid | 14:16 |
| seb128 | mvo_: well, the face browser is used for login screen too and we don't want to have the option on login screen | 14:16 |
| Keybuk | not for someone to walk up and log in | 14:16 |
| pitti | right, gdm shouldn't expose it if there's noone logged in | 14:16 |
| mvo_ | aha, ok | 14:17 |
| pitti | I actually tried to integrate this functionality into the old gdm, but that code is a mess | 14:17 |
| pitti | gently poke it, and it starts segfaulting around | 14:17 |
| pitti | (apart from the fact that the structure is very deep and hairy) | 14:17 |
| pitti | we could add a 4th button to the "log out" dialog, but ETOOMANYBUTTONS | 14:18 |
| pitti | (no Ted here?) | 14:18 |
| pitti | Ted offered me to care about the integration into fusa | 14:18 |
| seb128 | pitti: there is no logout dialog at the moment | 14:19 |
| kwwii | since we have been in the new team it has been unclear which meetings we need to go to | 14:19 |
| seb128 | or not a stable one | 14:19 |
| pitti | hm? sure it is | 14:19 |
| seb128 | pitti: expect the current one to go before intrepid | 14:19 |
| seb128 | vuntz wants to merge the opensuse one | 14:19 |
| seb128 | so we will either use the new one | 14:19 |
| pitti | seb128: right; but we'll still have something that appears if you click on "Log out martin", surely? | 14:19 |
| seb128 | or be asked to get the old one back | 14:19 |
| seb128 | pitti: right, just pointing out "don't bother patching the current code, it'll change" | 14:20 |
| pitti | right | 14:20 |
| pitti | I think initially we'll patch fusa | 14:20 |
| pitti | but I'd still like to have it *somewhere* else | 14:20 |
| seb128 | that should not change while we are using old gdm ;-) | 14:20 |
| pitti | well, if you guys are happy with just fusa, fine for me | 14:21 |
| Keybuk | sounds like this is something we have a little while to discuss before it needs to be done | 14:21 |
| Keybuk | f-u-s-a is certainly the one place it should be | 14:21 |
| seb128 | right, agreed | 14:21 |
| seb128 | +having it in the gdmflexiserver list would be nice | 14:21 |
| pitti | at some point the new gdm will natively support guests, and we'll get it | 14:21 |
| pitti | unfortunately they don't respond to me at all | 14:21 |
| Keybuk | ok | 14:21 |
| Keybuk | * Default theme in Intrepid (pitti) | 14:21 |
| pitti | 'they' -> UPSTREAM | 14:21 |
| pitti | ah, yeah | 14:21 |
| seb128 | they moved to other things apparently, ie gnome-session dbus branch | 14:21 |
| kwwii | w00t, pitti is doing the themeing now? | 14:22 |
| pitti | I wondered which theme will be the default for intrepid installs and upgrades? | 14:22 |
| pitti | human or the black one? | 14:22 |
| pitti | kwwii: at least wondering about it, yes :) | 14:22 |
| kwwii | pitti: the black one will get one more update before the weekend and sometime next week I will put a light one back in as default | 14:22 |
| pitti | personally I could live with having the black one by default on fresh installs, but I'd complain heavily if we intend to auto-upgrade to the dark one | 14:22 |
| MacSlow | if you need mockups when thinking about where to put things -> http://people.ubuntu.com/~mmueller/login-experience-mockup.ogg | 14:23 |
| MacSlow | for any proposals | 14:23 |
| kwwii | pitti: right, in any case it should not change what you already have, that would be quite a shock | 14:23 |
| pitti | kwwii: ah, so this is just for getting more wirespread testing? | 14:23 |
| kwwii | to be honest I have been waiting for a little bird to whisper in my ear tellling me to keep the dark on in as default | 14:23 |
| kwwii | pitti: exactly | 14:23 |
| pitti | auto-upgrading a black-on-white theme to essentially the inverse is ergonomically bad in various ways, yeah | 14:23 |
| pitti | that was my primary concern | 14:24 |
| kwwii | no worries then | 14:24 |
| OgMaciel | MacSlow: I must say: WOW! | 14:24 |
| seb128 | MacSlow: looks good ;-) | 14:24 |
| pitti | ok, thanks; I'm happy again :) | 14:24 |
| * pitti hugs kwwii | 14:24 | |
| OgMaciel | don't mind me :) | 14:24 |
| kwwii | there is one issue to discuss, themeing gdm | 14:24 |
| mvo_ | nice work MacSlow | 14:24 |
| kwwii | which gdm are we using, how do we theme it, etc | 14:24 |
| MacSlow | OgMaciel, seb128 to some extend the graphics work already... but most of the integration is still missing | 14:24 |
| pitti | MacSlow: BLING | 14:25 |
| OgMaciel | MacSlow: it is defintely a great mockup | 14:25 |
| Keybuk | ok | 14:25 |
| MacSlow | mvo_, seb128: but you saw part of that already in London... I showed it to you afaik | 14:25 |
| Keybuk | the sponsoring queue | 14:25 |
| Keybuk | http://people.ubuntu.com/~dholbach/sponsoring/ | 14:25 |
| seb128 | MacSlow: yes | 14:25 |
| pitti | kwwii: getting 2.22 into intrepid would be a royal PITA, I'm afraid | 14:25 |
| Keybuk | please check through that and make sure you're not unnecessarily sitting on anything | 14:26 |
| * mvo_ nods | 14:26 | |
| kwwii | pitti: so pretty much the same stuff we have had in the past? | 14:26 |
| pitti | I think that is a difficult problem long-term, actualy | 14:26 |
| pitti | Fedora doesn't seem to give a rat's^W^W^W care about upgrades at all | 14:26 |
| Keybuk | otherwise, is there any other business? | 14:27 |
| Keybuk | pitti: they care a little bit ;) I'm getting whined at because you can't upgrade from upstart 0.3.x to 0.5 cleanly | 14:27 |
| pitti | the gdm issue is a pretty interesting topic indeed | 14:27 |
| seb128 | (I'm on swap day tomorrow, just for notice) | 14:27 |
| kwwii | pitti: and it seems that nobody is interested in it :p | 14:28 |
| pitti | Keybuk: heh; but in the new gdm almost everything is missing that the old one has, xdmcp, auto-login, configuration files, etc.; and no automatic conf upgrade either | 14:28 |
| Keybuk | Fedora really seem to be | 14:28 |
| Keybuk | err | 14:28 |
| Keybuk | how can I put this diplomatically | 14:28 |
| Keybuk | rushing a lot of features into F10 | 14:28 |
| Keybuk | it's like they're trying to prove how awesome contributing upstream is | 14:28 |
| Keybuk | and landing just about everything that anybody's working on | 14:28 |
| pitti | it seems like two full months of upstream work in order to put all the missing bits into the new gdm | 14:28 |
| Keybuk | they reckon they'll have kernel mode setting | 14:29 |
| Keybuk | a replacement rhgb (plymouth) | 14:29 |
| pitti | I don't think any of us has the time for doing that | 14:29 |
| Keybuk | DeviceKit instead of HAL | 14:29 |
| Keybuk | full PK/CK | 14:29 |
| Keybuk | new gdm | 14:29 |
| pitti | F9 already has the new gdm | 14:29 |
| MacSlow | speaking of Xorg -> http://www.phoronix.com/scan.php?page=article&item=oscon_2008_x&num=1 :) | 14:29 |
| pitti | Keybuk: DK -> s/instead of/in addition/? or do they really do the entire transition in one huge step? | 14:29 |
| Keybuk | dunno | 14:29 |
| Keybuk | davidz had a small panic | 14:30 |
| MacSlow | pitti, I wanted to take a llook at plymouth... but not with the currently little time at hand | 14:30 |
| Keybuk | OMG SO MUCH WORK type of thing | 14:30 |
| pitti | $ apt-cache rdepends hal|wc -l | 14:30 |
| pitti | 62 | 14:30 |
| pitti | that was slightly easier in warty :) | 14:30 |
| Keybuk | I can't imagine they can drop HAL | 14:31 |
| pitti | the new user admin tool as well then? | 14:32 |
| pitti | since system-config-user has some really scary mechanism to become root | 14:32 |
| Keybuk | *nods* | 14:33 |
| pitti | anyway, seems we are either stuck with the old gdm forever, or at some point have to say "screw configuration and screw autologin" and swallow the new one | 14:33 |
| Keybuk | anyway, since we have no other business, let's end the meeting now so other people can do other things ;) | 14:34 |
| pitti | right | 14:34 |
| Keybuk | pitti: or implement config and autologin | 14:34 |
| * MacSlow needs to go to the loo | 14:34 | |
| MacSlow | that's urgent :) | 14:34 |
| seb128 | pitti: well, they are discussing it upstream | 14:34 |
| Keybuk | isn't upstream just RH ? | 14:35 |
| seb128 | multi-display will come back when they get multi-seat support in consolekit | 14:35 |
| seb128 | Keybuk: the old maintainer which he still trying to contribute works for sun | 14:35 |
| cjwatson | we need autologin for the installer experience to be sane, btw | 14:35 |
| seb128 | s/he/is | 14:35 |
| cjwatson | (or else do foul things to bypass gdm) | 14:35 |
| seb128 | there is autologin now apparently, it's just hidden in gconf | 14:35 |
| seb128 | they have no gdmsetup for the new version | 14:35 |
| seb128 | and no config migration | 14:36 |
| seb128 | multi-display is not possible | 14:36 |
| seb128 | there is no xdmcp option in the login screen | 14:36 |
| seb128 | also there is no graphical banner | 14:37 |
| seb128 | but that's something we would not care a lot about if we get the new face-browser | 14:37 |
| seb128 | though people who don't have the hardware for that will fallback to the standard GTK banner | 14:37 |
| kwwii | whenever we figure out which gdm we are using and how it needs to be themed, be sure to think of telling me please ;-) | 14:37 |
| pitti | multi-display as in "two running user sessions in parallel"? | 14:39 |
| seb128 | "+ GDM doesn't support multi-display. This means that distros that | 14:41 |
| seb128 | want to support users with terminal-server, thin client, or other | 14:41 |
| seb128 | novel setups will not be able to migrate to the new GDM rewrite until | 14:41 |
| seb128 | this is addressed." | 14:41 |
| seb128 | pitti: that's what the previous upstream wrote on the list | 14:41 |
| seb128 | 14:42 | |
| seb128 | oh, btw in case that's interesting information for somebody they added policykit support to set system default settings to gconf in svn | 14:44 |
| pitti | mvo__: ^ | 14:45 |
| mvo__ | pitti: I read about it the other day | 14:46 |
| seb128 | yeah, I think I mentionned it during the sprint when you were speaking about the proxy changes | 14:46 |
| pitti | brb, have to reboot (intrepid kernel struck me again) | 14:47 |
| === ubottu changed the topic of #ubuntu-meeting to: Current meeting: Java Team | Calendar: http://fridge.ubuntu.com/event | Logs: https://wiki.ubuntu.com/MeetingLogs/ | 24 Jul 16:00 UTC: Ubuntu Mobile | 25 Jul 20:00 UTC: MOTU | 28 Jul 14:00 UTC: Maintainer scripts | 31 Jul 14:00 UTC: Mentoring Reception | 31 Jul 16:00 UTC: Ubuntu Mobile | ||
| === mike is now known as Guest63363 | ||
| persia | Who's here for the Java meeting? | 14:59 |
| Koon | o/ | 14:59 |
| Guest63363 | I'm | 14:59 |
| * dbhole is (Deepak Bhole from Red Hat) | 15:00 | |
| Koon | dbhole: Thierry here, thanks for coming ! | 15:01 |
| dbhole | np! | 15:01 |
| === mikegr is now known as mikegr_ | ||
| === mikegr_ is now known as mikegr___ | ||
| * persia looks for slytherin | 15:02 | |
| slytherin | I am here | 15:02 |
| persia | OK. Let's get started then. | 15:02 |
| persia | Firstly, my apologies for not getting the minutes out. I'm editing the page now, and should have the history for future review. | 15:03 |
| persia | First up, Roadmap review: | 15:03 |
| persia | OpenJDK is now fully in main: moving that to Done. | 15:03 |
| persia | Robilad sends apologies due to OSCON, so we'll skip integration with the server stack | 15:04 |
| persia | Any volunteers to drive optimisation? | 15:04 |
| slytherin | optimization as in 'remove duplication'? | 15:05 |
| persia | optimisation as in "Identify possible opportunities to optimise the Java stack" | 15:05 |
| persia | OK. I'm dropping this from the Roadmap, as we've had a few meetings where nobody wanted to drive it. If anyone wishes to do so in the future, we can add it back. | 15:06 |
| slytherin | Ok. | 15:06 |
| persia | Next: slytherin: can you update on status of "Transition Java packages from multiverse to universe where possible."? | 15:07 |
| slytherin | Yes. I am currently evaluating packages. And I have come up with a list. Unfortunately the list is not online anywhere. I will put up a page by Saturday with details. | 15:08 |
| persia | Great. Any blocking issues? | 15:08 |
| slytherin | Nothing. Except few FTBFS. :-) | 15:09 |
| persia | Next: Koon: can you update on status of "Maven packaging support options"? | 15:09 |
| Koon | Yes. I've drafted a spec at https://wiki.ubuntu.com/JavaTeam/Specs/MavenSupportSpec that shows what the problem is -- now the document is open for anyone's suggestions on how to do it. | 15:09 |
| Koon | I invited Deepak here to explain to us how it was done in JPackage/Fedora, this would be one of the solutions. | 15:09 |
| Koon | (if all compatible with Debian policies) | 15:10 |
| dbhole | Hi guys.. I am Deepak. I wrote the patches for maven that went into JPackage, and subsequently Fedora | 15:10 |
| dbhole | our motivation was two fold: 1) allow full offline builds 2) use jars from the system | 15:11 |
| persia | dbhole: would you mind if we finished the Roadmap review quickly, and then focused on that? | 15:11 |
| dbhole | oh, oops.. sorry I thought that was my cue :) sure, just let me know when to talk! | 15:11 |
| * persia may have failed to post some URLs to make this clear | 15:11 | |
| persia | Agenda: https://wiki.ubuntu.com/JavaTeam/Meeting | 15:11 |
| persia | Roadmap: https://wiki.ubuntu.com/JavaTeam/Roadmap | 15:11 |
| dbhole | ah, hadn't seen that | 15:12 |
| persia | missing item from the Roadmap discussed last meeting: slytherin: did you get any feedback from Debian regarding a consistent version of libraries for intrepid/lenny? | 15:12 |
| slytherin | persia: No. I didn't follow up on that, sorry. | 15:13 |
| persia | slytherin: No worries. Please bring it as a new agenda item if you get a chance later. | 15:13 |
| persia | OK. Roadmap review complete. | 15:13 |
| persia | Next item: Presentation of the JPP Maven patchset by Deepak Bhole | 15:13 |
| persia | dbhole: All yours :) | 15:13 |
| dbhole | alright! | 15:13 |
| dbhole | okay, so I will start off with what I mentioned above: our motivation was two fold: 1) allow full offline builds 2) use jars from the system | 15:14 |
| dbhole | while maven2 does have an offline switch, it doesn't strictly work. It will still go online to determine snapshot versions, or latest versions (when none are specified in the pom) | 15:14 |
| dbhole | JPackage (JPP)/Fedora have a single patch that fixes both issues. It ensures that maven will never go online no matter what, and it makes it so that maven can read files from the local filesystem | 15:15 |
| dbhole | to make it be offline, the patch injects code into certain places where maven tries to determine whether or not it should be going online (for snapshots, missing versions, etc.) | 15:16 |
| Koon | dbhole: is the patch specific to the Fedora-way the Java libraries are laid out on the filesystem ? | 15:16 |
| dbhole | Koon: Yes, it is. However, there are 2 components .. 1) Patch 2) 2 java files that define a "repository layout" .. while the patch does have some code specific to fedora/jpp layout (changing code in maven bootstrap files) .. most of the spefici code is in the layout .java files | 15:17 |
| Koon | afaict our layout is simple : everything in /usr/share/java | 15:18 |
| Koon | so it shouldn't be too difficult to change for a Java programmer | 15:18 |
| dbhole | Koon: great, that sounds similar to JPP/Fedora. Only one slight difference there though is that JPP/Fedora also uses subdirectories under /usr/share/java under certain cases | 15:19 |
| dbhole | Koon: But that couldn't require any changes to the patch set, as the patch itself needs to no nothing about subdirectories and what not | 15:20 |
| persia | Ubuntu also has subdirectories in /usr/share/java in some special cases (e.g. openoffice) | 15:20 |
| dbhole | s/couldn't/shouldn't | 15:20 |
| dbhole | ah okay, yes then the layouts are very similar in Ubunto and JPP/Fedora | 15:20 |
| Koon | dbhole: how do you solve the .pom part ? | 15:20 |
| dbhole | Koon: Initially when maven was introduced, the packages did not install poms, so we created a maven2-common-poms package, that supplied all kinds of poms. Now, as we rebuilds/update other packages, we are starting to add poms to those packages itself | 15:22 |
| dbhole | the patch set allows definition of "default" poms (those that comes from maven2-common-poms) .. when packages install their own poms in a different locations, those new poms automatically take preference | 15:22 |
| persia | dbhole: Are there any cases where you've found it to be better to have the .pom file in maven2-common-poms, or is that just a pragmatic convenience package? | 15:23 |
| dbhole | persia: nope, we always prefer the package to have it's own pom, because a pom installed by the package is more likely to have correct dependencies that one installed by the common poms package, which may have older poms | 15:24 |
| Koon | dbhole: I was wondering if shipping them artificially with the source that require them was a simpler solution -- because having a dependency system parallel to the dpkg one doesn't sound too good to me | 15:24 |
| persia | Maybe we could create e.g. dh_pom to help do something like we do which shlibs for C? | 15:25 |
| slytherin | persia: +1 | 15:25 |
| slytherin | but in this case we need to calculate build dependencies. AFAIK, dh_shlibs calculates runtime dependencies | 15:26 |
| dbhole | Koon: how do? for example if maven needs plexus-utils, do you mean ship plexus-utils pom with maven? | 15:26 |
| dbhole | s/do/so | 15:26 |
| persia | slytherin: Ah, right, and automated calculation of build-dependencies is frowned upon. | 15:27 |
| Koon | dbhole: no, we /could/ (though it's dirty), take all poms downloaded by the "normal maven", fix them so that they require the right versions, and make a giant patch to the source that creates the appropriate pom files under .m2 | 15:27 |
| slytherin | I have a question. | 15:28 |
| persia | Koon: That sounds like the maven2-common-poms solution, which was identified as less good. | 15:28 |
| Koon | persia: sure. I just fear that updating/writing those poms might be very dangerous and can BreakYourBuilds(tm) | 15:29 |
| dbhole | Koon: Right, but then that would require more work for each package. With our current system, all our spec file does is run "mvn-jpp" and everything just works | 15:29 |
| Koon | dbhole: ok so in your experience it's not breaking that often | 15:29 |
| dbhole | persia: the common-poms file is not a permanent solution. As more packages in the stack start installing their own poms, the idea is that eventucally we can just get rid of common-poms package | 15:30 |
| dbhole | Koon: nope .. specially once after each package installs their own pom, from that point own, the poms are automatically correct | 15:30 |
| dbhole | s/own/on | 15:30 |
| persia | Koon: I see two different use cases: firstly is the Java developer wanting to use maven. For that, we want maven to work, and can expect the developer to install the required libraries (as with -dev in C). | 15:30 |
| Koon | dbhole: what happens if a java library is updated but no .pom file is shipped with it... that would break the common_poms, right ? | 15:30 |
| persia | Secondly is using maven for automated builds on the buildds, for which we manually set Build-Depends anyway, so we know them to be complete. | 15:31 |
| persia | dbhole: Right. Based on that, I'm arguing against introducing common-poms in Ubuntu. | 15:31 |
| dbhole | Koon: correct, if a java library (that does not install it's own pom) is updated and the commons-poms installs an older version of that pom, there will be a failure | 15:31 |
| Koon | persia: in case (1) would the developer not use the auto-magically-download of maven ? | 15:31 |
| persia | Koon: Not if we patch maven to not do that. We only ship one maven, with one behaviour. | 15:32 |
| Koon | persia: ah, that would be different to the fedora way, then. They have two mavens: mvn and mvn-jpp | 15:32 |
| persia | Anyway, I don't think we want developers to use auto-magically-download, as it means the result is less likely to work in Ubuntu. | 15:32 |
| persia | Oh. Hrm. I'm not sure then. | 15:32 |
| dbhole | persia: The behavior of maven to use the local file system is completely optional. That is a key feature of our patchset.. if one runs "mvn", it will behave like upstream maven 100% | 15:33 |
| dbhole | only mvn-jpp alters behaviour | 15:33 |
| Koon | persia: we can't just package everuything a java dev would want | 15:33 |
| mikegr___ | I have a question, too. how does a single java package creator know that it's library with a specific filename isn't already delivered by another package if all libraries are stored in a flat directory? | 15:33 |
| persia | mikegr___: Contents.gz is one means to check. | 15:33 |
| persia | Koon: I'd like to package everything, but I understand what you mean :) | 15:34 |
| Koon | persia: I would go with the double-version, otherwise we'll alien the java dev community | 15:35 |
| persia | That makes sense. | 15:35 |
| persia | OK. Anyone have any objections to looking at Fedora's mvn-jpp and using that as a model for our maven packages? | 15:36 |
| persia | Any more questions for dbhole? | 15:36 |
| Koon | to sum it up: we apparently could go with the -jpp patchset, we might not want to have common-poms though, but rather have a qa pass on all libraries to ship pom with them | 15:36 |
| Koon | dbhole: what would be the patches to use | 15:37 |
| Koon | maven2-JPackageRepositoryLayout.java | 15:37 |
| Koon | maven2-jpprepolayout.patch | 15:37 |
| dbhole | Koon: maven2-jpprepolayout.patch maven2-JPackageRepositoryLayout.java and maven2-MavenJPackageDepmap.java | 15:37 |
| Koon | about the depmap, cuold you briefly explain how it works ? | 15:38 |
| Koon | that's something to proovide with the package to-build-with-maven right ? | 15:38 |
| slytherin | I have a suggestion. | 15:39 |
| slytherin | What we can do first is make maven work in offline mode and rely on the packager for correct build dependencies. | 15:39 |
| dbhole | Koon: Sure. So because we want to use the libraries on the local fs, we need a way to tell maven how to map the dependencies as it sees it, to where those libraries are on the system. That is the basic idea of the depmap.. it serves as a "mapping config" for "libraries as maven knows it" to "library on filesystem" | 15:39 |
| Koon | slytherin: maven won't work without pom files | 15:39 |
| slytherin | Koon: Let's say we are trying to build a package which already had pom. We force maven to not download dependencies from third party repositories. | 15:40 |
| Koon | dbhole: ok, and if the file is in /usr/share/java you just put GROUPID=/ ? | 15:41 |
| slytherin | At the same time, we rely on developer to know correct build dependencies. This is first part of teh spec. | 15:41 |
| slytherin | Then we can start looking into how we can calculate build dependencies based on .pom files. | 15:41 |
| dbhole | Koon: No, for historical reasons (they way jpackage packaged maven 1.0/1.1), we use groupid=JPP for /usr/share/java .. and any subdirs beneath are appended ... e.g. /usr/share/java/plexus = JPP/plexus for groupid | 15:42 |
| Koon | dbhole: ok. | 15:42 |
| slytherin | DO we use jpackage at all in Debian/Ubuntu? | 15:43 |
| Koon | dbhole: last question about build-time maven plugins | 15:43 |
| dbhole | Koon: also, as each package installs it's own pom, we also make it add it's own dependencies in a central file.. which is why mvn-jpp rarely needs a dependency map specification | 15:43 |
| dbhole | er | 15:43 |
| Koon | dbhole: if you take Geronimo for instance, the maven build starts with building a series of geronimo-maven-plugins | 15:43 |
| Koon | dbhole: would those coexist peacefully with the system-installed ones ? I suppose yes ;) | 15:44 |
| dbhole | we make a package install it's dependencies map in a single file, I mean | 15:44 |
| dbhole | Koon: yes, they would | 15:44 |
| dbhole | Koon: plugins can be packaged and added on top as needed under various locations in /usr/share/java .. as long as the mapping is right, they work fine | 15:45 |
| Koon | dbhole: about the central file, it's a single file or a depmap.d directory ? | 15:46 |
| Koon | slytherin: no, it's RPM only atm | 15:46 |
| dbhole | Koon: currently a central file, /etc/maven/maven-dempap.xml ... the packages install their own fragment under /etc/maven/fragments/ .. and in postinstall, they cat that into the central file | 15:47 |
| Koon | dbhole: ok, we might need to review that for debian policy reasons. | 15:47 |
| Koon | Thank you very much for all those precisions | 15:47 |
| dbhole | Koon: sure.. you can easily change that, all of that logic is in the .java files | 15:48 |
| dbhole | Koon: no problem, glad I could help! | 15:48 |
| Koon | dbhole: if someone tries to implement that, I'm pretty sure we'll have more questions :) | 15:48 |
| dbhole | certainly! my email address is dbhole@redhat.com if any further questions come up | 15:50 |
| dbhole | (for those that didn't it) | 15:50 |
| dbhole | er, didn't have it | 15:50 |
| persia | dbhole: Thanks a lot for explaining in such detail. | 15:50 |
| * dbhole should not have skipped on coffee today | 15:50 | |
| persia | Last item on today's agenda: About Scala and how to help | 15:50 |
| dbhole | persia: you're welcome | 15:50 |
| persia | mikegr___: The floor is yours | 15:50 |
| mikegr___ | hello, I'm not familiar with packaging, but I would like to add latest version of scala to ubuntu. | 15:51 |
| mikegr___ | there is an old package with version 2.6.1 which is from debian. | 15:51 |
| mikegr___ | and a request for this https://bugs.launchpad.net/ubuntu/+source/scala/+bug/239557 | 15:52 |
| ubottu | Launchpad bug 239557 in scala "Update Scala 2.7.1.final has been released" [Undecided,New] | 15:52 |
| mikegr___ | :-) | 15:52 |
| mikegr___ | so is someone working on this or how could l help | 15:52 |
| mikegr___ | should/may I contact the old maintainer? | 15:53 |
| persia | mikegr___: The bug is not currently assigned to anyone, which usually means nobody is working on it in Ubuntu. | 15:53 |
| slytherin | mikegr___: is the package orphaned in Debian? | 15:53 |
| persia | As this update would also fix some release critical bugs for Debian (from what I see), you might contact the Debian maintainer to see how you could help. | 15:54 |
| persia | If that doesn't work, I'd recommend building an updated source package and attaching a diff.gz to the Ubuntu bug for review (remember to assign yourself the Ubuntu bug if you are working on it). | 15:55 |
| mikegr___ | ok. what link can you give me for a first read regrarding packaging? | 15:55 |
| mikegr___ | anyway I will contact the maintainer and come back to you. | 15:56 |
| mikegr___ | thanks for the hint about this content.gz. i'm newbie on that. | 15:58 |
| persia | There was a good page on the Debian wiki about Java packaging, but I can't find it right now.http://www.debian.org/doc/packaging-manuals/java-policy/ may provide some interesting information. | 15:58 |
| persia | OK. Anyone have any last minute items for the agenda? | 15:58 |
| slytherin | I have one. | 15:59 |
| persia | slytherin: Go. | 15:59 |
| slytherin | damn, I forgot what I had to say. :-( | 15:59 |
| slytherin | Leave it. | 15:59 |
| persia | slytherin: Just add it to the wiki when you think of it, and we'll do it next week, | 15:59 |
| slytherin | sure | 16:00 |
| persia | Last item: who would like to volunteer to write the minutes for today? | 16:00 |
| slytherin | persia: I can but not immediately. Also I have not written minutes before so please guide me. | 16:02 |
| persia | slytherin: That'd be great. Thanks. Catch me to ask questions whenever. | 16:03 |
| slytherin | ok | 16:03 |
| persia | Next meeting is 31st July, 14:00 UTC. | 16:03 |
| persia | Thanks everyone for coming. | 16:03 |
| cjwatson | mikegr___: apt-file is a useful wrapper around searching Contents-$ARCH.gz, FYI | 16:05 |
| mikegr___ | cjwatson: thanks | 16:17 |
| === mvo__ is now known as mvo | ||
| === ubottu changed the topic of #ubuntu-meeting to: Calendar: http://fridge.ubuntu.com/event | Logs: https://wiki.ubuntu.com/MeetingLogs/ | 24 Jul 16:00 UTC: Ubuntu Mobile | 25 Jul 20:00 UTC: MOTU | 28 Jul 14:00 UTC: Maintainer scripts | 31 Jul 14:00 UTC: Mentoring Reception | 31 Jul 16:00 UTC: Ubuntu Mobile | 02 Aug 13:00 UTC: Xubuntu Community | ||
| === ubottu changed the topic of #ubuntu-meeting to: Current meeting: Ubuntu Mobile | Calendar: http://fridge.ubuntu.com/event | Logs: https://wiki.ubuntu.com/MeetingLogs/ | 25 Jul 20:00 UTC: MOTU | 28 Jul 14:00 UTC: Maintainer scripts | 31 Jul 14:00 UTC: Mentoring Reception | 31 Jul 16:00 UTC: Ubuntu Mobile | 02 Aug 13:00 UTC: Xubuntu Community | ||
| persia | #startmeeting | 17:00 |
| MootBot | Meeting started at 11:03. The chair is persia. | 17:00 |
| MootBot | Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] | 17:00 |
| persia | [LINK] https://wiki.ubuntu.com/MobileAndEmbedded/Meeting/20080724 | 17:00 |
| MootBot | LINK received: https://wiki.ubuntu.com/MobileAndEmbedded/Meeting/20080724 | 17:00 |
| persia | There are no action items from last week. | 17:00 |
| persia | There are no current agenda items. | 17:01 |
| persia | Does anyone have anything they want to add to the agenda? | 17:01 |
| * ogra waves | 17:01 | |
| ogra | nothing to add here :) | 17:01 |
| ogra | persia, are we the only ones ? | 17:02 |
| persia | ogra: At least the only ones yet to write anything :) | 17:02 |
| ogra | heh | 17:02 |
| * agoliveira is lurking around too. | 17:03 | |
| mkrufky | im sitting in, cuz im curious | 17:03 |
| Java-Jim | same here | 17:04 |
| ogra | well, it will likely be a short meeting if we dont have anything to discuss :) | 17:05 |
| persia | Yep. Unless anyone has anything, I'll end the meeting | 17:05 |
| lool | Good short meeting! | 17:07 |
| persia | Thanks everyone for coming. Please add items to the agenda for next week, and we'll have something to discuss. In the meantime, #ubuntu-mobile is the place to ask questions. | 17:07 |
| persia | #endmeeting | 17:07 |
| MootBot | Meeting finished at 11:10. | 17:07 |
| agoliveira | Best one ever! You guys are getting good at it! :-D | 17:09 |
| ogra | heh | 17:10 |
| === mkrufky is now known as mkrufky-lunch | ||
| === ubottu changed the topic of #ubuntu-meeting to: Calendar: http://fridge.ubuntu.com/event | Logs: https://wiki.ubuntu.com/MeetingLogs/ | 25 Jul 20:00 UTC: MOTU | 28 Jul 14:00 UTC: Maintainer scripts | 31 Jul 14:00 UTC: Mentoring Reception | 31 Jul 16:00 UTC: Ubuntu Mobile | 02 Aug 13:00 UTC: Xubuntu Community | 03 Aug 18:00 UTC: Mozilla Team | ||
| === ember_ is now known as ember | ||
| === mkrufky-lunch is now known as mkrufky | ||
| === chuck_ is now known as zul | ||
| === kirkland` is now known as kirkland | ||
| === Moot2 is now known as MootBot | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!