[15:00] <barry> #startmeeting
[15:00] <MootBot> Meeting started at 09:00. The chair is barry.
[15:00] <barry> hello everyone and welcome to this week's ameu reviewers meeting.  who's here today?
[15:00] <intellectronica> me
[15:00] <abentley> me
[15:00] <mars> me
[15:01] <gary_poster> me
[15:02] <allenap> me
[15:02] <EdwinGrubbs> me
[15:02] <barry> adeuring, bac ping
[15:02] <cprov> me
[15:02] <flacoste> me
[15:02] <barry> bigjools, BjornT ping
[15:02] <barry> danilo_: ping
[15:02] <adeuring> me, sorry for the delay
[15:02] <bac> me
[15:02] <barry> gmb: ping
[15:03] <barry> rockstar, salgado, sinzui ping
[15:03] <salgado> me
[15:03] <barry> [TOPIC] agenda
[15:03] <MootBot> New Topic:  agenda
[15:03] <barry>  * Roll call
[15:03] <barry>  * Action items
[15:03] <barry>  * Mentoring update
[15:03] <barry>  * Peanut gallery (anything not on the agenda)
[15:03] <sinzui> mo
[15:03] <sinzui> me
[15:03] <barry> pretty light day today (planned at least)
[15:04] <barry> [TOPIC] action items
[15:04] <MootBot> New Topic:  action items
[15:04] <rockstar> me
[15:04] <barry>  * danilo to look into storm/sqlobject result set compatibility
[15:04] <barry> is danilo_ here today?  flacoste do you have any status on this?
[15:04] <BjornT> me
[15:04] <flacoste> danilo?
[15:04] <flacoste> that was allenap
[15:04] <flacoste> backporting the patch he landed on storm trunk
[15:05] <allenap> I forgot :(
[15:05] <barry> flacoste: oops!
[15:05] <gmb> me
[15:05] <allenap> Please assign to me and I'll try and do it this time :)
[15:05] <barry> allenap: done, thanks
[15:05] <barry>  * gary_poster will check to see if there's a bug open for adding a hook to `bzr send`, and submit one if there isn't
[15:06] <gary_poster> no sorry
[15:06] <gary_poster> will put back on my list
[15:06] <barry> gary_poster: cool, thanks
[15:06] <barry>  * flacoste to work on API reviewer cheat sheet
[15:06] <rockstar> gary_poster, barry, abentley has a branch that he's been working on the forever.
[15:06] <gary_poster> rockstar: ok cool, I'll ask him about it
[15:06] <flacoste> barry: no progress since last week
[15:06] <barry> np
[15:06] <flacoste> barry: keep it up, i like this weekly "i suck" reminder :-)
[15:06] <barry> :-D
[15:06] <gary_poster> :-)
[15:07] <flacoste> good for keeping the ego in leash
[15:07] <abentley> gary_poster: I've done the support for specifying a body when sending, but not adding the hook.
[15:07] <gary_poster> abentley: cool.  I'm guessing it's not on your immediate plate to finish it up?
[15:07] <abentley> gary_poster: Right.
[15:08] <gary_poster> understood
[15:08] <gary_poster> thanks
[15:08] <barry> [TOPIC] mentoring update
[15:08] <MootBot> New Topic:  mentoring update
[15:08] <abentley> barry: Did you get anywhere with adding body support to claws?
[15:08] <gary_poster> abentley: do you happen to know if there's a bug for this, and what it might be, if so?
[15:08] <abentley> gary_poster: I'm not aware of a bug for this.
[15:08] <barry> abentley: i didn't :(
[15:09] <gary_poster> abentley: ok cool.
[15:09] <gary_poster> barry: one to-do item scratched off ;-) ...but maybe needs to be replaced with another.
[15:09] <barry> gary_poster: i'll cross it off and you can let me know if you want another
[15:09] <gary_poster> barry: cool thanks
[15:10] <barry> am i right that only stub is still being mentored?
[15:11] <barry> i should ping a few folks to see if they're ready to be mentats
[15:11] <barry> i don't think there's many folks left who aren't revewiers
[15:11] <barry> anyway...
[15:12] <barry> [TOPIC] peanut gallery
[15:12] <MootBot> New Topic:  peanut gallery
[15:12] <barry> do you guys have anything not on the agenda?
[15:12] <abentley> I am wondering if we have a policy on redundant assertions?
[15:12] <abentley> e.g. if foo; else: assert not foo
[15:13] <intellectronica> abentley: i thought the policy is that we always do this
[15:13] <intellectronica> but maybe it's not documented anywhere?
[15:13] <barry> intellectronica: we always have an else clause if there's an elif
[15:13] <barry> but if there's no elif we don't need an else+assert
[15:13] <intellectronica> oh, right
[15:13] <abentley> Why would we *always* do that?
[15:13] <rockstar> abentley's example seems to be different than what barry showed intellectronica
[15:14] <barry> abentley: doesn't make sense to me
[15:14] <rockstar> Yea, the else+assert seems a little silly, as though assert would catch something the if would not.
[15:14] <BjornT> abentley: do you have an example in our code?
[15:14] <abentley> BjornT: It was something I reviewed on Monday.
[15:14] <intellectronica> yes, sorry, i got confused. if there's only one if there's probably no need to do this, unless it's imprtant that the code fails at this point
[15:15] <abentley> https://code.edge.launchpad.net/~salgado/launchpad/bug-358498/+merge/5496
[15:16] <barry> abentley: the one on line 16 can just as well be raise AssertionError(...)
[15:16] <salgado> in this specific case I wanted the assertion because the 'elif' block should be removed soon, at which point the assertion will become non-redundant
[15:16] <barry> and that does fall within our guidelines
[15:16] <abentley> barry: It's unreacable code.
[15:16] <barry> abentley: proven by the assertion? <wink>
[15:16] <abentley> barry: It can equally well be raise IAmSuperman
[15:17] <barry> abentley: the one on line 13 seems okay, but should have a message
[15:17] <abentley> barry: It just seems like the wrong use of asserts-- proving that Python isn't buggy.
[15:17] <BjornT> abentley: ok. i would replace that assert with a raise AssertionError
[15:17] <barry> salgado: you're saying the whole 8-14 block will be removed eventually?
[15:18] <barry> abentley: sorry, i was talk about the one in the else clause (first)
[15:18] <barry> i.e. line 16 is fine
[15:18] <barry> line 13, yeah, i suppose. doesn't bother me too much either way
[15:19] <abentley> barry: I thought asserts were for proving your own state wasn't buggy.
[15:19] <barry> abentley: yes, or that the state you're assuming to be the case actually is the case
[15:19] <abentley> Anyhow, I'll continue to say "I think this is redundant, but keep it if you like."
[15:19] <barry> abentley: +1, for the line 13 assert
[15:20] <barry> oh, yeah, line 16 isn't a change
[15:20] <barry> but still.  or whatever.
[15:20] <abentley> barry: line 13 can't be reached because of line 6.
[15:20] <barry> abentley: thanks
[15:20] <barry> abentley: yep
[15:21]  * barry agrees with abentley when he says:  Anyhow, I'll continue to say "I think this is redundant, but keep it if you like."
[15:21] <BjornT> oh, we're talking about line 13. yes, that one should be removed
[15:22] <adeuring> well, yes, but salgado said that he will soon reorganize the code, so leaving this as a"reminder" is OK, IMHO
[15:22] <barry> agreed.  maybe the assertion message (which salgado will add <wink>) should state something to that effect?
[15:23] <salgado> maybe. :)
[15:23] <barry> abentley: thanks for bringing this up
[15:23] <barry> anything more on this?
[15:23] <abentley> barry: np
[15:24] <barry> does anybody else have anything not on the agenda?
[15:25] <barry> 5
[15:25] <barry> 4
[15:25] <rockstar> Happy Tax Day!
[15:25] <barry> rockstar: "happy"?!
[15:25] <barry> 3
[15:25] <barry> 2
[15:26] <barry> 1
[15:26] <barry> #endmeeting
[15:26] <MootBot> Meeting finished at 09:26.
[15:26] <gary_poster> bye
[15:26] <barry> thanks everyone!
[15:26] <mars> thanks barry
[15:26] <cprov> thanks barry
[15:26] <barry> see ya back at the ranch
[23:31] <thumper> here
[23:31] <jml> hi
[23:32] <barry> #startmeeting
[23:32] <MootBot> Meeting started at 17:32. The chair is barry.
[23:32] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[23:32] <barry> hi jml, thumper.  are you here?
[23:32] <thumper> here
[23:32] <jml> barry: like you wouldn't believe.
[23:32] <barry> not that i have a big agenda
[23:33] <barry> [TOPIC] agenda
[23:33] <MootBot> New Topic:  agenda
[23:33] <barry>  * Roll call
[23:33] <barry>  * Action items
[23:33] <barry>  * Mentoring update
[23:33] <barry>  * Peanut gallery (anything not on the agenda)
[23:33] <barry> [TOPIC] action items
[23:33] <MootBot> New Topic:  action items
[23:33] <barry> thumper: just one for you, an old one i think
[23:33] <barry>  * thumper to open bug on `webservice` pagetests globs problem
[23:33] <thumper> hmm
[23:33] <thumper> I don't recall doing it
[23:34] <barry> do you still want to? :)
[23:34] <thumper> I should do it
[23:34] <barry> i can keep it on the agenda
[23:35] <barry> [TOPIC]  * Peanut gallery (anything not on the agenda)
[23:35] <MootBot> New Topic:   * Peanut gallery (anything not on the agenda)
[23:35] <barry> you guys have anything?
[23:36] <thumper> bug 362032
[23:36] <thumper> I don't really have anything
[23:36] <barry> thumper: thanks
[23:36] <barry> jml?
[23:38] <barry> jml: i guess not
[23:38] <barry> i have one issue that came up today in a review:
[23:38] <barry>  * don't return unwrapped objects from view methods, barry and gary ("the fightin' arries!")
[23:39] <jml> back
[23:39] <jml> computer crapped out
[23:39] <barry> i agree with the principle.  gary wants to go further and prevent view modules from importing removeSecurityProxy
[23:39] <barry> jml: no worries
[23:39] <thumper> barry: what do you mean?
[23:39] <jml> what did I miss?
[23:39] <barry> jml: not much.  do you have any agenda items?
[23:39] <thumper> I disagree with not allowing removeSecurityProxy at all
[23:40] <thumper> but it's uses should be well defined
[23:40] <jml> just one re mentoring.
[23:40] <barry> thumper: can you state why?
[23:40] <barry> jml: we'll come back to that
[23:40] <thumper> not off the top of my head
[23:40] <thumper> I'd have to look at the situations where we use it
[23:40] <thumper> and why we did it that way
[23:41] <barry> thumper: think about it, you don't have to answer now
[23:41] <jml> barry: so, I'm not against adding a rule wrt removeSecurityProxy but...
[23:41] <jml> it's not going to help that much :)
[23:41] <barry> why not?
[23:41] <jml> two reasons
[23:42] <jml> for a start, it's actually really easy to return non-wrapped objects, particularly if they aren't db objects
[23:42] <jml> even without rSP
[23:42] <jml> the issue goes more deeply into the model code
[23:43] <jml> e.g. up until recently, all SourcePackage objects had no security proxy at all.
[23:43] <jml> second, the purpose of the importfascist is unclear
[23:44] <jml> and so a prohibition there will last exactly as long as it takes for people to need removeSecurityProxy in view code and to forget exactly why it is that we don't allow it.
[23:45] <barry> btw, fwiw, i think rSP in view code is fine under the right circumstances
[23:46] <jml> so, what are the reasons for not returning unwrapped objects from views?
[23:47] <thumper> I'm actually happy for "not returning unwrapped objects from views"
[23:47] <thumper> keep the unwrapped objects in a defined scope
[23:47] <barry> jml: it's a vague (to me) feeling that we could leak private data
[23:47] <thumper> however I'm against "don't allow the unwrapping of objects in views"
[23:48] <jml> barry: I think the real problem there is that it's difficult to audit any given page.
[23:49] <barry> jml: agreed.  thumper agreed
[23:49] <jml> barry: in some ways, rSP makes it easier to audit :)
[23:49] <barry> i'm definitely against unwrapping in model code.  so where else would you do it?  i don't like having to add an artificial layer in there
[23:49] <barry> jml: true
[23:50] <jml> so, I guess I'd say "whatever". We've already got quite a few well-intentioned for-your-own
[23:50] <jml> -good rules. One more won't break _this_ camel.
[23:51] <barry> jml: cool, this is an interesting discussion anyway.  we can move on and we'll bring it up at the next ameu
[23:51] <barry> [TOPIC] mentoring update
[23:51] <MootBot> New Topic:  mentoring update
[23:51] <jml> o hai
[23:52] <jml> stub's doing a great job, and I see no reason not to promote him.
[23:52] <barry> beauty.  i'll make it official, thanks
[23:52] <jml> np
[23:52] <barry> i think he's the last mentat atm
[23:53] <barry> well, that's all i've got.  anything else from you two?
[23:53] <thumper> nope
[23:53] <jml> I'm cool.
[23:53] <barry> #endmeeting
[23:53] <MootBot> Meeting finished at 17:53.
[23:53] <barry> thanks guys
[23:53] <jml> barry: thank you


