[05:51] <pam> cjwatson: Is there a gfxboot language reference somewhere (not just the vocabulary but more general like stack handling,...)? I am failing miserably trying to walk through arrays (http://pastebin.com/m193ef855)
[07:40] <pitti> Good morning
[07:41] <geser> Hi pitti
[07:44] <pitti> hey geser, wie gehts?
[07:44] <geser> fine
[07:45] <geser> and you?
[07:45] <pitti> great, enjoyed some days off
[07:57] <StevenK> Hey pitti!
[07:58] <StevenK> pitti: It appears that the UNR and Ubuntu livefses fail to build due to: system-config-printer-udev: Conflicts: hal-cups-utils but 0.6.19+git20090217-0ubuntu7 is to be installed
[07:58] <StevenK> pitti: Should hal-cups-utils just get unseeded in both cases?
[07:59] <pitti> StevenK: yes, it should; it's obsolete
[07:59] <StevenK> pitti: Okay, shall I fix both seeds and both meta packages?
[08:00] <pitti> StevenK: I'm just committing the ubuntu change
[08:03] <StevenK> pitti: You'll fiddle ubuntu-meta, or shall I?
[08:03] <pitti> StevenK: please go ahead while you are at it
[08:21] <maxb> I'm feeling a bit snubbed by the fast closure of https://bugs.launchpad.net/bugs/406070. Isn't a feature present in Jaunty being lost from Karmic a valid regression bug worth tracking, regardless of whether it's upstream's fault?
[08:22] <pitti> mbiebl: FYI, I committed 20_cpufreq_warning_message_fix.patch upstream, so we are back to two distro specific and easy patches in hal
[08:24] <pitti> mbiebl: do you want me to commit the hal smartdimmer support that we have in Ubuntu to the debian experimental branch?
[08:25] <pitti> mbiebl: I won't commit it for now, it's a bit dubious
[08:36] <pitti> mbiebl: oh, and it's obsolete in the new DK world anyway
[08:45] <seb128> maxb, the bug is not constructive, you should rather open request to add features to the new capplet
[08:47] <maxb> Hrm. Tracking a feature regression in the distro is not useful?
[08:48] <maxb> The features don't really belong in an applet calling itself the "Volume Control" anyway
[08:49] <seb128> maxb, what feature?
[08:50] <seb128> maxb, opening bugs about "the new capplet version sucks" is of no use no
[08:50] <seb128> maxb, you should open a bug about "gnome-volume-control should let you selection <option you need>"
[08:50] <seb128> selection -> select
[08:51] <maxb> I didn't say "it sucks", I said "removed without adequate replacement"
[08:52] <maxb> furthermore, I stated in the bug why adding features to gnome-volume-control didn't make sense
[08:52] <seb128> maxb, still not a constructive way to approch things, we don't write this code
[08:52] <seb128> well try being constructive there
[08:52] <seb128> suggest what we should do knowing that we will not roll back to distro patch deprecated code
[08:54] <maxb> Leaving aside all other matters, isn't it important to track the fact that we've removed a user-visible feature and not supplied any replacement?
[08:54] <maxb> Especially when the feature is something Windows has had since 95? 3.1?
[08:55] <seb128> maxb, I stop this discussion there I'm not interested in non constructive discussion there, we already have a collection of bugs about people like the old version better for random reasons
[08:56] <maxb> Removal of a concrete features is not a "random reason"
[08:56] <maxb> * feature
[08:57] <seb128> you can select sound theme in the new interface
[08:57] <maxb> You can coarsely choose between "Ubuntu" and "No sounds", yes
[08:58] <maxb> that falls a long way short of selecting individual sounds for events
[08:58] <seb128> well open a bug about "new capplet should you set custom sounds for events"
[08:58] <maxb> and also it provides no way to select visual alert rather than audible, as the old one did
[09:01] <seb128> maxb, bug #324700 is your request about sound events made in a constructive way and not with an unclear ranting title
[09:06] <maxb> Your definition of ranting is considerably more sensitive than mine
[09:07] <seb128> maxb, sorry but your bug title suggest that we should not have changed to capplet without have some features there but the decision of rewritting is not ours
[09:07] <seb128> and we distro patched the previous codebase in jaunty to address those concerns
[09:09] <seb128> so better to suggest changes to make it adequate rather than complain about the switch not being adequate
[09:15] <maxb> OK, well, for my future reference, what _is_ the procedure when an upstream drops a feature without having firm plans to replace it?
[09:16] <maxb> I guess another example would be the gdm graphical configuration tool, which we luckily have someone interested in writing a new one
[09:16] <seb128> maxb, open a bug on the new component saying "the tools should have this feature"
[09:16] <maxb> But in the general case, do we aim to track such feature-loss regressions in any way, or do we just aim to make upstream's current feature set work well?
[09:16] <seb128> maxb, not saying "you switched before it was ready" or "how could you do that" or "new version sucks"
[09:17] <seb128> maxb, depends of the feature, I'm not sure sound events ever worked correctly under GNOME and they are not a stopper
[09:17] <seb128> maxb, ie they don't prevent any work to get done, don't destroy any data, etc
[09:18] <seb128> we don't aim to replace every corner case option or at least don't consider that has a stopper
[09:18] <seb128> as
[09:19] <hile> for people who care about the sound themes the new capplet is of course a step backwards. myself, I only care about the 'disable all event sounds and themes' buttons
[09:21] <hile> maybe this is some evil plan for 'sound theme feature pack' sales :)
[10:16] <dpm> pitti: may we borrow you for a second on #kubuntu-devel for a question on translations (Riddell tells us that you also initially set up the kde i18n packaging infrastructure)
[10:21] <pitti> dpm: joined
[10:21] <dpm> thanks! :)
[10:22] <sebner> pitti: uploaded lyx. thanks for you help
[10:23] <PecisDarbs> hi people, is there any plans to address mobile broadband modem issue with usb_modeswitch? This utility isn't in repos even.
[10:23] <pitti> sebner: just saw it, thanks for sorting this out
[10:24] <sebner> pitti: well, my duty since I acked the sync :)
[10:25] <sebner> pitti: really fixing it during archive-reorg?
[10:26] <pitti> sebner: not really, I think
[10:26] <pitti> we still don't want to officially "bless" lyx with support, do we?
[10:27] <sebner> pitti: heh, well sooner or later ...
[10:27] <sebner> it's the main -> universe problem
[10:28] <pitti> well, it's not a technical bug in any way, we specifically don't want to support each and every package in the universe
[10:31] <sebner> pitti: right, so what the long-term solution do you have in mind?
[10:34] <pitti> sebner: keep a separate source, or fix the two packages in main which pull it in to depend on an alternative
[10:34] <pitti> or drop to suggests
[10:34] <ttx> pitti: about the Eucalyptus MIR process, I've started writing up MIR reports for a first set, see bug 405715. Please let me know if the way it's presented, the level of details etc. is OK and I should continue this way. For example, let me know if I should push reports to a wikipage instead.
[10:34] <tseliot> pitti: what would be the best way to add a hal quirk? A separate package or adding it to hal would be better?
[10:35] <pitti> ttx: looks okay; please note that it's enough to mention dependencies which are not in main
[10:35] <pitti> tseliot: what kind of quirk?
[10:35] <ttx> pitti: ok thx
[10:35] <tseliot> pitti: for suspend/resume (for an OEM project)
[10:36] <pitti> tseliot: suspend quirks for models should go into hal-info (I can commit them upstream)
[10:37] <tseliot> pitti: ok, thanks, that's exactly what I needed to know :-)
[10:38] <pitti> tseliot: send it to hal@lists.fd.o or to me, or to a bug report and sub me
[10:39] <sebner> pitti: for karmic +1 I suppose?
[10:39] <pitti> sebner: not particularly; it can happen whenever it's convenient
[10:39] <sebner> heh, kk
[10:39] <tseliot> pitti: I can't do this yet as I can't disclose the vendor's identity but I'll do it ASAP
[10:40] <pitti> oh
[10:41] <pitti> tseliot: right, just send it once it's possible, and keep it as a private patch until then
[10:41] <tseliot> pitti: yes, the patch will live only in the OEM repos for now
[10:45] <tjaalton> pitti: wrote a MIR for audit, it's holding xorg-server back, bug 406226
[10:46] <pitti> Guest82317: I still know who you are!!!
[10:46] <tjaalton> probably needs kees or someone to check it first
[10:46] <NCommander> pitti, I continue to retry to regain my lost ID
[10:47] <pitti> tjaalton: right, tossed to kees
[10:47] <tjaalton> pitti: thanks
[10:53] <robbiew> evand: welcome back to the world of the internets :)
[10:53] <evand> thanks!
[10:54] <pitti> hey evand
[10:54]  * evand was starting to get the shakes
[10:54] <evand> hi
[10:54] <pitti> feeling lonely? :-)
[10:54] <highvoltage> welcome back to the webs evand
[10:55] <evand> haha, indeed
[10:55] <evand> thanks highvoltage
[11:33] <unggnu> hi all
[11:33] <gnomefreak> .win 10
[11:34] <unggnu> Is there a reason why the Firefox 3.5 package even in Karmic needs so many Gnome dependencies while the 3.0 not? There are probably many KDE users who want to install Firefox.
[11:34] <unggnu> And Firefox 3.5 from the homepage even works fine without all this dependcies. Could somebody please fix this?
[11:35] <gnomefreak> unggnu: not the pace for that question please join me in #ubuntu-mozillateam
[12:30] <Timmy2Tall> i am trying to play world of warcraft on ubuntu but after i have installed it it wants to update but when i get to the terms and conditions it will not let me click accept. help plz
[12:33] <directhex> Timmy2Tall, this is really the opposite of a "user support running wine" channel
[12:33] <directhex> YokoZar, what's the wine users' channel?
[12:34] <YokoZar> directhex: #winehq
[12:35] <directhex> Timmy2Tall, ^^
[12:35] <Timmy2Tall> Hey man lol
[14:01] <maxb> Where, and after what duration of posting sensibly, may I apply for unmoderated posting on ubuntu-devel@ ?
[14:02] <maxb> It's a bit awkward participating in a discussion when your responses don't hit the list for hours/days
[14:08] <hyperair> maxb: i thought you were a MOTU. =O
[14:09] <maxb> one day :-)
[14:09] <hyperair> go get UUC-ship first then!
[14:09] <hyperair> that'll effectively allow you to post without moderation
[14:11] <maxb> I probably have (almost?) enough knowledge, what I lack is the skill at actually managing my time to get Ubuntu dev stuff done having been at work all day doing employee dev stuff
[14:52] <kees> tjaalton: hah, funny, I was going to be writing the audit MIR since AppArmor needs it too now.  :P
[14:53] <pitti> kees: so now you have the chance to "self" approve it :)
[14:53] <kees> pitti: yup!  perfect.  :)
[14:53] <kees> it should be pretty trivial, actually.  I just hadn't made time for it yet -- had it on the security team's sprint todo list.  :P
[14:54] <tjaalton> kees: heh, great :)
[15:31] <robbiew> cjwatson: doko: evand: james_w: Keybuk: liw: mvo: slangasek: al-maisan: mterry: FYI - No Meeting
[15:32] <liw> robbiew, ack
[15:32] <james_w> thanks
[15:32] <mterry> yup
[15:32] <doko> siesta ...
[15:32]  * robbiew sent email, but knows not everyone checks their's every 5min like he does :P
[15:32] <al-maisan> robbiew: thanks for letting me know!
[15:33] <maxb> doko: Hi, did you see my question about default-jdk-builddep yesterday?
[15:34] <maxb> < maxb> I'm trying to push a s/default-jdk-builddep/default-jdk/ change back to Debian and the maintainer is hesitant because no Debian Policy explains the purpose of these
[15:34] <maxb> < maxb> Can you provide an authoritative Debian citation for the correct usage of default-jdk vs. default-jdk-builddep?
[15:34] <doko> maxb: no, there's none. the one from the ubuntu wiki looks ok however
[15:34] <mvo> robbiew: ok
[15:36] <maxb> OK. I've pointed the maintainer in question at your java-gcj-compat-dev builddep mass bug filing, if that's not good enough I shall refer him to this irclog
[17:12] <snadge> tried #ubuntu, google.. can only find old info on 64bit sun java.. it appears to be broken, applets not initializing .. jnlp failing to launch .. i have other 64bit ubuntu machines that i stuffed around with and cant remember how i got it to work.. opinions?
[17:12] <snadge> i think it may have involved downloading it from sun and installing it manually
[17:12] <ScottK> NCommander: More powerpc fun: https://launchpad.net/ubuntu/+source/dc-qt/0.2.0.alpha-4ubuntu2/+build/1139325/+files/buildlog_ubuntu-karmic-powerpc.dc-qt_0.2.0.alpha-4ubuntu2_CHROOTWAIT.txt.gz
[17:14] <snadge> has anyone suggested the support channel for ubuntu be broken up into two channels.. #ubuntu-n00b or #ubuntu-idontknowhowtousegoogle and #ubuntu
[17:15] <snadge> the signal to noise ratio in there is ridiculous
[17:16] <Pici> snadge: There is a discussion about it currently on the Ubuntu IRC Council agenda as well as something ongoing on the ubuntu-irc mailing list.
[17:16] <mathiaz> james_w: when you submit a merge proposal and you subscribe a specific person, it seems that no notification are sent
[17:16] <mathiaz> james_w: ex: https://code.launchpad.net/~mathiaz/ubuntu/karmic/cim-schema/2.22.0-update/+merge/9397
[17:17] <mathiaz> james_w: ttx didn't get notified by LP
[17:17] <snadge> im only saying this because #ubuntu-devel is not a support channel.. i just thought someone knowledgeable on sun java on 64bit jaunty, would take pity on me and point me to something useful
[17:17] <snadge> considering i have read the forums wikis.. the information is mostly outdated, and advocates manually installing it from sun.com
[17:17] <ttx> mathiaz: or maybe it got eaten by a spamfilter, but that would be by the canonical one :)
[17:19] <Tronic> snadge: It would have to be #ubuntu and #ubuntu-longtimers or something like that.
[17:19] <Tronic> Newbies always come to #ubuntu.
[17:20] <Pici> Anyway, a better place to discuss this would be in #ubuntu-irc, as -devel is really for development stuff
[17:20] <ScottK> Tronic and snadge: This isn't the channel for Ubuntu IRC channel planning.
[17:21] <snadge> thanks.. duly noted
[17:27] <james_w> mathiaz: did you put ttx in the "reviewer" box?
[17:28] <mathiaz> james_w: yes
[17:32] <mbiebl> pitti: so your commits, thanks
[17:34] <mbiebl> s/so/saw/
[17:37] <mathiaz> james_w: regarding pywbem rejection, should the license use of "either" be fixed before a new upload?
[17:37] <mathiaz> james_w: I've already corrected the other mistake (yacc.py is LGPL2 and not LGPL2+ in debian/copyright)
[17:54] <james_w> mathiaz: I'm not sure
[17:54] <james_w> I'll ask around
[17:54] <mathiaz> james_w: ok - I've emailed the upstream authors to get a reponse from them.
[17:54] <james_w> thanks
[17:56] <vikram> Hi guys
[17:56] <james_w> mathiaz: bug 406492
[17:56] <vikram> How do I use this chat client
[17:56] <vikram> please help
[18:01] <alonswartz> question for mdz , mvo and anyone else knowledgable about apt pinning. I filed a bug on LP a while back and recently it manifested itself in a bad way in one of our systems. I was hoping someone could take a look http://bit.ly/10N2Ub
[18:18] <james_w> mathiaz: upload and I'll accept
[18:33] <mathiaz> james_w: new version of pywbem uploaded
[18:34] <james_w> thanks
[18:35] <maxb> alonswartz: bizarre, must be a bug deep in the guts of apr
[18:35] <maxb> * apt
[18:37] <alonswartz> maxb: yeah, i know - very weird. What would be the best way to get this confirmed and on its way to being solved?
[18:38] <maxb> Well, confirming it is easy. (I just did). Solving it requires someone to actually dig deep into the apt sourcecode.
[18:39] <maxb> You might like to upstream it to debian
[18:39] <alonswartz> maxb: what version of apt are you using?
[18:39] <maxb> I'm on karmic
[18:40] <maxb> !info apt
[18:40] <alonswartz> maxb: just saw you updated the bug report, thanks!
[18:40] <maxb> !info apt karmic
[18:41] <maxb> Well that's interesting. apt-get may want to downgrade, but aptitude doesn't
[18:43] <alonswartz> maxb: the plot thickens...
[18:44] <maxb> Not particularly, apt-get and aptitude don't share 100% of the package management code
[18:46] <alonswartz> I suppose that might help in narrowing it down (I'm not familiar with the apt code)
[18:51] <james_w> chrisccoulson: hey, did you speak to the Debian maintainer about libgdamm4.0?
[18:52] <chrisccoulson> james_w - not yet. it's on my list of things to do
[18:53] <james_w> chrisccoulson: them not renaming in the same way, but I don't think it would be a killer would it?
[18:55] <chrisccoulson> they should rename it in the same way shouldn't they?
[18:55] <james_w> I assume so
[18:56] <chrisccoulson> i can contact the debian maintainer still. i only started working on updating that last night because another update i'm doing needs it
[19:13] <mathiaz> james_w: could you bump up the priority of sblim-cmpi-base pkg import?
[19:14] <james_w> done
[19:15] <mathiaz> james_w: thank you :)
[19:31] <sroecker> hi, any jockey experts around?
[20:53] <mathiaz> Using cdbs, how can I rename usr/share/sblim-cmpi-base/provider-regiser.sh (as installed by upstream) to usr/bin/cmpi-provider-register (as I want it in the final debian package)?
[20:54] <ebroder> You have to add something to the debian/rules file
[20:55] <ebroder> I usually use binary-install/PACKAGE_NAME::, I think
[20:55] <ebroder> So do something like...
[20:55] <ebroder> binary-install/PACKAGE::
[20:56] <ebroder>         mv $(DEB_DESTDIR)/usr/share/sblim-cmpi-base/provider-regiser.sh $(DEB_DESTDIR)/usr/bin/cmpi-provider-register
[21:16] <mathiaz> ebroder: awesome - thanks! I use install/PACKAGE instead of binary-install
[21:17] <mathiaz> ebroder: it worked out well in the end :)
[21:17] <ebroder> install should be fine - just be sure to put it after you include your cdbs classes
[22:05] <kirkland> does anyone know why python-pysqlite2 might have dropped from main to universe?
[22:05] <kirkland> looks like landscape-common is depending on it now, which would necessitate bringing it back into main
[22:05] <kirkland> i'm wondering if i need an MIR to do this
[22:34] <ScottK> kirkland: Generally if it was in Main before you don't need a full MIR.
[22:34] <kirkland> ScottK: cool
[22:34] <ScottK> kirkland: Is there a *pysqlite3 in Main?
[22:34] <ScottK> There might be some resistance to supporting multiple versions.
[22:35] <mathiaz> ScottK: I don't think there is a pysqlite3
[22:35] <kirkland> python-sqlite - python interface to SQLite 2
[22:35] <ScottK> OK.
[22:35] <kirkland> python-pysqlite2 - Python interface to SQLite 3
[22:35]  * kirkland finds those descriptions confusing :-)
[22:35] <kirkland> both in universe
[22:35] <ebroder> kirkland: SQLite 3 support is built-in to Python >=2.5, isn't it?
[22:35] <mathiaz> ScottK: now that sqlite3 is in the standard library pysqlite doesn't need to exist anymore.
[22:36] <ScottK> ebroder: I think that's right.
[23:43] <TheMuso> /c/c
[23:54] <kirkland> siretart: ping
[23:54] <kirkland> siretart: would you please merge byobu-2.23 into Debian when you get a chance?
[23:57] <ebroder> Is there a relatively easy way to figure out how the debian-installer does a particular step? Say, installing grub?
[23:59] <ebroder> I guess I go hunting for udebs?