[00:01] <Kano> well sent a mail, hopefully the file is added...
[00:02] <mathiaz> what's the process to get a specific changeset (included in 2.6.29) to be included in the jaunty kernel?
[00:38] <dtchen> mathiaz: request a pull; see the trailing vertical edge of https://wiki.ubuntu.com/KernelPatches
[00:38] <dtchen> mathiaz: ("How we will take it")
[00:41] <dtchen> mathiaz: see also https://lists.ubuntu.com/archives/kernel-team/2009-March/004942.html if you haven't already
[00:41] <mathiaz> dtchen: great. thanks.
[05:52] <Kamping_Kaiser> http://packages.ubuntu.com/search?keywords=linux-image-generic just noticed - hardy is the only release with the security/updates problem. (guess thats a good thing)
[11:48] <BUGabundo> good morning
[11:48] <BUGabundo> can I get help debuging sis191 kernel module?
[11:49] <BUGabundo> subsystem 0802
[14:05] <Kano> hi rtg ,did you read my mail about the missing dvb-s2 firmware
[14:06] <Kano> rtg: dvb-fe-cx24116.fw
[14:06] <Kano> it had instructions how to extract it
[14:06] <Kano> + checksum to verify
[14:15] <ogasawara> rtg: mathias has a cherrypick request - bug 353496
[14:15] <ubot3> Malone bug 353496 in linux "hpilo: open/close fix - commit c073b2db006ba9370be1eecc36a1be1d9ce31310 - included in 2.6.29" [Medium,Triaged] https://launchpad.net/bugs/353496
[14:32] <Leon_Nardella> I know this is not a support channel, but could somebody please point me at some wiki page on how I can inspect/debug/gather evidences on ext4 freezes in order to file a better bug report?
[14:56] <manjo> Leon_Nardella, launchpad.net
[14:57] <manjo> look at other ext4 bugs that are filed
[14:57] <manjo> should give you an idea what the developers are looking for in a bug report
[14:58] <Leon_Nardella> manjo: I already filed a bug, with ubuntu-bug's logs and  simple instructions on how I can reproduce it on my system.. I'm just looking for something more specific. Someone told to me to try kdb, but I think it's a little overwhelming for me.
[15:06] <manjo> what is the bug number ?
[15:07] <manjo> I am not an ext4 expert but I can advice on your bug report
[15:10] <Leon_Nardella> manjo: #353451
[15:10] <Leon_Nardella> I was researching on other other packages' bugs and I'm beginning to think it is somehow linked to that ext4 data loss bugs.
[15:11] <Leon_Nardella> If you read the comment, you'll see people actually having 2 problems. First was their system freezing with no apparent reason and then finding they lost data.
[15:12] <manjo> Leon_Nardella, are you able to ping the machine when it freezes ?
[15:13] <Leon_Nardella> manjo: That's a good question. Haven't tried that.
[15:13] <manjo> can you run top with 2sec updates and see which process is running when you see the freeze/hang ?
[15:13] <manjo> so run top his s and say .2
[15:13] <manjo> s/his/hit
[15:15] <Leon_Nardella> I'll try both things when I have access to my system again.
[15:15] <Leon_Nardella> What I can tell you is that absolutely nothing shows up in /var/log when it freezes and I can't kill X ( yeah, I know about dontzap )
[15:16] <manjo> I have ext4 on my laptop and I have experienced freezes when I over load the machine with a ton of IO load
[15:16] <manjo> but if might be useful to see if you kernel completely hung or if you desktop is frozen by pinging it
[15:17] <manjo> also find out what process is currently running
[15:18] <Leon_Nardella> manjo: Have you found a fix for your freezes?
[15:18] <manjo> no like i said I am not an ext4 expert ...
[15:18] <manjo> but ext4 is under active dev so some unstable behaviour is expected
[15:19] <Leon_Nardella> Indeed.
[15:37] <liw> I did some testing wrt #257790 and I can now get my disks to work. However, I don't know what I'm doing and the changes may break things for other people.
[20:55] <amitk> dtchen: updated bug #351924 with alsa-info
[20:55] <ubot3> Malone bug 351924 in pulseaudio "Sound stopped working after recent upgrade to Jaunty beta" [Undecided,Incomplete] https://launchpad.net/bugs/351924
[20:59] <manjo> I think there is a bug in the audio playback.. even when I mute flash is able to play sound
[21:00] <manjo> I have 32bit flash runinng under the wrapper
[21:00] <manjo> on 64bit


[01:40] <Unit193> https://lists.torproject.org/pipermail/tor-relays/2023-August/021292.html would you look at that?  U of M has a Tor relay but OSU notable seems to be lacking one!  Seems Michigan is better. :>
[12:06] <yano> uh-oh
[23:32] <dzho> you could beat them to the punch and put up a Veilid node
[23:36] <Unit193> Meh, "mobile first" :P


[11:03] <bdrung> @pilot in
[16:28] <bdrung> @pilot out
[17:00] <kanashiro[m]> @pilot in
[17:47] <krytarik> Btw, the topic should be updated to now say "Focal-Lunar" wrt support in #ubuntu
[17:55] <ahasenack> juliank: hi, around? What's up with the "lunar new" task in https://bugs.launchpad.net/ubuntu/+source/fwupd-efi/+bug/2011808 for fwupd-signed?
[17:55] -ubottu:#ubuntu-devel- Launchpad bug 2011808 in fwupd-signed (Ubuntu Lunar) "[SRU] [HWE] fwupd-efi/1:1.4-0ubuntu0.1 tracker" [Undecided, New]
[17:55] <ahasenack> and for mantic (main task), that is also in new?
[17:56] <juliank> ah
[17:56] <juliank> ahasenack: sorry forgot to include the LP entry in changelog in lunar
[17:56] <juliank> That got inherited to mantic
[17:56] <ahasenack> lunar has 1.52, same as mantic indeed
[17:57] <ahasenack> so released
[17:57] <ahasenack> ?
[17:57] <juliank> Yeah just fixed the state
[17:57] <juliank> Wrote the SRU bug after the upload to devel which was lunar at the time 🤷♂
[17:58] <ahasenack> juliank: another question: https://wiki.ubuntu.com/firmware-updates states some test cases in "Full QA Process across stable releases" that I don't think were run. Specifically, "fwupdmgr.sh in fwupd-tests deb", and the "dbus interface" paragraph, and the GUI portions in the last bullet point
[17:59] <ahasenack> I'm assuming this wiki page applies, because it's a version update, and not just patches
[17:59] <juliank> ahasenack: I am not aware of this page
[17:59] <ahasenack> the only release missing seems to be focal, on the other hand. THe rest was released
[18:00] <ahasenack> juliank: I got to it from https://wiki.ubuntu.com/StableReleaseUpdates#fwupd_and_fwupdate under "fwupd and fwupdate"
[18:00] <ahasenack> (ah, the link is direct already)
[18:01] <juliank> I brought the fwupd-efi bits into sync with the process for grub, as that's now all special
[18:02] <ahasenack> hm, so "fwupd" is not related to that page at all?
[18:02] <ahasenack> since the bug is about fwupd-efi and fwupd-signed?
[18:02] <ahasenack> I may be mixing them
[18:02] <juliank> fwupd-efi bits now have to go via ubuntu-uefi-team instead of OEM team
[18:02] <juliank> As we revamped signing and introduced a same signed binary across releases policy
[18:02] <juliank> Like signing goes via PPA now
[18:03] <juliank> I think we don't have proper SRU procedures for UEFI components
[18:04] <juliank> Anyway I think Microupdates to fwupd-efi probably need a different process than testing all the userspace components
[18:06] <juliank> Like we only changed the UEFI capsule helper so we only need to test OEM capsule support
[18:06] <juliank> Which was validated on a certified machine
[18:06] <ahasenack> this is 1:1.2-3ubuntu0.2 to 1:1.4-0ubuntu0.1, is that micro?
[18:06] <ahasenack> (for fwupd-efi in focal)
[18:06] <juliank> It was like a handful minor Bug fixes yeah
[18:08] <ahasenack> well, and NX
[18:08] <juliank> Yes but that's setting a bit in te binary
[18:09] <juliank> It's just saying it's NX compatible, not needing any work
[18:09] <juliank> https://github.com/fwupd/fwupd-efi/compare/1.2...1.4
[18:10] <ahasenack> any idea why focal was skipped on the 12th, this monday? Just forgotten?
[18:10] <ahasenack> all others were released
[18:11] <ahasenack> bionic I'm assuming will be left alone, so maybe we should add the block-proposed tag for it
[18:11] <ahasenack> leave it there for the esm people to pick it up whenever needed
[18:11] <juliank> bionic is the most important one really
[18:12] <juliank> We're still finishing the publishing of the shim update there
[18:12] <ahasenack> what does that mean?
[18:12] <juliank> Which depends on the fwupd-efi 1.4 because the previous is signed with the old key
[18:13] <juliank> So we fix that in the main archive but somehow it stalled again
[18:13] <juliank> I think sil2100 just ran out of time in the SRU shift when it came to focal
[18:13] <juliank> You need to release them, wait a publisher run, then release the next series or launchpad fails
[18:14] <juliank> Because fwupd-efi is binary copied and it was in publishing in one series
[18:14] <ahasenack> oooook :)
[18:14] <ahasenack> I think I'll leave this one alone then
[18:14] <ahasenack> too many moving parts I'm not familiar with
[18:21] <ahasenack> juliank: in https://bugs.launchpad.net/ubuntu/+source/gnu-efi/+bug/2011804, you say "We will test NX support when we work on the NX supported shim."
[18:21] -ubottu:#ubuntu-devel- Launchpad bug 2011804 in gnu-efi (Ubuntu Kinetic) "[SRU] [HWE] gnu-efi 3.0.15" [Undecided, Fix Committed]
[18:21] <ahasenack> does that mean this update depends on another one that hasn't landed yet?
[18:22] <ahasenack> or specifically fwupd-efi that we just talked about?
[18:22] <juliank> Well no the future shim update depends on those one
[18:22] <juliank> Well not strongly depends
[18:22] <juliank> But I mean no firmware that requires the NX bit is going to load fwupd if it can't load shim because that doesn't have the bit
[18:23] <ahasenack> well, fwupd-efi is already in kinetic-updates
[18:23] <juliank> Yeah it's fine
[18:23] <ahasenack> does this mean gnu-efi can now have an extra test, now that fwupd-efi with NX is in updates?
[18:24] <juliank> Oh gnu-efi should have been released with fwupd-efi because fwupd-efi built using it
[18:24] <juliank> But no we can't test NX yet because we need the shim
[18:25] <ahasenack> yeah, you called out something like this in the "other info" of fwupd-efi
[18:25] <ahasenack> no, "see also"
[18:25] <juliank> The gnu-efi update was done as a build-dep for the new fwupd-efi
[18:25] <ahasenack> next time perhaps call this out more specifically: update X needs to be landed at the same time, or something
[18:26] <ahasenack> but it's how I got to the gnu-efi bug, via your "see also" remark
[18:28] <ahasenack> so why are we releasing updates with a feature we cannot test yet? Why not do it after this new shim is available?
[18:28] <ahasenack> chicken-and-egg problem?
[18:29] <juliank> There were some other interesting fixes for hardware support in there
[18:30] <juliank> But mainly the goal is to ship signed components in the same version
[18:30] <ahasenack> I see, everybody got 1.51.1
[18:31] <juliank> You can go find FO100 specification, it specifies the signed boot asset policy I'm working on/with
[18:31] <juliank> But yes it probably should have a SRU policy page too
[18:32] <juliank> But the whole thing developed in a security update
[18:32] <ahasenack> such specs don't look like they are a light read
[18:33] <juliank> Anyhow I hope this addresses the questions, I do suggest leaving boot stuff to vorlon or sil2100 as they have more context
[18:33] <ahasenack> yep
[18:33] <juliank> I need to resume my EOD star trek snw watching, take 3 ;)
[18:34] <ahasenack> I might sign up for paramount+ just because of that. It used to be free with my broadband contract, but isn't anymore
[18:54] <vorlon> We grabbed a free trial of Paramount+ to binge Picard now that it's complete.  Our free 1-week trial turned into a free 2-month trial, because due to terrible UI I wound up accidentally starting trial accounts both on my desktop and on the TV, then tried to cancel the one from my desktop, so they offered me more free time
[18:54] <vorlon> (and the I was able to cancel the TV-only trial and link the TV to the other one)
[19:18] <ahasenack> I was wondering about waiting for all episodes to be available, and then get a trial
[19:18] <ahasenack> but if it's one week only, that would not be enough
[19:18] <sarnold> pick the right week? :)
[19:19] <ahasenack> at the very end, yeah
[19:19] <ahasenack> or just pay up one month, that's also not too bad
[19:19] <ahasenack> but waiting all this time is bad
[19:19] <ahasenack> (for snw)
[19:19] <ahasenack> I really enjoyed the 1st season
[19:19] <ahasenack> felt like ST back to its roots of exploration
[21:05] <kanashiro[m]> @pilot out
[21:57] <vpa1977> Hi, I am looking for a review and sponsorship of openjdk-21 early access merge. https://code.launchpad.net/~vpa1977/ubuntu/+source/openjdk-21/+git/openjdk-21/+merge/444680. All changes from Ubuntu were integrated in Debian, but I had to regenerate the control file to get the correct dependencies, so it is technically a merge. Thank you!!!!
[22:02] <robert_ancell> @pilot in


[00:15] <superm1> ScottK, looking at the debdiff between the two uploads, i highly doubt that is where the problem was introduced? http://launchpadlibrarian.net/22563445/libsdl1.2_1.2.13-4ubuntu1_1.2.13-4ubuntu2.diff.gz
[00:15] <superm1> i think that previous merge would be more likely to cause the problems
[00:19] <ScottK> superm1: OK.  Thanks for looking.  TheMuso uploaded that one, so maybe he'll look.
[00:20] <TheMuso> The OpenGL and sdl one? I really don't know what I should be looking for actually, everything looks sane to me when I glanced atht ehrules file the other day.
[00:29] <directhex> DktrKranz, braving the debian NM gauntlet, i see?
[00:31] <DktrKranz> directhex, yep
[00:31] <directhex> DktrKranz, who is your advocate?
[00:32] <DktrKranz> cedric
[00:34] <DktrKranz> and now, I'll get some sleep... boring day is just passed
[00:34] <directhex> the NM list is odd. ian murdock, the ian part of "debian", is stuck in NM since 2004?
[00:35] <DktrKranz> emeritous
[00:43] <ScottK> TheMuso: I'm not sure, but between the upload you sponsored and the one superm1 sponsored it seems to have gotten somewhat broken.
[00:49] <TheMuso> ScottK: Right. WIll have another look then.
[00:50] <ScottK> TheMuso: Thanks.
[00:56] <RAOF> Is the new DX notification daemon going to get significantly less crap at displaying notifications without actions associated, or is it time for me to start patching stuff?
[00:58] <directhex> RAOF, i fear how the new daemon will interact with banshee
[00:58] <RAOF> directhex: This is exactly the use-case I'm exploring now :)
[00:58] <Laney> It'll just mean the skip button will go away, right?
[00:59] <directhex> Laney, which will make me mad. grr, directhex smash!
[00:59] <RAOF> No.  It means that instead of a notification, a dialog pops up with "skip", "cancel", and "ok" buttons.
[00:59] <directhex> RAOF, no wai!
[00:59] <Laney> I'm assuming it gets patched
[00:59] <RAOF> This dialog isn't always on top, and hence is almost always not on top, due to focus-stealing prevention.
[00:59] <TheMuso> ScottK: Hrm interesting. It may be a Debian change that broke it. I'll have to dig up my merge diff to double check it to be sure that also wasn't the culpret.
[01:00] <Laney> ah, national anthem on the radio
[01:00]  * Laney hand on heart
[01:31] <TheMuso> SDL problem found, squashing a few bytesize SDL bugs while I'm at it.
[01:32] <directhex> yay TheMuso
[01:35] <RAOF> Alright motu-release!  The only thing between us and a working evolution-sharp package in Jaunty is a FFe ack.
[01:37] <ScottK> TheMuso: Great.  Glad to hear it.
[01:38] <ScottK> RAOF: What bug?
[01:38] <RAOF> https://bugs.edge.launchpad.net/ubuntu/+source/evolution-sharp/+bug/331858
[01:39] <RAOF> Should be a bit of a no-brainer, really.  evolution-sharp is totally broken at the moment.  I guess "working" after "not-working at all" is a bit of a featuer :)
[01:40] <ScottK> RAOF: Are you going to take responsibility for the rebuilds and how soon will they be done?
[01:41] <RAOF> I'll take responsibility for the rebuilds.
[01:41] <RAOF> They should be easy; I'll do them shortly after evolution-sharp clears NEW.
[01:43] <ScottK> OK.
[01:43] <ScottK> Ack from me then.  You need two.
[01:44] <RAOF> Yup.  Thanks.
[01:44] <RAOF> Any pet bugs you'd like fixed? :)
[01:46] <ScottK> I'd ask you to fix boost, but I've already got test builds started.
[01:49] <ScottK> RAOF: I guess if you'd go knock out a few from the sponsorship queue, I'd appreciate that.
[01:49] <RAOF> That's a good plan.  I've been meaning to do that for ages.
[01:54]  * ScottK notes that there are currently 890 Universe packages FBTFS in Jaunty if anyone is looking for something to do http://qa.ubuntuwire.com/ftbfs/#universe
[01:55] <RAOF> Um. We require 2 motu-sru acks before an SRU is approved, yes?
[01:56] <RAOF> The wiki page doesn't actually appear to contain this information.
[01:56] <ScottK> Dunno about SRU.
[01:57] <ScottK> My suggestion would be upload it an let them decide.
[01:57] <ScottK> By that's probably totally wrong.
[01:57]  * ajmitch wonders how many of those are FTBFS on the main release architectures
[01:58] <ScottK> ajmitch: Mostly not, but enough for people to keep busy.
[02:00]  * ajmitch sees a lot of spurious armel failures there
[02:00] <ScottK> Yep
[02:00] <ScottK> There's a lot on sparc and ia64 that just needs a retry too.
[02:00] <ajmitch> eg last-exit failed to build because udev couldn't be installed in the build chroot
[02:01] <ScottK> Still some on powerpc too altough I managed to clear up a lot of powerpc the list time the buildd's were quiet.
[02:02] <ajmitch> RAOF: you'll be disappointed to see that xserver-xorg-video-nouveau failed to build on HPPA :)
[02:02] <RAOF> ajmitch: I'm crushed.
[02:03] <ajmitch> can you even use nvidia cards with those?
[02:03] <RAOF> Probably not.
[02:06] <TheMuso> ScottK: Will probably take a ook at powerpc FTBFSs at some point.
[02:06] <TheMuso> look
[02:06] <TheMuso> And sparc should be fixed by tomorrow, got a ports kernel upload coming tonight hopefully, my time.
[02:07] <TheMuso> for glibc/qt4-x11 and anything else depending on endianness.
[02:07] <ScottK> TheMuso: I've been gradually working on sneaking in retries of stuff that died when the ports kernels were all broken.
[02:07] <TheMuso> ScottK: cool.
[02:07] <ScottK> I think on powerpc almost anything in Main has some real problem.
[02:07]  * RAOF hasn't been doing particularly well with the sponsors queue.  A bunch that weren't meant to be sponsored, and now vnc4 hasn't built since Hardy.
[02:07] <ScottK> That's great news about sparc.
[02:08] <ScottK> TheMuso: IA64 seems to be healthy too, just needs time to catch up.
[02:08] <TheMuso> ScottK: Yeah.
[02:09] <ScottK> About 36 hours ago I noticed the powerpc buildd's were idle so I went to find something to retry.  While I was doing that two uploads got done.  That retry still hasn't happened.
[02:12]  * ajmitch wonders what should be done about packages that have FTBFS since hardy
[02:14] <TheMuso> ScottK: lol
[02:14] <TheMuso> I think my weekends are the best time, most devs are asleep, and those of us in a similar timezone to myself are either doing something else, or aren't always donig uploads etc.
[02:14] <TheMuso> I remember last weekend I retried several packages on various arches in main, plan to do the same this weekend.
[02:15] <ScottK> I had similar luck myself.
[02:35]  * TheMuso shakes his head at libsdl. It doesn't even link directly to the X libs, it dlopens them. :S
[02:35] <TheMuso> At least thats how it gets built.
[02:36] <TheMuso> Although that does make sense in terms of non-X systems wanting to use it.
[02:40] <TheMuso> SDL would be better off having a plugin system, which probably already exists in the post 1.2 branch upstream anyway.
[05:28] <dholbach> good morning
[06:01] <fabrice_sp> Good morning
[06:13] <iulian> Morning dholbach, fabrice_sp.
[06:13] <fabrice_sp> morning iulian!
[06:14] <fabrice_sp> morning dholbach also
[06:14] <fabrice_sp> :-)
[06:14] <dholbach> hiya iulian, hi fabrice_sp
[06:15] <fabrice_sp> by the way, one question: now that we are in FF, a merge that hasn't been sponsored before, has to follow the FFe process? (it's for Bug #247591)
[06:17] <ScottK> yes it does
[06:17] <fabrice_sp> ok. Will do then. thanks
[06:51] <Laibsch> Is this a good place for questions about pbuilder-dist?  I tried #pbuilder but that does not seem to exist anywhere.
[06:56] <ScottK> Probably.
[07:16] <Laibsch> I want to backport a package X (for personal use), which relies on debhelper 7.   Although I re-compiled debhelper 7 first, it does not seem to find it.  How do I include previously built packages in those available to subsequent builds?
[07:16] <Laibsch> Same question goes the other way round, too, of course.  How to exclude so to make sure a package succeeds a build from scratch
[07:59] <tonyyarusso> What is the function of 'make clean' exactly?
[08:02] <Flannel> tonyyarusso: It removes all packages from /var/cache/apt/archives/
[08:02] <Flannel> oh, make clean!
[08:02] <Flannel> hah
[08:02]  * Flannel runs away.
[08:04] <tonyyarusso> Way to read Flannel :P
[08:04] <Flannel> quiet.
[08:04]  * jussi01 points and laughs at Flannel (yes... Im everywhere) :P
[08:05] <Flannel> jussi01: I'm everywhere-er!
[08:11] <dholbach> tonyyarusso: it removes files that are created automatically during the build process (like the compiled binaries, etc.)
[08:11] <tonyyarusso> dholbach: ah, ok
[08:11] <tonyyarusso> any of you guys have an AIM account and want to help me test something?
[08:11]  * tonyyarusso compiled without SSL, so that's the only protocol that works - whoops.
[08:14] <tonyyarusso> Also, how do you build a package with a configure script?  I'm used to using 'debuild -S -sa' and then 'sudo pbuilder build *.dsc', but debuild requires the ./configure to have run first.  However, it appears that script is run within debian/rules, so is all automatic if I can figure out the invocation properly.
[08:17] <liw> tonyyarusso, debian/rules must invoke the configure script in some way; if you use cdbs, one of the magic includes will do that for you; if you don't use cdbs, you need to write your own build target and call ./configure from there
[08:17] <tonyyarusso> liw: debian/rules does invoke the configure script.  I just am not getting to the point of letting debian/rules do it's thing.
[08:18] <tonyyarusso> oh, wait - I think it's because I was missing some helper scripts.  nvm
[08:23] <tonyyarusso> Do all Ubuntu changes go in debian/patches/, or do some touch the bulk of the source?  (how does that directory compare to the rest, and under what circumstances should changes go there)
[08:24] <geser> tonyyarusso: it depends if the package uses a patch system or not
[08:25] <tonyyarusso> geser: It does, CDBS with something.  (pidgin)
[08:25] <pmjdebruijn> tonyyarusso: then patches should go under debian/patches
[08:25] <tonyyarusso> simple-patchsys apparently
[08:25] <tonyyarusso> okie dokie
[08:26] <geser> so patches to the source should go there while you can change files in debian/ directly
[08:27] <dholbach> what-patch (in ubuntu-dev-tools) FTW!
[08:28] <tonyyarusso> just found that - cool beans
[09:27] <`6og> hi all. I want to rebuild the hardy kernel packages to see if the packages in -security will build without -updates. Any clues how i could do that?
[09:28] <soren> Try it in a PPA. You can configure it to only use -security.
[09:30] <`6og> soren, i'll investigate that, thanks.
[09:51] <tonyyarusso> What are some reasons a patch would fail to apply during 'pbuilder build'?
[09:52] <savvas> tonyyarusso: usually when the original file that you are patching changes
[09:53] <tonyyarusso> savvas: ah, possibly due to another patch for instance?
[09:53] <geser> or you try to patch a already patch file while the patch is against the unpatched version
[09:54] <geser> tonyyarusso: might also be due to changes upstream
[09:54] <savvas> true, like my problem yesterday with boost1.35 :P
[09:54] <tonyyarusso> geser: Can't be upstream - I haven't changed versions.
[09:54]  * tonyyarusso greps for patches touching the same file
[09:55] <tonyyarusso> well that's not it...
[09:56] <tonyyarusso> I wish the error was more descriptive - all it says is "Trying patch debian/patches/75_pounce-options-enhance.patch at level 1 ... 0 ... 2 ... failure."
[09:56] <savvas> tonyyarusso: source link?
[09:57] <tonyyarusso> savvas: to what, the patch?
[09:57] <tonyyarusso> http://paste.ubuntu.com/120522/
[09:57] <geser> tonyyarusso: try to manually apply the patch (with patch) so you see the exact messages
[09:57] <savvas> patch and the debian source if you have them :)
[09:57] <savvas> ah pidgin
[09:57] <tonyyarusso> yeah
[09:58] <tonyyarusso> oh, nvm - everyone ignore me...
[09:58] <savvas> tonyyarusso: hardy?
[09:58] <tonyyarusso> I left changes in the source tree from generating said patch, 'cause it's 4am and I'm an idiot.
[09:58] <tonyyarusso> savvas: for now yes
[09:59] <savvas> oh, so problem fixed :)
[10:00] <tonyyarusso> Let's try this again...
[10:04] <tonyyarusso> savvas: btw, what was relevate about asking if it was hardy?  (I ask so I know what I need to change to do this for jaunty as well)
[10:04] <tonyyarusso> *relevant
[10:05] <savvas> I just wanted to know which source package you are using :)
[10:05] <tonyyarusso> ah
[10:05] <savvas> I saw 2.4.1 in the patch
[10:05]  * tonyyarusso hopes not much has changed in this part of the package so I don't get any surpriseds
[10:07] <tonyyarusso> savvas: btw, if you know anything about pidgin, I figured out how to do what I want in GTK, but I have no idea how to do it in GNT for finch, since GNT doesn't seem to have a radio button feature, only checkboxes that aren't mutually exclusive.
[10:08] <savvas> nope, still learning packaging, sorry :P
[10:11] <savvas> geser: I'm trying to make all boost (1.34) packages move to boost1.35 - I should patch so that packages such as libboost-filesystem-dev in boost (1.34) is renamed as libboost-filesystem1.34-dev, right?
[10:12] <savvas> or if anyone else knows :)
[10:12] <incorrect> hopefully backporting bdb 4.7 will fix openldap replication issues
[10:24] <geser> savvas: I wouldn't rename them, better would be to get rid of boost 1.34 if possible, we have 1.35 and 1.37 in archive too
[10:25] <savvas> geser: so I should just work on boost1.35?
[10:27] <geser> what are you trying to accomplish? it's not really clear to me right now
[10:28] <savvas> geser: sorry, hold a sec
[10:28] <savvas> $ sudo apt-get install libboost-filesystem-dev
[10:28] <savvas> The following packages have unmet dependencies: libboost-filesystem-dev: Depends: libboost-dev (= 1.34.1-15ubuntu1)
[10:29] <geser> works here: jaunty on amd64
[10:31]  * savvas updates
[10:31] <savvas> oooh.. now I see
[10:32] <savvas> I already had libboost-filesystem1.37-dev hehe
[10:32] <savvas> aptitude makes it a bit more clear :)
[10:34] <savvas> thanks!
[10:43] <ahasenack> hi, does anybody have an example of a postinst script that detects whether it's the first installation of a package?
[10:43] <ahasenack> I have a package with a hourly cron job whose start time I want to randomize at install time
[10:43] <ahasenack> but I don't want to touch it in upgrades
[10:44] <ahasenack> I wouldn't want to use something as a macro (@RANDOM@) in the cron.d file and sed it in postinst because there is a window of time where the @RANDOM@ would be there, thus making the cron.d file invalid during that amount of time
[10:46] <soren> ahasenack: if $1 is "configure" and $2 is empty or undefined, then it's the first install.
[10:46] <savvas> ahasenack: you could check if the file  in cron.d exists
[10:46] <savvas> oh
[10:46]  * savvas notes :P
[10:47] <ahasenack> soren: thanks
[10:47] <soren> ahasenack: If $1 is "configure", $2 contains the version from whence you're upgrading.
[10:47] <savvas> soren: is dpkg --compare-versions used in that case?
[10:48] <Toadstool> ahasenack: if [ ! -e $file ]; then TMP=`mktemp` ; … ; mv $TMP cron_location fi also works
[10:48] <Toadstool> hi everybody
[10:48] <soren> savvas: You can use dpkg --compare-versions to compare $2 to a known version string to determine if you need to do certain things during this particular upgrade, yes.
[10:48] <ahasenack> Toadstool: thanks too
[10:48] <savvas> cool
[10:49] <geser> Toadstool: wouldn't that overwrite an admin decision to rm that cron.d file on  upgrades?
[10:49] <soren> savvas: If, for instance, a configuration file moved in version 1.2-4ubuntu2, you can do "if dpkg --compare-versions "$2" -lt 1.2-4ubuntu2; then mv <old path> <new path> ; fi" or something like that.
[10:51] <soren> savvas: What would belong in the preinst, though.
[10:51] <Toadstool> geser: hmm, well yes, good point
[10:51] <savvas> thanks soren :)
[10:53] <Toadstool> geser: that could be worked around using ucf, though...
[10:54] <soren> Toadstool: ucf is a completely different kettle of fish, though :)
[10:54] <Toadstool> agreed :)
[10:57] <ahasenack> hmm, can't use $RANDOM with /bin/shj
[10:57] <ahasenack> sh
[11:02] <soren> Right, it's a bash thing.
[11:04] <savvas> is there a special section for virtual packages / meta packages?
[11:07] <slytherin> savvas: metapackages? I believe ubuntu-restricted-extras uses it.
[11:09] <savvas> thanks
[11:19] <ScottK> DktrKranz: Are you around?
[11:39] <savvas> is there a standard policy for dummy packages? e.g. description one-line or the detailed one?
[11:43] <sistpoty|work> hi folks
[11:47] <slytherin> savvas: What do you mean by dummy packages? Transitional packages?
[11:47] <slytherin> NCommander: around? have question about a build failures on sparc.
[11:47] <savvas> slytherin: yes, transitional dummy packages
[11:48] <slytherin> savvas: I don't think the description of transitional packages are treated any different way.
[11:48] <savvas> ok thanks :)
[12:04] <incorrect> yay! libdb 4.7 backported to hardy
[12:09] <slytherin> wow, openjdk build on armel is sure blocking other builds. :-)
[12:10] <directhex> slytherin, yeah..... how much RAM do the buildds have?
[12:10] <slytherin> directhex: I am not sure this is RAM problem.
[12:11] <directhex> slytherin, well, it can't help... if it needs ram into the gigs, and has barely any ram, then all the swapping won't speed it up
[12:12] <slytherin> directhex: looks like the last successful build of openjdk also took two days, and that was on another server.
[12:13] <directhex> slytherin, does it work well on arm?
[12:14] <slytherin> directhex: no ides, I don't have an armel machine. You should ask NCommander if he has one.
[12:14]  * NCommander has a few ...
[12:15] <slytherin> NCommander: how many different ports do you have?
[12:15] <slytherin> I mean archs
[12:15] <directhex> i still can't see mention of NCommander without the electric six song "dance commander" running through my head
[12:15] <NCommander> slytherin, I got a MIPS, a few ARMs, PowerPC, x86, amd64, lpia
[12:15] <NCommander> my sh4 is MIA
[12:16] <slytherin> that is a long list. :-)
[12:16] <\sh> guys, what do we need to sync a package from debian, during FF? especially security stuff (uw-imap)
[12:16] <slytherin> \sh: if it is bug fix only then no FFE is needed.
[12:17] <\sh> slytherin: so just a sync request on LP
[12:17] <directhex> NCommander, you can give the moonlight plugin a shot on them now, if they run jaunty ;)
[12:22] <NCommander> Microsoft compiled their codecs for ARM?
[12:29] <directhex> NCommander, nay. built against ffmpeg
[12:29] <directhex> NCommander, but i've been told by upstream that if they CAN build them (ie.. have a working build environment) then they'll add any arch people ask for
[12:29] <NCommander> Upstream as in Microsoft?!
[12:29] <directhex> as in novell
[12:30] <NCommander> oh
[12:30] <directhex> the binaries are hosted on microsoft.com, but the builds are done by novell
[12:30] <NCommander> so Novell has MS's codec code O__o;
[12:30] <NCommander> wow ....
[12:30] <NCommander> I'm suprised that ever leaves Seattle
[12:34] <directhex> i doubt MS want the arseache of doing it themselves
[12:34] <directhex> they're just hosting the binaries & paying the mpeg-la fees
[12:44] <fransman> that got to be a remote sever at the Microsoft campus Novell is working on
[12:47] <directhex> fransman, well, no, hence the request for build servers (or tips for making qemu work)
[12:50] <slytherin> NCommander: do you think you can take a look at a build failure on sparc and provide some insight?
[12:51] <NCommander> slytherin, the kernel on sparc is extremely broken ATM
[12:51] <NCommander> We have a kernel upload pending to fix it, and then glibc needs to be retried, which should make most of the stranger build failures go away
[12:51] <slytherin> NCommander: hmm, that could be reason. I saw some error in one of the linux header files.
[12:51] <slytherin> So I will ignore the error for now and will do rebuilds later.
[12:54] <stefanlsd> dholbach: for the 5-a-day stuff, all we need to do now is join the team?
[12:54] <dholbach> yes
[12:54] <dholbach> and add yourself to https://wiki.ubuntu.com/Bugs/Events
[12:54] <dholbach> the stats are not quite ready yet but should be soon
[12:54] <dholbach> nothing will be lost :)
[12:55] <nhandler> What team has the ability to modify http://www.ubuntu.com/community pages? http://www.ubuntu.com/community/processes/techboard is out of date
[12:58] <stefanlsd> dholbach: does it rely on the  LP id's being on that page?
[12:58] <dholbach> stefanlsd: yep, just for the bug jams
[12:58] <stefanlsd> dholbach: aah ok. will do
[12:59] <dholbach> super
[12:59] <james_w> nhandler: bugs on ubuntu-website are the preferred way to report those sorts of issues I believe
[13:01] <nhandler> james_w: Ok, thanks a lot. I'll file the bug when I get back home later.
[13:18] <fransman> savvas: why do we need, what got to be his task, the contact person you can't riches for some week for flumotion?
[13:19] <Vest84> mok0: hi, do you have a free time to review my project again? I've fixed it: http://revu.ubuntuwire.com/details.py?package=gnome-quod
[13:20] <mok0> Vest84: I will take a look later, busy right now
[13:20] <Vest84> ok, thank you in forward
[13:21] <fransman> savvas: talking about bug 319204 btw
[13:22] <DktrKranz> ScottK: yes
[13:23] <ScottK> DktrKranz: I had sent you mail about the Ubuntu Release meeting today, but sistpoty|work said he'd cover it, so no worries.
[13:23] <directhex> DktrKranz, how does that changelog i posted to the md2 bug look?
[13:24] <DktrKranz> ScottK: cool. I can eventually attend too
[13:27] <DktrKranz> directhex: I plan to look at them at a whole tonight (so I can finally install MD2 \o/)
[13:29] <savvas> lool: any update on flumotion - debian? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=473781
[13:30] <lool> savvas: So first, 0.4.x was supposed to be a stable series and 0.5.x a devel series leading to 0.6
[13:30] <lool> I believe 0.5.x would now be more easy to work with than 0.4 though
[13:31] <lool> savvas: Second, updating packages like flumotion is very time consuming if you try to get the Depends right; it's usually easy to get it working, but ensuring that you have the proper depends for any Python module that the code might use less so
[13:32] <lool> And apart of that, I had no time nor interest in working on flumotion while lenny was frozen, now would be more interesting though
[13:33] <savvas> fransman: ^ :)
[13:33] <savvas> lool: ok thanks, if you need help, I could try out and minimize the usage of packages in Depends
[13:35] <lool> I don't know; I can think of two time consuming ways to do things right; alternatively I don't care if someone picks up the package, removes my name from it, and does it empirically
[13:45] <_ruben> slightly offtopic, but does anyone has a decent Makefile syntax reference?
[13:48] <soren> _ruben: "info make"?
[13:50] <fransman> lool: have you seen [link] because they uses them self for pbuilder
[13:50] <fransman> https://code.fluendo.com/flumotion/trac/browser/flumotion/trunk/pkg
[13:51] <lool> They started it from my packages
[13:51] <fransman> https://code.fluendo.com/flumotion/trac/wiki/PbuilderUbuntu
[13:51] <fransman> ok i didn't know
[13:51] <_ruben> ah .. that brought me to "the gnu make manual" .. which seems to a very decent doc
[14:21] <DktrKranz> nhandler: I just sent a mail to MC to formally add you to motu-release team
[14:24] <kpirc> I am looking for a reviewer for my 'cadabra' package on REVU. Any takers?
[14:24] <directhex> woo for nhandler?
[14:24] <directhex> kpirc, which language is it in?
[14:24] <kpirc> directhex: C++
[14:24] <directhex> pass
[14:27] <stefanlsd> dholbach: is that tag anything special?  gbj-za-0902 , or gbj-johannesburg-0902?
[14:27] <dholbach> stefanlsd: should be all fine - just pick anything similar to the others on Bugs/Events
[14:28] <dholbach> stefanlsd: talk about it on  #ubuntu-bugs ?
[14:28] <stefanlsd> dholbach: kk
[14:28] <stefanlsd> oh right :)
[14:28] <dholbach> stefanlsd: that's where the bug and bug jam action is going on :)
[14:43] <bddebian> Heya gang
[14:49] <geser> Hi bddebian
[14:49] <bddebian> Heya geser
[14:55] <slytherin> persia: I wonder why netbeans has not yet cleared the queue
[15:20] <sistpoty|work> siretart: new faucc on spooky:~sistpoty/faumachine
[15:27] <siretart> sistpoty|work: what about faumachine? unchanged?
[15:27] <sistpoty|work> siretart: just adding the versioned build-dep there, give me a minute please ;)
[15:28] <siretart> ok. building faucc...
[15:32] <sistpoty|work> siretart: thanks... faumachine is now also on spooky
[15:36] <siretart> sistpoty|work: building...
[15:37] <sistpoty|work> siretart: thanks! (crossing thumbs that this indeed fixes it on i386)
[15:38] <MaduserTr> Is there a way to have a debian/watch where the version is not in the href?
[15:43] <siretart> sistpoty|work: well, it seems that at least as no longer exists with exit code 1 :-)
[15:43] <siretart> still building though...
[15:43] <savvas> transitional dummy packages have 'Architecture: all', right?
[15:43] <sistpoty|work> siretart: :) (and yes, it does take ages :/)
[15:45] <savvas> MaduserTr: no, not usually - in such cases, it's good to contact the administrator or the author to create uwatch-friendlier links :)
[15:46] <savvas> MaduserTr: can you show us the link and the debian/uwatch file you have?
[15:46] <MaduserTr> The link is http://josm.openstreetmap.de/tested
[15:47] <MaduserTr> and they changed because of trafik some days ago, (before it was a link)
[15:48] <savvas> MaduserTr: you could use get-orig-source in the debian/rules - but I have never tried it
[15:48] <MaduserTr> savvas: thanks i will search and try
[15:50] <savvas> MaduserTr: https://wiki.ubuntu.com/PackagingGuide/Examples/ChangingTheOrigTarball
[16:01] <orci> I remember reading somewhere that Shuttleworth made a comment that the desktop is not viable for ubuntu. Does this mean that Ubuntu will aim servers primarily in the near future?
[16:02]  * RainCT has just bought an ubuntu certified PC.. the sticker looks nice :)
[16:03]  * directhex certifies his laptop for ubuntu directhex edition
[16:03] <RainCT> 150€ box.. works like a charm :)
[16:05] <sistpoty|work> thanks siretart, just got the accepted mail :)
[16:07] <siretart> :)
[16:07] <__iron> hi RainCT
[16:07] <__iron> just time for pm
[16:07] <__iron> ?
[16:11] <RainCT> Hi __iron
[16:11] <RainCT> Sure
[16:14] <orci> sorry wrong channel?
[16:14] <__iron> orci: try #ubuntu
[16:16] <orci> __iron, unfortunately #ubuntu is useless most of the time. But thanks, I'll try another channel
[16:16] <__iron> motu is dev-channel
[16:16] <DktrKranz> dholbach: hi, mind adding nhandler to motu-release team? See also https://lists.ubuntu.com/archives/motu-council/2009-February/002029.html
[16:18] <dholbach> DktrKranz: I'm not on the MC
[16:19] <dholbach> soren: ^ can you help there?
[16:19] <soren> dholbach: hm?
[16:19] <soren> Oh.
[16:19] <soren> Er.. Sure.
[16:19] <DktrKranz> dholbach: oh... already dropped your role?
[16:20] <dholbach> the TB and CC are still discussing the MC election
[16:20] <soren> DktrKranz, dholbach, nhandler: Done.
[16:20] <dholbach> DktrKranz: so I can lay back and let soren do the work
[16:20] <soren> dholbach: We miss you! :)
[16:20] <dholbach> already?
[16:21] <soren> Since before you left, dude.
[16:21]  * DktrKranz hugs soren and hugs dholbach for past, awesome, MC work
[16:21]  * dholbach hugs y'all back :)
[16:21] <dholbach> The Ubuntu Community - where hugging comes first!
[16:22] <dholbach> :-D
[16:22] <DktrKranz> dholbach: do you miss mass-hugs, don't you? Be prepared for next UDS ;)
[16:22] <dholbach> :-)
[16:22] <dholbach> DktrKranz: it's much more fun if you don't prepare :)
[16:23] <DktrKranz> heh
[16:35] <savvas> what was that file that they list packages and architectures that are blocked from being built?
[16:35] <savvas> I remember seeing it somewhere online on debian.org
[16:38] <soren> savvas: http://buildd.debian.org/quinn-diff/Packages-arch-specific
[16:40] <maxb> soren, savvas: btw, Soyuz currently uses an out-of-date version
[16:41] <soren> maxb: How can you tell?
[16:41] <savvas> maxb: I got a heavy lag for some reason, did any reply to my question?
[16:41] <soren> 16:38:59 < soren> savvas: http://buildd.debian.org/quinn-diff/Packages-arch-specific
[16:41] <savvas> 17:35:23 < savvas> what was that file that they list packages and architectures that are blocked from being  built?
[16:41] <savvas> cool, thanks soren :)
[16:41] <soren> Sure.
[16:41] <maxb> soren: by asking the admins on #launchpad
[16:42] <maxb> bug 316579
[16:42] <soren> maxb: Just now?
[16:42] <maxb> back when I filed that bug
[16:42] <soren> maxb: That's useful info. Thanks.
[16:42] <maxb> fortunately it appears milestoned for a fix soon
[16:59] <savvas> hm.. %i8kutils: i386							      # Dell (i386) laptop utils
[17:03] <iulian> (removed the MOTU meeting part)
[17:04] <iulian> The next meeting was TBD so we don't want to have it in the topic if we didn't schedule one.
[17:11] <savvas> looks like i8kutils can be built on amd64 as well: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=480938
[17:12] <stefanlsd> Karmic Koala
[17:12] <stefanlsd> hehe
[17:15] <savvas> Grumping Groundhog? :p
[17:16] <kpirc> I need a reviewer for my 'cadabra' package on revu. Any takers? (it's a computer algebra system)
[17:33] <phaidros> hi, can I tell prevu to use a different arch then the host system?
[17:35] <RainCT> yay, UDS in Barcelona :)
[17:47] <iulian> Karmic... sounds cool :)
[17:47] <phaidros> any hints on setting arch with prevu?
[17:48] <phaidros> I want to backport x86 packages on an amd64 host ..
[17:48] <phaidros> is that doable ?
[17:54] <loic-m> phaidros: should be ok as long as they don't use assembler code
[17:54] <loic-m> Don't know much about prevu though
[17:55] <maxb> prevu's mostly a simple frontend for pbuilder. If you're getting into that sort of advanced territory, you probably want to use pbuilder directly (or better still cowbuilder)
[17:59] <jdong> phaidros: you can use a linux32 chroot
[17:59] <RainCT> or pbuilder-dist/cowbuiler-dist :)
[17:59] <jdong> other than that, no, prevu doesn't have built-in support for i386 pbuilders on amd64.
[18:00] <slytherin> geser: just FYI ... libjboss-buildmagic-java really seems to have circular build dep.
[18:05] <phaidros> jdong: thanks.
[18:22]  * sistpoty|work heads home... cya
[18:57] <savvas> oops, I think I made a mistake with bug #190247 - we aren't supposed to touch the status once sponsors are subscribed, right?
[18:57] <savvas> I subscribed ubuntu-main-sponsors and then set it as "in progress"
[18:59] <slytherin> khashayar: there? I have question about celt.
[19:23] <goshawk> hi
[19:28] <RainCT> hi :)
[19:59] <weboide> Hi, what can I do (except hit my head with my keyboard) when there's already a package with the same source name in the repos as the package I'm working on?
[20:03] <slytherin> weboide: which package is that?
[20:04] <weboide> slytherin: I'm working on eina (a music player) and in debian experimental there is source package eina already.
[20:04] <weboide> slytherin: eina (debian) is a lib.
[20:05] <slytherin> weboide: you rename your package to something like eina-player
[20:05] <slytherin> weboide: meanwhile make sure upstream knows that they are using and already used project name
[20:05] <weboide> slytherin: that's what I thought but there would be issues with the directory name in the orig.tar.gz, would I have to rename that too?
[20:06] <weboide> slytherin: the best way is that upstream changes the name...
[20:06] <weboide> slytherin: right?
[20:06] <slytherin> weboide: yes
[20:07] <weboide> slytherin: but the thing is it seems that the debian eina appeared afterwards...
[20:07] <slytherin> weboide: have you checked first release dates for both projects?
[20:09] <weboide> slytherin: no, but I am now. Debian eina appears to be Enlightenment libraries.
[20:10] <a|wen-> savvas: AFAIK you should make sure it is set to confirmed, with no assignee when subscribing ubuntu-*-sponsors
[20:11] <savvas> a|wen-: ok, I'll set it back now
[20:29] <slytherin> slomo: gst-plugins-ugly-multiverse0.10 source is nothing but a copy of gst-plugins-ugly0.10 source, right?
[20:29] <weboide> slytherin: ha, I found eina (player) back in 2004!
[20:29] <slytherin> :-)
[20:41] <andersk> I have a debdiff for Intrepid's open-vm-tools that fixes bug 289921, bug 306835, and bug 302226.  Should I keep adding fixes to the one debdiff, or do I need to post separate debdiffs for each bug?
[20:42] <sistpoty> andersk: one debdiff is preferred
[20:43] <andersk> Great.  Thanks.
[20:47] <silas428> Is C essential to developing for Ubuntu, or can I use other languages?
[20:48] <mrooney> silas428: it is not at all! many desktop things are done in Python
[20:48] <mrooney> and if you are writing your own app, you can use pretty much anything
[20:48] <mrooney> C#, Vala
[20:48] <silas428> My programming skills aren't good enough to program my own apps
[20:48] <silas428> How about fixing bugs etc?
[20:48] <DaSkreech> Hello
[20:49] <mrooney> silas428: for fixing bugs, you will just be limited to fixing non-C bugs
[20:49] <silas428> mrooney: where can I find some python desktop things? I have done some reading on python
[20:49] <DaSkreech> Is there any chan for the Aluetian islands?
[20:49] <mrooney> silas428: however looking at bitesize C bugs might be on your level and could help you learn
[20:50] <silas428> Do the intro programming books help any for fixing bugs?
[20:50] <silas428> or learning to fix bugs
[20:50] <DaSkreech> I don't think there are any for the chukcha language
[20:51] <mrooney> silas428: I'd check out https://wiki.ubuntu.com/UbuntuDeveloperWeek
[20:51] <mrooney> for example the second Wed talk
[20:52] <mrooney> also https://wiki.ubuntu.com/UbuntuOpenWeek is likely to be helpful
[20:54] <silas428> thanks
[20:55] <DaSkreech> I've never even heard of chukcha before :-(
[21:47] <Vest84> guys, I've found in the internet the next lines: Clutter and Cluttermm packages are probably available from your Linux distribution. For instance, on Ubuntu Linux or Debian you can install the libcluttermm-0.9-dev package But there is no packages with this name in packages.ubuntu.com
[21:47] <Vest84> do you know they exist?
[21:50] <rexbron> tseliot: Is there a particular reason why the dontzap class is part of the cli gui?
[21:50] <rexbron> or cli interface rather
[21:56] <tseliot> rexbron: what's the problem?
[21:59] <tseliot> rexbron: the methods in that class are used to talk to kubuntu's control panel (which is written in C++)
[22:09] <rexbron> tseliot: Ubuntu Studio is looking at disabling the dontzap option by default and want to provide a gui method to enable it if users so desire. Since dontzap is written in python and so is ubuntstudio-controls, I was looking at calling the dontzap methods directly from there  rather than creating a subshell
[22:13] <tseliot> rexbron: you can copy that class then and depend on python-xkit.
[22:13] <tseliot> The implementation in Kubuntu calls it from the command line and it works well though
[22:14] <tseliot> the Python class is only a few lines
[22:17] <directhex> Vest84, not in the archive - even jaunty has only 0.8
[22:19] <Vest84> directhex: so, you mean the information is wrong?
[22:19] <directhex> Vest84, seems so.
[22:19] <Vest84> take a look please
[22:19] <Vest84> http://www.openismus.com/documents/cluttermm_tutorial/0.9/docs/tutorial/html/sec-installation.html
[22:20] <Vest84> directhex: what do you think ab. it?
[22:21] <rexbron> tseliot: I'm pushing a branch that has DontZap factored out as a module and has the dontzap script import it
[22:22] <RainCT> ScottK-desktop or some other Kubuntu guy: in Jaunty there is no system-config-printer-kde executable anymore. I guess this is normal and now it can only be launched from some control panel?
[22:23] <ScottK> RainCT: I don't recall.
[22:23]  * ScottK looks at JontheEchidna.
[22:23] <JontheEchidna> It's launchable from System Settings now
[22:24] <tseliot> rexbron: ok, I'll have a look at it ASAP (it's night here)
[22:24] <JontheEchidna> It's in the Advanced tab iirc
[22:24] <RainCT> Okay, thanks. Just to be sure that it isn't missing :)
[22:25] <rexbron> tseliot: I hope I'm not misunderstanding you but asap usually refers to very quickly and I think you are implying "when I can"
[22:25] <JontheEchidna> It might be better placed in the Computer Administration section instead of the System section in the advanced tab..
[22:25] <nemo> what the heck happened to libsdl-net1.2-dev in jaunty?
[22:25] <nemo> and libsdl-net1.2 for that matter
[22:27] <rexbron> tseliot: https://code.edge.launchpad.net/~rexbron/dontzap/trunk.dontzap_as_module
[22:27] <tseliot> rexbron: yes, it's more like "when I can". It's been a rather stressing period and I have to fix a nasty bug (which has the highest priority now)
[22:28] <rexbron> tseliot: is there anyone else who could look at that branch? bryce is listed as a contributer
[22:30] <tseliot> rexbron: he reviewed my code but he might be very busy too
[22:30] <rexbron> tseliot: I can ask :)
[22:30] <tseliot> ok
[22:31] <nemo> eek. you guys got rid of fpc too :(
[22:32] <tseliot> rexbron: on a second thought (now that I can see the diff) I think I can have a look at it tomorrow. It shouldn't take long
[22:33] <tseliot> well, tomorrow in Italy ;)
[22:34] <tseliot> (the time zone)
[22:35] <nemo> hm. restoring the Ibex packages seems to work fine. I wonder why they were removed
[22:35] <rexbron> tseliot: thanks!
[22:36] <tseliot> rexbron: np. Good night
[22:49] <nemo> frig. no a52dec-dev either
[22:52] <maxb> nemo: removal reasons should be given on https://launchpad.net/ubuntu/+source/<sourcepackagename>
[22:54] <maxb> sdl-net1.2 is still there in jaunty
[22:54] <maxb> fpc is still there in jaunty
[22:54] <maxb> a52dec is still there in jaunty
[22:55] <maxb> nemo: I call pilot error :-)
[22:55] <nemo> maxb: hmmmm
[22:55] <nemo> maxb: where are you finding these?
[22:55] <nemo> for i386
[22:55] <maxb> https://launchpad.net/ubuntu/+source/a52dec
[22:55] <maxb> https://launchpad.net/ubuntu/+source/fpc
[22:55] <maxb> https://launchpad.net/ubuntu/+source/sdl-net1.2
[22:55] <nemo> source packages are there, yes :)
[22:56] <maxb> Well... if the binaries have gone missing, that's worrying
[22:57] <nemo> maxb: if you drill down to i386, only binaries listed for all these are Intrepid
[22:57] <nemo> maxb: I've been slowly adding the intrepid ones by hand, one at a time.
[22:57] <nemo> which was working out ok, right up until I ran into fp-units-multimedia which wanted a52dec-dev
[22:57] <nemo> which I can't seem to find even an Intrepid package of, oddly.
[22:58] <nemo> maxb: certainly they aren't in the repository
[22:58] <nemo> which is pretty nutty for libsdl-net I have to say
[23:01] <maxb> so, um, I can see libsdl-net1.2 in jaunty i386 and amd64 Packages file
[23:01] <maxb> So what's the problem?
[23:01] <nemo> If I go to:
[23:01] <nemo> https://launchpad.net/ubuntu/jaunty/i386/libsdl-net1.2/1.2.7-2
[23:02] <nemo> the only downloadable file was for hardy RELEASE
[23:02] <nemo> is this ok?
[23:02] <maxb> yes
[23:02] <nemo> if so, I must be missing something more fundamental about package management in ubuntu
[23:02] <nemo> do I need to enable some hardy repo in order to install all this in Jaunty?
[23:02] <maxb> No
[23:02] <nemo> 'cause the default repo said that libsdl-net1.2 wasn't available
[23:03] <maxb> bad mirror?
[23:03] <nemo> no. said it was literally not available.
[23:03] <maxb> Well, it is available
[23:03] <nemo> masked or whatever. not familiar with the terminology precisely
[23:04] <nemo> anyway. so I installed off of the link above, the Hardy package
[23:04] <nemo> but. let me remove it, try reinstalling, and get the precise error
[23:04] <maxb> That's a kludgy way to do it
[23:04] <nemo> didn't say I knew this stuff...
[23:04] <nemo> Packkage libsdl-net1.2 is not available, but is referred to by another package.
[23:05] <nemo> This may mean that the package is missing, has been obsoleted, or is only available from another source
[23:05] <maxb> apt-get update
[23:05] <nemo> that seems an odd reason given I just updated to Jaunty minutes ago :)
[23:05]  * nemo does it anyway
[23:07] <nemo> and heck. why'd it uninstall 'em in the first place on update, unless they had been obsoleted
[23:07] <nemo> I had a functioning libsdl-net1.2-dev which I let it uninstall thinking I had to perhaps install libsdl-net1.3 or somesuch
[23:09] <nemo> maxb: *sigh* you were right :(
[23:09] <maxb> O:-)
[23:10] <nemo> now why didn't it do that *FOR* me :-p
[23:15] <directhex> dear firefox, of all the times to crash, when i click "confirm booking" is not one of them. no love, directhex
[23:15] <nemo> directhex: can I see the crash stack from about:crashes ?
[23:16] <nemo> want to see if flash or java might have been at fault.
[23:16] <nemo> 'course could be just some buggy plugin you have :)
[23:16] <nemo> er. extension.
[23:16] <directhex> The URL is not valid and cannot be loaded.
[23:19] <directhex> This booking has already been made. If you feel this is wrong please contact us at the phone number at the bottom of this page.
[23:19] <directhex> could be worse
[23:19] <mok0> karmic koala!
[23:20] <nemo> heh
[23:20] <nemo> hm. now why on earth is Qt sucking up 100% of my CPU in Jaunty
[23:20] <nemo> laptop is just churning away
[23:21]  * nemo checks to see what libqt packages changed
[23:21] <nemo> great. 4.5.0 :-/
[23:21] <nemo> guess I can forcibly revert to Ibex on those
[23:38] <genii> Hi, is launchpad currently down? Trying to participate in the BugJam but keep getting "try reloading"
[23:39] <JontheEchidna> nah, it's still up. It's just doing that more than often
[23:39] <mrooney> genii: #launchpad  would be the appropriate place to inquire, and it is a known issue :)
[23:40] <JontheEchidna> *more than usual
[23:40] <genii> mrooney: Great, thanks
[23:43] <nemo> looks like I'm running into http://www.qtsoftware.com/developer/task-tracker/index_html?method=entry&id=173328
[23:43] <nemo> I suppose I should file it as a Jaunty bug too, as a warning to others :)
[23:43] <nemo> hm. n/m. that can't be the right bug.
[23:44] <nemo> wrong reason
[23:44] <nemo> right place, wrong reason :)
[23:46] <nemo> oh well. enough whinging in here. I didn't actually have any *ubuntu* problems that an update couldn't fix. later y'all
[23:51] <mrooney> Any idea why my Intrepid package is saying "Error: Dependency is not satisfiable: python-central"
[23:56] <goshawk> for an ubuntu-security member: bug #292923 have been solved in jaunty with the next version 1.2.4 . This version is just a security fix, i think it could be backported to intrepid too..


[16:01] <coreycb> o/
[16:01] <arges> o/
[16:01] <lutostag> o/
[16:01] <smb> o/
[16:01] <hallyn> \o
[16:01] <matsubara> o/
[16:02] <apw> o\
[16:02] <lutostag> #startmeeting ubuntu-server-team
[16:02] <meetingology> Meeting started Tue Feb 10 16:02:44 2015 UTC.  The chair is lutostag. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[16:02] <meetingology> Available commands: action commands idea info link nick
[16:03] <lutostag> #topic Review ACTION points from previous meeting
[16:03] <lutostag> doesnt look like there are any action items from last time assuming "gaughen to establish new qa-team point of contact for server team" made progress
[16:03] <gnuoy> o/
[16:03] <smoser> o/
[16:03] <rharper> \o
[16:03] <chiluk> o/
[16:04] <rbasak> o/
[16:04] <zul> hi
[16:04] <lutostag> #topic Vivid Development
[16:04] <gaughen> lutostag, THAT IS DONE
[16:04] <gaughen> AAAH DAMN ALL CAPS
[16:04] <gaughen> lutostag, that is done
[16:04] <gaughen> sorry, didn't mean to shout
[16:04] <lutostag> gaughen: thanks :)
[16:04] <lutostag> #link https://wiki.ubuntu.com/VividVervet/ReleaseSchedule
[16:04] <jamespage> o/
[16:04] <lutostag> Feature Freeze and DI Freeze the 19th
[16:04] <gaughen> \o
[16:05] <jamespage> get those version bumps in now or you'll have to ask for exceptions!
[16:06] <lutostag> #subtopic Release Bugs
[16:06] <lutostag> #link http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-v-tracking-bug-tasks.html#ubuntu-server
[16:07] <lutostag> cloud init bugs are the high ones I see, no critical
[16:07] <lutostag> still a ways out to be really worrying on that
[16:08] <lutostag> #subtopic Blueprints
[16:08] <lutostag> #link http://status.ubuntu.com/ubuntu-v/group/topic-v-server.html
[16:08] <lutostag> kilo is looking good! :)
[16:09] <lutostag> #topic Server & Cloud Bugs (caribou)
[16:09] <lutostag> or another contact?
[16:10] <lutostag> that's ok we'll move on for now
[16:10] <lutostag> #topic Weekly Updates & Questions for the Kernel Team (smb, sforshee, arges)
[16:10] <smb> Nothing hear here. Please move along.
[16:10] <lutostag> smb: thanks
[16:10] <lutostag> #topic Ubuntu Server Team Events
[16:11] <lutostag> so hopefully you guys have gotten in your ODS stuff, anything else?
[16:11] <beisner> it's taco tuesday.
[16:12] <jamespage> no its freedom friday - but on a tuesday still
[16:12] <hallyn> yum
[16:13] <lutostag> great
[16:13] <lutostag> #topic Open Discussion
[16:13] <lutostag> anything else?
[16:13] <lutostag> #topic Announce next meeting date and time
[16:14] <lutostag> same time +7days, same channel :)
[16:14] <lutostag> #endmeeting
[16:14] <meetingology> Meeting ended Tue Feb 10 16:14:17 2015 UTC.
[16:14] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2015/ubuntu-meeting.2015-02-10-16.02.moin.txt
[16:14] <gnuoy> thanks lutostag
[16:14] <beisner> thanks, lutostag
[16:14] <lutostag> zul: seems like your chair next
[16:14] <lutostag> :)
[16:15] <lutostag> or arosales -- he doesnt get a break...
[17:00] <jsalisbury> ##
[17:00] <meetingology> Meeting started Tue Feb 10 17:00:06 2015 UTC.  The chair is jsalisbury. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[17:00] <meetingology> Available commands: action commands idea info link nick
[17:00] <jsalisbury> ##
[17:00] <jsalisbury> [LINK] https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Vivid
[17:00] <smb> o/
[17:00] <kamal> o/
[17:00] <cking> \o
[17:00] <henrix> o/
[17:00] <arges> o/
[17:00] <bjf> o/
[17:00] <sforshee> o/
[17:00] <ogasawara> o/
[17:00] <chiluk> /O\
[17:00] <jsalisbury> [TOPIC] Release Metrics and Incoming Bugs (jsalisbury)
[17:01] <jsalisbury> Release metrics and incoming bug data can be reviewed at the following link:
[17:01] <jsalisbury> [LINK] http://people.canonical.com/~kernel/reports/kt-meeting.txt
[17:01] <apw> o/
[17:01] <jsalisbury> ..
[17:01] <ppisati> o/
[17:01] <jsalisbury> [TOPIC] Status: Vivid Development Kernel (ogasawara)
[17:01] <ogasawara> Our Vivid kernel has been rebased to v3.18.5 upstream stable.  It's
[17:01] <ogasawara> been uploaded to the archive, 3.18.0-13.14.  Please test and let us
[17:01] <ogasawara> know your results.
[17:01] <ogasawara> We would like to push the v3.19 based kernel we have up to the archive
[17:01] <ogasawara> soon.  We are just cleaning up some DKMS drivers before we do so.  For anyone interested in getting an early preview, we have a v3.19 based
[17:01] <ogasawara> kernel available for testing in our ckt PPA.
[17:01] <ogasawara> -----
[17:01] <ogasawara> Important upcoming dates:
[17:01] <ogasawara> [LINK] https://wiki.ubuntu.com/VividVervet/ReleaseSchedule
[17:01] <ogasawara> Thurs Feb 19 - 14.04.2 Point Release (~1 week away, yes this was
[17:01] <ogasawara> delayed)
[17:01] <ogasawara> Thurs Feb 26 - Beta 1 Freeze (~2 weeks away)
[17:01] <ogasawara> Thurs Mar 26 - Fina l Beta (~6 weeks away)
[17:01] <ogasawara> Thurs Apr 09 - Kernel Freeze (~8 weeks away)
[17:01] <ogasawara> ..
[17:01] <jsalisbury> [TOPIC] Status: CVE's
[17:01] <jsalisbury> The current CVE status can be reviewed at the following link:
[17:01] <jsalisbury> http://people.canonical.com/~kernel/cve/pkg/ALL-linux.html
[17:01] <jsalisbury> ..
[17:02] <jsalisbury> [TOPIC] Status: Stable, Security, and Bugfix Kernel Updates - Utopic/Trusty/Precise/Lucid (bjf/henrix/kamal/arges)
[17:02] <bjf> Status for the main kernels, until today:
[17:02] <bjf>   *   Lucid - Kernel Prep Week
[17:02] <bjf>   * Precise - Kernel Prep Week
[17:02] <bjf>   *  Trusty - Kernel Prep Week
[17:02] <bjf>   *  Utopic - Kernel Prep Week
[17:02] <bjf>
[17:02] <bjf> Current opened tracking bugs details:
[17:02] <bjf>   * http://kernel.ubuntu.com/sru/kernel-sru-workflow.html
[17:02] <bjf> For SRUs, SRU report is a good source of information:
[17:02] <bjf>   * http://kernel.ubuntu.com/sru/sru-report.html
[17:02] <bjf>
[17:02] <bjf>
[17:02] <bjf> Schedule:
[17:02] <bjf>
[17:02] <bjf> Current cycle had ended. Waiting for next cycle to start on Feb. 08.
[17:02] <bjf> cycle: 06-Feb through 28-Feb
[17:02] <bjf> [17:02] <bjf>          06-Feb   Last day for kernel commits for this cycle
[17:02] <bjf> 08-Feb - 14-Feb   Kernel prep week.
[17:02] <bjf> 15-Feb - 28-Feb   Bug verification; Regression testing; Release
[17:02] <bjf> ..
[17:02] <jsalisbury> [TOPIC] Open Discussion or Questions? Raise your hand to be recognized (o/)
[17:03] <jsalisbury> Thanks everyone
[17:03] <jsalisbury> #endmeeting
[17:03] <meetingology> Meeting ended Tue Feb 10 17:03:03 2015 UTC.
[17:03] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2015/ubuntu-meeting.2015-02-10-17.00.moin.txt
[17:03] <kamal> thanks jsalisbury


[16:25] <CIA-4> debian-installer: cjwatson * r1308 ubuntu/ (7 files in 2 dirs): Move to 2.6.35-1 kernels.
[17:13] <achiang> anyone have tricks for debugging casper?
[17:19] <cjwatson> http://wiki.ubuntu.com/DebuggingCasper
[17:19] <superm1> also i dont see it mentioned there, but break=casper-bottom helps
[17:23] <achiang> cjwatson: thanks. i'll try that. i'm doing some rather non-standard things.
[17:25] <achiang> cjwatson: superm1: are you aware of any issues with running casper on a long-running system? say, running out of inodes in the aufs?
[17:26] <cjwatson> wouldn't surprise me but I'm not specifically aware
[17:27] <achiang> ok. i'm looking to setup a system where we essentially run casper off the hard drive (for long periods of time)
[17:27] <achiang> does that sound sane?
[17:27] <cjwatson> I wouldn't.  But it's your call. :-)
[17:27] <cjwatson> I don't trust aufs that much.
[17:28] <achiang> that's... unfortunate
[17:28] <cjwatson> test it on your target system, rather than relying on theory
[17:29] <achiang> cjwatson: right. that's on my list of todos
[17:29] <achiang> i'm still trying to setup the target system though
[17:43] <CIA-4> debian-installer: cjwatson * r1309 ubuntu/debian/changelog: releasing version 20100211ubuntu5
[19:48] <davmor2> cjwatson: the tool for selecting lamp etc on the server cd what is it called please?
[19:49] <davmor2> apparently mysql isn't installed on lamp server
[19:54] <cjwatson> tasksel
[19:54] <davmor2> cjwatson: thanks
[19:55] <davmor2> just got there myself from my server book