[12:04] <lamont> daniels: heh
[12:07] <_nexus_> qualche italiano?
[12:07] <_nexus_> ERROR[ogle_nav] : faild to open/read the DVD <_nexus_> callbacks.on_opendvd_activate(): DVDSetDVDRoot: Root not set
[12:08] <Kamion> #ubuntu, unless you have a patch :-)
[12:08] <_nexus_> ?
[12:08] <_nexus_> io devo settare il dvd in dvdroot come il comando?
[12:13] <lamont> daniels: it almost looks like (from debian/rules) that the minimum requirement is met with simply 'mv MANIFEST.hppa.new MANIFEST.hppa.in', yes>
[12:13] <lamont> >
[12:13] <lamont> ?
[12:14] <lamont> well, minus fonts
[12:16] <daniels> lamont: modulo anything in MANIFEST.all.in, yeah
[12:16] <lamont> grep -F MANIFEST.all MANIFEST.hppa.new > zz && mv zz MANIFEST.hppa.in
[12:17] <daniels> yeah
[12:18] <lamont> interesting... that makes an empty file... :(
[12:18] <daniels> oh
[12:18] <lamont> grep -Fv -f MANIFEST.all MANIFEST.hppa.new > zz
[12:18] <lamont> much better.
[12:18] <daniels> grep -F -v -f ... yeah
[12:23] <lamont> daniels: any current plans for a ubuntu9 version once you're back?
[12:26] <daniels> lamont: yeah, fo'sho.  fixing glx module loading, tweaking the way we create xc-xserver-xorg-dbg.
[12:26] <daniels> couple of other minor fixes.
[12:29] <lamont> daniels: OK.  I'll just toss you a new MANIFEST.hppa.in then.
[12:30] <lamont> since it certainly doesn't warrant _2_ xorg uploads. :-)
[12:32] <daniels> lamont: heh, cool :)
[12:32] <daniels> lamont: yeah, I'll probably do it on the 4th
[12:33] <bluefoxicy> uh
[12:33] <bluefoxicy> Martin Pitt
[12:33] <bluefoxicy> I need to talk to him
[12:33] <mdz> bluefoxicy: = pitti
[12:33] <bluefoxicy> ok
[12:33] <bluefoxicy> trulux said he's been talking to him
[12:33] <bluefoxicy> so I want to see what's going on :)
[12:34] <bluefoxicy> mdz:  should I e-mail him or wait for him to come on
[12:34] <Kamion> it's kind of holiday season at the moment
[12:34] <bluefoxicy> so e-mail would be rude then?
[12:34] <daniels> bluefoxicy: if it's not urgent, try email.
[12:34] <daniels> no, not at all
[12:34] <bluefoxicy> it's not urgent but I dn't want to bother his holiday :)
[12:34] <mdz> and even during more normal working time, he's not generally around until about 0800 UTC
[12:35] <Kamion> wasn't referring to e-mail, just telling you not to expect him around necessarily any time soon
[12:35] <daniels> thom: please make mutt on amnesiac stop segfaulting ;)
[12:35] <bluefoxicy> ok
[12:35] <daniels> thom: (~daniel/core, if you're interested)
[12:35] <bluefoxicy> so I'll e-mail then  :)
[12:37] <lamont> daniels: ubuntu8.1 build scheduled, I expect it'll work - but it is behind a gcc-3.3 build, so that just means it'll be a few hours before it's actually done.
[12:38] <daniels> lamont: sure, that's fine.
[12:38] <lamont> daniels: before dying in MANIFEST check, Build needed 02:58:19, 3106716k disk space
[12:38] <daniels> that's not too bad
[12:38] <daniels> of course, it's no concordia (32min)
[12:38] <daniels> hey, I'm sure someone said 'San Andreas'
[12:41] <Kamion> San Andreas?
[12:41] <daniels> Kamion: GTA: San Andreas
[12:41] <daniels> the only game where you get to hear 'I THO' YO' WAS REPRESENNIN'
[12:41] <Kamion> aha
[12:42] <daniels> it's *way* too much fun, and totally worth having bought a PS2 for :)
[12:42] <Kamion> suits you down to the ground then :)
[12:42] <daniels> of course
[12:42] <daniels> young black American from tha ghetto
[12:42] <daniels> they picked their demographic fo'sho
[12:42] <mdz> anyone else getting loads of old mail via Ubuntu lists?
[12:42] <daniels> mdz: jdub presumably just did moderation
[12:42] <daniels> mdz: (yes)
[12:42] <ogra> mako is moderating ;)
[12:43] <daniels> Kamion: you can also dress them, get haircuts, and buy bling!
[12:43] <Kamion> sort of Barbie for the 2000s
[12:44] <daniels> my homie has some dogtags
[12:45] <ogra> Kamion: LOL
[12:45] <lamont> daniels: I think I have my dad's dogtags around here somewhere.
[12:52] <mdz> mako: http://err.no/pictures/2004-12-Mataro/thumbnail/dsc00372.jpg
[12:53] <daniels> mdz: dude, http://photos.jonmasters.org/albums/canonical_conference_mataro_2004/dscn4515.thumb.jpg
[12:53] <daniels> or, even better, http://photos.jonmasters.org/canonical_conference_mataro_2004/dscn4515
[12:53] <daniels> that is *frightening*.
[12:53] <mdz> that's nothing
[12:54] <mdz> http://err.no/pictures/2004-12-Mataro/slides/dsc00337.html
[12:54] <bluefoxicy> when is Hoary scheduled?
[12:54] <mdz> bluefoxicy: http://www.ubuntulinux.org/wiki/HoaryReleaseSchedule
[12:55] <bluefoxicy> damn
[12:55] <bluefoxicy> february feature freeze will mean no more exploration of SSP
[12:56] <bluefoxicy> guess that rules out trying to push for getting anything trulux has done into Hoary
[12:56] <Kamion> one of the great benefits of a six-monthly release cycle is that you don't have to do the dysfunctional thing of trying to push absolutely everything for the current release
[12:57] <Kamion> (dysfunctional because the behaviour tends to push releases back and make them less stable)
[12:57] <bluefoxicy> Kamion:  I don't know if trulux has SSP completely ready so that package regression can be searched for yet
[12:57] <bluefoxicy> if you compile a package with SSP, and it has an internally triggered buffer overflow, it will break
[12:58] <Kamion> sounds like an excellent reason to target hoary+1 ;)
[12:58] <Kamion> (the former)
[12:59] <bluefoxicy> I don't think you could build and test every package in Ubuntu's core (not in Universe) by February
[12:59] <bluefoxicy> then again, maybe I'm using odd values for "test"
[01:00] <bluefoxicy> although, would that type of breakage really preclude SSP from being used?  It's basically SSP exposing existing bugs . . .
[01:00] <Kamion> there are plenty of programs where you wouldn't care
[01:01] <Kamion> I'm all for exposing bugs in server processes, but that's a limited subset
[01:01] <Kamion> I'm also all for not pissing users off about one-byte overflows in programs where it doesn't really matter :)
[01:02] <Kamion> either way, rushing into something this complex doesn't sound like a good plan; I prefer the "careful consideration" approach
[01:08] <bluefoxicy> Kamion: it's not complex is it?
[01:08] <bluefoxicy> Kamion:  and what about overflows in mozilla?
[01:08] <bluefoxicy> one bad .png file and you're suddenly dealing with the FBI coming to your door to examine your worm-based child porn trafficing activities.
[01:10] <bluefoxicy> Kamion:  also, a lot of attacks are local privilege elevation
[01:10] <bluefoxicy> if an attacker can't exploit Mozilla, he can't get local access, thus he can't use a local exploit to freeze the machine (floating point register corruption) or get root access
[01:21] <mako> mdz: i look slightly insane in that picture
[01:22] <ogra> mako: but ubercool in this one (february-calendar) http://www.grawert.net/mataro/img100.jpeg
[01:23] <mako> ogra: that one is great :)
[01:24] <bluefoxicy> btw
[01:24] <bluefoxicy> what's a hedgehog?
[01:25] <ogra> http://www.glaquarium.org/scans2/hedgehog.jpg
[01:25] <mdz> dict hedgehog
[01:26] <ogra> bluefoxicy: google picture search is your friend
[01:28] <bluefoxicy> that doesn't look like the image of the warthog that Ubuntu had up on the amin page for a while
[01:28] <bluefoxicy> but it's cute.
[01:35] <mdz> a warthog and a hedgehog are different animals
[02:05] <Kamion> bluefoxicy: dude, relax, I'm not having a go at the value of it in general, merely saying that rushing into a change that will make programs crash when they would previously have worked (not all buffer overflows are fatal or security exposures, remember) is unwise.
[02:05] <Kamion> mozilla is obviously a network client and therefore on a security boundary
[02:05] <Kamion> same as server processes
[02:05] <Kamion> not everything is on a security boundary
[02:05] <bluefoxicy> heh
[02:06] <bluefoxicy> Kamion:  all libraries are on a security boundary by default though
[02:06] <Kamion> the most important thing about security engineering is knowing where the boundaries are ...
[02:06] <bluefoxicy> unless YOU want to trace and catalogue every network-side program and every library they call, and every plug-in they can use that calls other libraries :)
[02:07] <bluefoxicy> but yeah
[02:07] <bluefoxicy> I don't want to rush
[02:07] <Kamion> let's take non-networked games; they're rarely on a security boundary, and they're often poorly written
[02:07] <Kamion> but it doesn't really matter if they overflow an array here or there
[02:07] <daniels> *very* poorly written.
[02:07] <bluefoxicy> right
[02:07] <bluefoxicy> non-networked games we don't care about
[02:08] <bluefoxicy> Kamion:  but in cases where you don't expose bugs, the protection is pretty much harmless
[02:08] <Kamion> and if they start crashing on Ubuntu when they don't crash on other distributions, I know who users are going to blame, and it won't be the game authors
[02:08] <bluefoxicy> so it becomes that it's not really worth the effort to decide which packages don't need the protection
[02:08] <Kamion> so I feel quite strongly that the change ought to be made only selectively
[02:08] <bluefoxicy> because it's visible when they break things (you NEED to test when you build a package)
[02:08] <Kamion> I disagree
[02:08] <bluefoxicy> howso?
[02:08] <Kamion> I've already explained
[02:09] <Kamion> I'm not going to do so twice :)
[02:09] <bluefoxicy> I already poked the gentoo-dev mailing list with this question once
[02:09] <bluefoxicy> and they couldn't decide where was and was not appropriate
[02:09] <daniels> just because it's a hard question doesn't mean it shouldn't be asked
[02:09] <bluefoxicy> it's hard to make a policy for this stuff :)
[02:09] <Kamion> many things are hard
[02:09] <bluefoxicy> daniels:  well, it becomes a hard question with certain answers
[02:09] <bluefoxicy> I run a fully stack smash protected base here. . .
[02:09] <Kamion> finding a sane middle ground between security engineering and release management is hard
[02:09] <bluefoxicy> gimme a minute
[02:10] <Kamion> doesn't mean it shouldn't be done
[02:10] <bluefoxicy> I'll count how much stuff ejects stack smash protection thatI have installed
[02:10] <Kamion> I'm not convinced that's relevant
[02:10] <Kamion> you're a security type, therefore it's a skewed sample :)
[02:10] <crimsun> we all agree that it's relevant for hoary+1, correct?
[02:10] <daniels> (anyone on #u-d will skew a sample)
[02:10] <sivang> Kamion: hello, I am interested to know if you could provide d-i sources that support installing using a preset language, that is for example, a d-i which would install ubuntu using the hebrew translation of d-i, and would then pull a deb package which would set all the needed fonts and set up hebrew input in GNOME Kbd Selector. is this possible?
[02:10] <crimsun> (because there's not much sense in pushing it in now)
[02:10] <bluefoxicy> Kamion:  I don't control what has and does not have SSP disabled
[02:11] <Kamion> sivang: preseed the language choices in your bootloader configuration
[02:11] <Kamion> as for the rest we haven't got the infrastructure for that yet, hopefully we will have soon with language packs
[02:12] <Kamion> crimsun: it seems fairly clear to me it should happen at the beginning of a release cycle, same way X.Org did
[02:12] <bluefoxicy> Kamion:  but the point of the check is that if there are, say, 10 packages in the world that break, and 100,000 packages total, and 70% of them are security boundaries, you have 30,000 packages to dredge through when only 10 really matter.
[02:12] <daniels> there will be a lot more than 10
[02:12] <daniels> you're a factor of ~100 off
[02:12] <bluefoxicy> daniels:  yeah
[02:12] <bluefoxicy> I know there's going to be a lot more than 10
[02:13] <Kamion> so why choose an exaggerated example? :)
[02:13] <bluefoxicy> but it's not that significant that it should be selectively applied rather than selectively removed, I believe.
[02:13] <sivang> Kamion: some folks over the huji have set up to create a localized hebrew distro, now I told them we should probably wait when we have the infrastructure available. How would you suggest going on with this?
[02:13] <sivang> Kamion: huji = Hebrew University Of Jerusalem
[02:13] <Kamion> bluefoxicy: I don't believe I was necessarily arguing for either selective application or selective removal; merely selection ...
[02:13] <bluefoxicy> Kamion: it gets the point accross better while letting me get away without having to explain that the example is hypothetical?  :)
[02:14] <bluefoxicy> Kamion:  heh
[02:14] <Kamion> sivang: I don't really have an answer for you as yet, sorry, I hope I will have in a while
[02:14] <Kamion> it's an important issue but the work just hasn't been done yet
[02:14] <Kamion> most of it is targetted at hoary though
[02:14] <bluefoxicy> Kamion:  RedHat selectively applies things.  When they started out, they had 100% of everything wide open with an executable stack and heap.  Now there's something like 1-5% of packages (estimate) that have an executable stack but don't need it
[02:15] <bluefoxicy> wihch means there's a hole in their policy at those points
[02:15] <Kamion> like I say, you're arguing against a strawman; I didn't say we wanted selective application
[02:15] <bluefoxicy> not a problem right now, but it's a potential place for you to start looking if you want ot hijack an RHEL server.
[02:15] <bluefoxicy> heh
[02:15] <bluefoxicy> Kamion:  and i never said I wanted to leave broken things to break
 Kamion:  I don't know if trulux has SSP completely ready so that package regression can be searched for yet
 if you compile a package with SSP, and it has an internally triggered buffer overflow, it will break
[02:16] <Kamion> however, it will easily take a full release cycle to determine what the things that users care about are that break, and whether fixing them or disabling SSP for them is appropriate
[02:16] <bluefoxicy> SEarching for regressions implies that somebody has to do something about them.  You have two choices:  Remove the protections, or fix the bugs.  I didn't specify which, and I don't expect you to suddenly become code janitors  :)
[02:17] <bluefoxicy> eh
[02:17] <Kamion> we're coming up to our second release, and that's a fairly critical time as regards community confidence
[02:17] <Kamion> if the second release is a "let's break the world" release, people are just going to shrug and go find something else
[02:17] <Kamion> so, caution is advised :)
[02:17] <bluefoxicy> Kamion:  disabling SSP for breaking things if you're crunched for time is acceptable, since you in the worst case wind up back where you started, and in the best case wind up with at least some protection
[02:18] <Kamion> indeed so
[02:18] <bluefoxicy> and I never implied that I wanted a broken release
[02:18] <Kamion> right, the only reason I said anything was that you sounded annoyed about the date of the feature freeze :)
[02:18] <bluefoxicy> if there's simply not enough time to definitely say that SSP can be supplied in SOMETHING without breaking ANYTHING, then it doesn't go in.  Same with anything else :)
[02:19] <Kamion> people with an interest in release management tend to have hot buttons about this kind of thing ...
[02:19] <bluefoxicy> Kamion:  yes, because that means there's little time for testing, and I don't know if the testing would need to show acceptable results before or after the freeze (if it's defferred to after the freeze, it means that at freeze time we don't know if it's going in or not)
[02:19] <bluefoxicy> heh
[02:19] <bluefoxicy> I actually didn't mean to discuss this here and now you know :)
[02:20] <Kamion> fair enough :)
[02:20] <Kamion> (apologies for going off on one :-))
[02:20] <bluefoxicy> it's ok
[02:20] <bluefoxicy> I like talking :P
[02:21] <bluefoxicy> just not wasting everyone's time with excess channel noise.
[02:22] <bluefoxicy> Kamion:  i think having added security in release 2 would be impressive though
[02:23] <bluefoxicy> but that's not my motivation.
[02:23] <bluefoxicy> if these things go in successfully, it will bring attention to their viability in default installs, which means others will mimic that behavior and increase the general security of their own operating environments :)
[02:24] <Kamion> we're adding a scary amount of stuff in release 2 ... :)
[02:24] <bluefoxicy> that's good :)
[02:24] <bluefoxicy> it's called progress
[02:24] <Kamion> back in the early planning stages for warty, we used "hoary" as a notional dumping-ground for everything future
[02:24] <Kamion> we've been trimming the list down ever since ...
[02:27] <bluefoxicy> have you seen my analysis of the USNs?  It's just statistics (I'm not yet scholarly involved in security; it's hobbyist level for me)
[02:27] <bluefoxicy> but it shows what could have been controlled :)
[02:27] <Kamion> like I say, I don't dispute the value. :)
[02:28] <bluefoxicy> either way it's an interesting read :)
[02:30] <Kamion> WRT adding security in release two, note that we're adding authenticated package retrieval, which is a major headline security feature in itself
[02:30] <bluefoxicy> gpg signatures?
[02:32] <Kamion> yeah
[02:32] <bluefoxicy> cool.
[02:33] <sivang> bluefoxicy: where can I read about those?
[02:34] <bluefoxicy> sivang:  https://www.ubuntulinux.org/wiki/USNAnalysis
[02:37] <bluefoxicy> I pointed out that the last bit left over is going to be at best containable with a MAC system, though this is not a full solution; kernel exploits I imagine would be able to get past SELinux in some cases, and then there's local attacks that may not rely on whatever the MAC restricts.
[02:37] <bluefoxicy> still those are special cases
[02:37] <Kamion> the grub password thing is interesting, although somebody else gets to argue with Mark about the extra question in the installer; I've done my share of arguments like that :)
[02:39] <bluefoxicy> uh
[02:39] <ogra> hmm, you loose the edit ....
[02:39] <bluefoxicy> those kinds of protections are probably better for server environments, though your kids at home might be smart enough to init/
[02:39] <bluefoxicy> those kinds of protections are probably better for server environments, though your kids at home might be smart enough to init=/bin/sh
[02:39] <bluefoxicy> or stuff
[02:39] <ogra> which is a big advantage in grub over lilo
[02:40] <ogra> or knoppix.....
[02:40] <Kamion> sadly grub doesn't work in all environments
[02:40] <ogra> its still young
[02:40] <bluefoxicy> then again, you know, if the home user isn't able to handle a password getting in their way, they're probably not going to need the functionality that entering the password gives in the first place.
[02:40] <sivang> young but _very_ promising.
[02:41] <ogra> yep...but still....
[02:41] <ogra> or rather the arch it ran on
[02:41] <Kamion> bluefoxicy: chances are we'd only ask if they opted to turn on selinux
[02:44] <bluefoxicy> yeah
[02:49] <bluefoxicy> Dan's Guardian should be looked at for the child safety thing.
[02:49] <bluefoxicy> https://www.ubuntulinux.org/wiki/IdeaPool
[02:49] <bluefoxicy> You can hijack certain users' connections and force them through a squid that uses Dan's Guardian as a parent
[03:16] <daniels> 'You down to represent, baby?'
[03:16] <daniels> elmo: GTA:SA.
[06:09] <srbaker> yo
[06:31] <fabbione> morning guys
[06:34] <crimsun> re
[07:05] <fabbione> ubuntu/pool/universe/l/linux-source-2.6.10
[07:06] <fabbione> does anybody spot something SLIGHTLY wrong with it?
[07:11] <crimsun> looks ok to me. I see reiserfs EA made it in.
[07:12] <fabbione> crimsun: yeah i did put them in..
[07:12] <fabbione> but that's not the problem
[07:13] <fabbione> the kernel landed in universe
[07:13] <fabbione> while it should be in main
[07:13] <crimsun> I was wondering about that
[09:17] <mdz> night
[09:18] <fabbione> night mdz
[09:19] <fabbione> mjg59: [   ]  linux-source-2.6.10_2.6.10-1_20041230-0427-i386-successful
[09:19] <fabbione> this was 4 minutes ago
[10:40] <Treenaks> zenrox: please make up your mind :)
[10:41] <zenrox> sorry hoary has it probs when a progam breaks and the only way to fix it is reboot
[10:42] <Treenaks> zenrox: that's only if the kernel breaks
[10:43] <crimsun> just remove #ubuntu* from your autojoin channel list ;)
[10:43] <zenrox> i tride 3 dif ways to kill gnome
[10:43] <zenrox> and that dont work
[10:43] <zenrox> then frezes gdm
[10:44] <Treenaks> zenrox: go to the console, whip out ps aux | less and kill -9 along ;)
[10:44] <zenrox> i did dint help
[10:44] <Treenaks> strange
[10:50] <Mithrandir> pitpong
[10:51] <Mithrandir> hm, no pitti
[10:54] <mvo> Mithrandir: he's on vacation
[10:55] <Mithrandir> he pinged me yesterday or the day before.
[10:56] <mvo> he worked one (or two?) days to keep up with all the security stuff that pilled around christmas
[11:13] <fabbione> hey Mithrandir
[11:13] <fabbione> Mithrandir: i think it is something to do with mailman
[11:13] <fabbione> Mithrandir
[11:13] <fabbione> do you still host planet.d.n?
[11:15] <HcE> fabbione: you mean planet.s.n, if yes, it's a yes
[11:15] <fabbione> .s.n?
[11:15] <HcE> maybe the d is just yet another alias
[11:15] <HcE> samfundet
[11:15] <fabbione> debian.net ?
[11:16] <fabbione> or .org..
[11:16] <HcE> hihi
[11:16] <HcE> he got a machine at Samfundet with a name planet too
[11:17] <fabbione> planet.samfundet.net doesn't resolv
[11:17] <HcE> planet.samfundet.no resolves
[11:18] <HcE> totally different machine
[11:18] <HcE> I always presume .n == .no
[11:18] <HcE> and s is close to d
[11:58] <Mithrandir> fabbione: no, planet.d.n is on gluck.
[12:02] <Treenaks> sid's Sources.gz is 1337 Kb today...
[12:07] <garnacho> mvo: ping?
[12:12] <abelli> garnacho: what's up
[12:12] <garnacho> hey abelli :)
[12:12] <garnacho> howdy?
[12:13] <abelli> ...de puta madre
[12:13] <abelli> any news on mini-gnome?
[12:17] <jordi> Treenaks: hah
[12:17] <garnacho> abelli: only that I have to get some time to finish the list... all my vacation days went to the conference, and there is missing stuff I wanted to add to gst before the gnome feature freeze... :/
[12:17] <Treenaks> jordi: so today, Debian's sources are 1337.. beat that, Gentoo!  I'm having trouble to build packages because "WARNING: packages cannot be authenticated". Is there a solution to that?
[02:26] <mvo> siretart: you can use the "--allow-unauthenticated" switch in apt
[02:27] <mvo> this is equivalent to setting: "APT::Get::AllowUnauthenticated=true" in your apt.conf
[02:27] <siretart> hm new to bpuilder, and I dont see a config options for that. gotta search..
[02:29] <mvo> siretart: I copied my /etc/apt dir to /etc/pbuilder/apt.config, added the APT::Get::AllowUnauthenticated=true to /etc/pbuilder/apt.confif/apt.conf.d/50allow-unauth and set APTCONFDIR=/etc/pbuilder/apt.config (in /etc/pbuilderrc)
[02:29] <siretart> ah, thank you very much
[02:30] <siretart> I'm trying to recompile evolution, because dependencies in hoary seems to be broken atm
[02:31] <mvo> siretart: really? seems to be ok here on my hoary ...
[02:31] <mvo> what kind of error message do you see?
[02:31] <siretart> evolution depends on libegroupwise1.2-0 (>= 1.1.1) which is unavailable
[02:32] <siretart> I find only libegroupwise1.2-1
[03:52] <siretart> mvo__: you where right, I was wrong, evolution is installable. aptitude was doing very weird things with my pinning config
[03:53] <mvo__> siretart: good to hear that it works for you again
[03:56] <siretart> mvo__: well, the actual problem still exists: evolution from hoary segfaults at start in my system. I'm still trying to find out why
[04:09] <fabbione> jeee i crashed
[04:10] <fabbione> i feel really really bad
[04:10] <fabbione> elmo: did you sync it from germinate (universe -> main)?
[04:11] <elmo> fabbione: not yet, still catching up on seed changes from the last week
[04:12] <fabbione> ok
[04:12] <fabbione> no rush :-)
[04:12] <fabbione> mvo: updrade-notifier is FTBFS
[04:12] <mvo> fabbione: shit
[04:12] <fabbione> (0.37-1) missing build-dep
[04:13] <fabbione> hecking for gtk+-2.0 libgnomeui-2.0 libglade-2.0 gconf-2.0 gamin hal dbus-glib-1... Package dbus-glib-1 was not found in the pkg-config search path.
[04:13] <fabbione> Perhaps you should add the directory containing `dbus-glib-1.pc'
[04:13] <fabbione> to the PKG_CONFIG_PATH environment variable
[04:13] <mvo> hm ... I was sure I added it :/
[04:14] <mvo> thanks for pointing this out
[04:14] <fabbione> np
[04:18] <abelli> sorry but i cant download universe's headers
[04:22] <Kinnison> bahnoseb
[04:30] <garnacho> mvo: ping?
[04:30] <mvo> garnacho: pong
[04:31] <garnacho> hi mvo :)
[04:31] <garnacho> remember we talked about adding isdn support to gst?
[04:31] <mvo> hi carolos
[04:31] <mvo> oh yes
[04:31] <mvo> I send you a mail about some ideas
[04:31] <mvo> I hope it made it to you?
[04:31] <garnacho> hmmm, no :/
[04:32] <garnacho> where did you send it?
[04:32] <mvo> I can resend it. i had some trouble with my isp recently :/
[04:32] <garnacho> please resend :)
[04:32] <mvo> send it to<EMAIL_ADDRESS>[04:32] <mvo> is this the wrong one?
[04:33] <garnacho> ouch, that address is quite old... try<EMAIL_ADDRESS>[04:33] <garnacho> (I should that address from everywhere...)
[04:33] <mvo> resend
[04:34] <mvo> thanks!
[04:34] <garnacho> thanks to you
[04:34] <garnacho> mvo: I began implementing some isdn support in gst, but I've got some doubts
[04:34] <mvo> what exactly troubles you?
[04:36] <garnacho> 1) do ippp interfaces show in ifconfig even when disconected (unlike ppp ones)
[04:36] <garnacho> and 2) the url you sent me has a bit unsecure method for password, does isdn support pap/chap?
[04:36] <garnacho> or am I forced to put it in the ppp options file?
[04:37] <mvo> it supports pap/chap
[04:37] <garnacho> cool, it's easier then, gst already supports this :)
[04:37] <mvo> about 1) i don't know, but with the capi based isdn support we really shouldn't need ipppd anymore. the stock pppd with the appropriate plugin should do
[04:38] <mvo> garnacho: most of the stuff needed for capi based isdn seems to be supported already :)
[04:39] <garnacho> mvo: hmmm, but there has to be an interface name, regardless of using ipppd, right?
[04:42] <mvo> garnacho: I'm not sure if I understand you but the interface name should be just ppp0 and it should behave like a normal ppp device from the systems point of view
[04:46] <garnacho> mvo: ok... so I'll have to find a way to distinguish between plain ppp interfaces and isdn ones :)
[04:47] <garnacho> mvo: but the rest is easy, and some work is already done
[04:47] <mvo> garnacho: what about checking for pppdplugin.so in existing one and /proc/capi/controller for new ones?
[04:47] <mvo> (just a idea)
[04:51] <mjg59> If someone could shove http://www.srcf.ucam.org/~mjg59/vbetool into Hoary, that would be great
[04:51] <garnacho> mvo: makes sense :)
[04:52] <zul> mjg59: what is it?
[04:52] <mjg59> zul: Lets you run various bits of video BIOS code
[04:52] <zul> cool
[04:52] <mjg59> Handy for ACPI
[04:53] <mvo> garnacho: cool! I owe you (at least) one beer on the next conference :)
[04:56] <garnacho> :P, who could refuse a beer? :)
[04:56] <srbaker> mjg59, what's vbetool?
[04:57] <mvo> garnacho: tell me once there is something for me to test (I assume you don't have isdn yourself :)
[04:58] <garnacho> mvo: cool! you're right :)
[04:59] <sivang> garnacho: we should maybe have a logger on #gst, so you could chat there and it would then reach all people who are involved in gst?
[05:00] <sivang> garnacho: :-)
[05:00] <mvo> where can I find the #gst channel?
[05:00] <garnacho> mvo: in irc.gnome.org
[05:00] <garnacho> sivang: not a bad idea...
[05:01] <mjg59> srbaker: <mjg59> zul: Lets you run various bits of video BIOS code
[05:03] <mvo> mjg59: I can upload it for hoary
[05:05] <srbaker> ahh
[05:05] <srbaker> cool
[05:05] <srbaker> oh, put ruby in main.
[05:05] <srbaker> because ruby is kick ass
[05:06] <mjg59> mvo: Rock, thanks
[05:06] <mjg59> Then we can sort out the userspace acpi stuff
[05:21] <srbaker> haha
[05:21] <srbaker> lamont, you should work for microsoft.
[05:21] <srbaker> lamont, things break faster now!
[05:22] <lamont> srbaker: trying to build xorg on hppa.
[05:22] <lamont> not because I want to use X on hppa, but because everything and it's mother build-depends something from x
[05:32] <lamont> off for more vacation fun today
[05:57] <mdz> Kamion: I very much like the idea of being able to tell someone who has messed up their package selections "install ubuntu-base and ubuntu-desktop" and have that make things OK
[05:57] <Kamion> the question is deciding what "messed up" means
[05:57] <mdz> yes
[05:58] <mdz> my general feeling is that it should bring them back to what we chose for them
[05:58] <Kamion> given that part of the idea of the MDA-only thing was to make it easier for server admins to install postfix without having to figure out how to uncripple it, I feel that that ought to be an exception
[05:58] <mdz> but it's clear that the current approach is less than ideal for many users
[06:00] <mdz> we could introduce Recommends
[06:00] <mdz> that seems fairly close to the semantics we want
[06:00] <mdz> "install this per default, but if the user wants to change it, that's OK"
[06:01] <Kamion> Depends: mail-transport-agent; Recommends: mda-only?
[06:01] <Kamion> (or postfix, currently)
[06:02] <mdz> I was thinking Recommends: postfix
[06:03] <mdz> (and no Depends)
[06:19] <mjg59> Argh.
[06:19] <mjg59> Module paramaters are broken in the kernel's ibm-acpi module
[06:20] <Treenaks> WTF? Evo now depends on mozilla-psm which depends on mozilla-browser?
[06:20] <Treenaks> (if you want SSL)
[06:27] <mjg59> Arse. intelfb only works on LCDs if the video mode is set at boot time
[06:58] <mvo> what do I have to kill if my gnome hangs on futex() on login?
[07:01] <sladen> mvo: try  ctrl+alt+backspace
[07:05] <mvo> sladen: that brings me back to gdm and when i try to login in again it hangs
[07:06] <Keybuk> login on console, kill -TERM -1
[07:06] <Keybuk> that usually fixes it
[07:06] <Keybuk> generally a wedges gnome-something-or-other
[07:06] <Keybuk> "iz gtk bug"
[07:09] <seb128> on login ? details ?
[07:09] <seb128> the panel and nautilus ? or on the splash screen ?
[07:10] <Treenaks> seb128: panels + nautilus. still.
[07:11] <Treenaks> seb128: and kill evolution upstream for me, please.
[07:11] <Treenaks> seb128: slowly, and painfully
[07:11] <seb128> the depends have not changed in evo
[07:11] <Treenaks> seb128: then SSL just Broke
[07:11] <seb128> and the freeze question was for mvo who has the problem
[07:12] <mvo> seb128: panel is visible (and some applets) but nothing else and no mouse/keys work
[07:13] <seb128> not a GNOME pb if you don't even get events
[07:13] <seb128> probably xfree or kernel
[07:13] <seb128> you should at least get a pointer and move it
[07:14] <mvo> I have a pointer, sorry for not telling you. and click on the available applets (weather applet) work
[07:15] <mvo> if I strace e.g. nautilus it hangs on "futex()"
[07:15] <seb128> ok
[07:15] <mvo> any idea :) ?
[07:15] <seb128> killall gnome-panel nautilus gnome-vfs-daemon trashapplet
[07:15] <seb128> and drive... (don't remember the exact name) too if you use the drive applet
[07:16] <seb128> that's #4794
[07:16] <seb128> if you can get details ...
[07:16] <mvo> works again, nice :)
[07:16] <seb128> I thought it was due to the hal support, but it's turned off now
[07:16] <mvo> thanks seb128
[07:16] <seb128> np
[07:17] <mdz> mvo: https://bugzilla.ubuntu.com/show_bug.cgi?id=4794 ?
[07:17] <mdz> ah, seb already pointed you to it
[07:18] <mvo> yes, thanks
[07:30] <_rene_> mvo: btw, sorry, no idea wrt that bug. maybe firestarter started doing something stupid with network (loopback etc.)?
[07:30] <_rene_> mvo: (I don't use and maintain it anymore, so I don't really know and care ;) )
[07:36] <mvo> _rene_: thanks anyway :)
[07:54] <abelli> plovs: your needed in ubuntu-doc..
[08:17] <elmo> mjg59: vbetool definitely i386 only?  just looking to P-a-s it
[08:39] <Kamion> note to self: when replacing an initrd in a CD image, try actually changing it
[08:48] <mjg59> elmo: Yup
[08:48] <mjg59> elmo: It uses vm86
[08:58] <calc> anyone know why linux-image-amd64-k8 wasn't updated to depend on 2.6.10 when it was uploaded?
[09:04] <Kamion> calc: because 2.6.10 isn't our default kernel yet, it's experimental
[09:04] <calc> ah ok
[09:04] <calc> that would be a very good reason :)
[09:05] <Kamion> linux-meta will get switched over en masse when 2.6.10 is in better shape
[09:06] <elmo> mjg59: k
[09:51] <Kamion> OK, who can take a language that build-depends on _emacs21_ seriously?! ;)
[09:54] <zul> nothing wrong with that os
[09:54] <zul> er...editor
[09:54] <ogra> Kamion: lisp ?
[09:58] <Josephus> prolog?
[09:59] <Kamion> ogra: python
[09:59] <ogra> ugh 8-O
[10:23] <sivang> zul: well, emacs is a computing paltform by now..:)
[10:25] <lifeless> Kamion: what language build-deps on emacs ?
[10:34] <Kamion> lifeless: python
[10:35] <lifeless> garh
[10:35] <janc> which python do you use ?  :-p
[10:35] <Kamion> the python2.4 source package, in this case
[10:36] <janc> that's something debian-specific or what ?
[10:36] <Kamion> no, grep emacs Doc/Makefile
[10:37] <Kamion> lots of stuff under Doc
[10:37] <janc> ah, the LaTeX-based documentation stuff probably  :-/
[10:38] <Kamion> info files
[10:39] <janc> python documentation source is in a special LaTeX-based format
[10:43] <daniels> mjg59: so, how's videopost coming along? :)
[10:44] <calc> hahaha
[10:44] <calc> so does that make emacs required now? ;)
[10:46] <Kamion> *build*-dep ...
[10:46] <calc> oh i forgot build-dep doesn't have to be inclusive
[10:46] <janc> you only need it to build the documentation...
[10:47] <calc> i guess it typically because things you build-dep on you end up depending on as well, except in doc building case
[10:51] <janc> most programs build-dep on gcc or similar, but they don't need it to run  ;-)
[11:10] <Keybuk> actually, most programs don't build-dep on gcc as it's build-essential </pedant> :p


[00:10] -queuebot:#ubuntu-release- Unapproved: evolution-ews (impish-proposed/universe) [3.40.4-1 => 3.40.4-1ubuntu1] (ubuntu-mate)
[00:25] <Eickmeyer> vorlon: Saw your message in #ubuntu-meeting. I haven't been receiving ISO failure emails. We eliminated a lot of applications a year ago, do we need to stop seeding more?
[00:42] <vorlon> Eickmeyer: the failure notification emails are configured to go to<EMAIL_ADDRESS>are they stuck in moderation perhaps?
[00:42] -queuebot:#ubuntu-release- New sync: libnih (impish-proposed/primary) [1.0.3-12]
[00:43] -queuebot:#ubuntu-release- New: accepted libnih [sync] (impish-proposed) [1.0.3-12]
[00:43] <Eickmeyer> vorlon: Perhaps. I can look into that. That said, what can we do? The only changes we've made since the 26th have been removals (albiet small) anyhow.
[00:45] <vorlon> Eickmeyer: as far as removing packages, I don't know what has changed but 4GiB is the maximum file size on an isofs, so the squashfs must be smaller than this; exactly how you manage the contents of the default install is certainly a flavor team decision
[00:48] -queuebot:#ubuntu-release- New binary: libnih [ppc64el] (impish-proposed/universe) [1.0.3-12] (no packageset)
[00:48] -queuebot:#ubuntu-release- New binary: libnih [s390x] (impish-proposed/universe) [1.0.3-12] (no packageset)
[00:52] <Eickmeyer> vorlon: Is it possible to increase the ISO file size beyond that? I have reason to believe people don't exactly burn directly to DVD anymore but to USB flash drives.
[00:54] <vorlon> Eickmeyer: it's a limit of the iso filesystem standard, not something changeable.  This is not about the size of the ISO but a size limit on individual files within the ISO
[00:54] <Eickmeyer> I see, much like FAT32.
[00:55] -queuebot:#ubuntu-release- New binary: libnih [arm64] (impish-proposed/universe) [1.0.3-12] (no packageset)
[00:55] -queuebot:#ubuntu-release- New binary: libnih [armhf] (impish-proposed/universe) [1.0.3-12] (no packageset)
[00:56] <vorlon> fwiw when I diff the manifests, I see a bunch of new xfce packages being pulled in
[00:57] -queuebot:#ubuntu-release- New: accepted libnih [arm64] (impish-proposed) [1.0.3-12]
[00:57] -queuebot:#ubuntu-release- New: accepted libnih [ppc64el] (impish-proposed) [1.0.3-12]
[00:57] -queuebot:#ubuntu-release- New: accepted libnih [armhf] (impish-proposed) [1.0.3-12]
[00:57] <vorlon> er no I don't, I'm looking at the diff backwards and these are xfce packages that have been dropped
[00:57] -queuebot:#ubuntu-release- New: accepted libnih [s390x] (impish-proposed) [1.0.3-12]
[00:58] <vorlon> so, effectively, this is a question of regular package growth; you've hit an immovable threshold, and there's really no way to build a release image without dropping something from the default install
[01:01] <vorlon> RAOF: so, does this mean lomiri-app-launch is unsupportable in Ubuntu because of new MIR?
[01:02] <RAOF> vorlon: Correct.
[01:03] <RAOF> Well, we could upload a separate mir1.x source package, which would provide the necessary things.
[01:03] <vorlon> RAOF: well, that doesn't seem like something we should volunteer to maintain just to support these Debian packages
[01:04] <RAOF> That was my thinking, yes.
[01:05] <RAOF> Lomiri upstream will eventually migrate to Mir 2.x. It's just the usual resource constraints.
[01:14] -queuebot:#ubuntu-release- New binary: libnih [riscv64] (impish-proposed/universe) [1.0.3-12] (no packageset)
[01:58] -queuebot:#ubuntu-release- Unapproved: ubuntustudio-meta (impish-proposed/universe) [0.248 => 0.249] (ubuntustudio)
[01:58] <Eickmeyer> vorlon: I removed a few things from the seed, hopefully that will work.
[02:15] -queuebot:#ubuntu-release- Unapproved: accepted ubuntustudio-meta [source] (impish-proposed) [0.249]
[02:45] -queuebot:#ubuntu-release- New binary: lomiri-download-manager [armhf] (impish-proposed/universe) [0.1.0-8] (no packageset)
[03:47] -queuebot:#ubuntu-release- Unapproved: accepted dovecot [source] (focal-proposed) [1:<IP_ADDRESS>-1ubuntu3.5]
[04:05] -queuebot:#ubuntu-release- New: accepted libnih [riscv64] (impish-proposed) [1.0.3-12]
[04:05] -queuebot:#ubuntu-release- New: accepted lomiri-download-manager [armhf] (impish-proposed) [0.1.0-8]
[04:09] -queuebot:#ubuntu-release- Unapproved: accepted strongswan [source] (focal-proposed) [5.8.2-1ubuntu3.2]
[04:21] -queuebot:#ubuntu-release- Unapproved: accepted strongswan [source] (hirsute-proposed) [5.9.1-1ubuntu1.1]
[04:53] -queuebot:#ubuntu-release- Unapproved: accepted thermald [source] (hirsute-proposed) [2.4.3-1ubuntu3]
[05:06] -queuebot:#ubuntu-release- Unapproved: accepted mesa [source] (focal-proposed) [21.0.3-0ubuntu0.3~20.04.3]
[06:45] -queuebot:#ubuntu-release- Unapproved: llvm-toolchain-11 (impish-proposed/main) [1:11.0.1-2ubuntu6 => 1:11.1.0-4] (i386-whitelist, ubuntu-server) (sync)
[07:29] -queuebot:#ubuntu-release- Unapproved: gridengine (impish-proposed/universe) [8.1.9+dfsg-9.1ubuntu1 => 8.1.9+dfsg-10] (no packageset) (sync)
[07:29] -queuebot:#ubuntu-release- Unapproved: accepted gridengine [sync] (impish-proposed) [8.1.9+dfsg-10]
[08:09] -queuebot:#ubuntu-release- Unapproved: s390-tools (focal-proposed/main) [2.12.0-0ubuntu3.3 => 2.12.0-0ubuntu3.4] (core)
[08:24] <fheimes> @ubuntu-sru: there are two pairs of s390-tools / s390-tools-signed packages in the hirsute and focal unapproved queue, please could you have a look and ideally approve? thx
[08:44] -queuebot:#ubuntu-release- Unapproved: linux-firmware (impish-proposed/main) [1.200 => 1.201] (core, kernel)
[09:51] -queuebot:#ubuntu-release- Unapproved: grub2 (bionic-proposed/main) [2.02-2ubuntu8.23 => 2.02-2ubuntu8.24~uefi2] (core)
[09:55] <juliank> ^ please reject
[09:55] <juliank> this one was for https://launchpad.net/~ubuntu-uefi-team/+archive/ubuntu/ppa
[10:05]  * didrocks flushes
[10:05] -queuebot:#ubuntu-release- Unapproved: rejected grub2 [source] (bionic-proposed) [2.02-2ubuntu8.24~uefi2]
[10:42] -queuebot:#ubuntu-release- Unapproved: stress-ng (impish-proposed/universe) [0.13.03-1 => 0.13.04-1] (no packageset) (sync)
[10:43] -queuebot:#ubuntu-release- Unapproved: accepted stress-ng [sync] (impish-proposed) [0.13.04-1]
[11:55] <xnox> RAOF:  i guess similar with lorimi upload/download managers depending on libnih for dbus bindings stuff instead of using, anything else.
[12:07] -queuebot:#ubuntu-release- Unapproved: dnsmasq (bionic-proposed/main) [2.79-1ubuntu0.4 => 2.79-1ubuntu0.5] (kubuntu, ubuntu-desktop, ubuntu-server)
[13:08] -queuebot:#ubuntu-release- Unapproved: unity-tweak-tool (impish-proposed/universe) [0.0.7+-0ubuntu6 => 0.0.7+-0ubuntu7] (no packageset)
[13:09] -queuebot:#ubuntu-release- Unapproved: accepted unity-tweak-tool [source] (impish-proposed) [0.0.7+-0ubuntu7]
[13:40] -queuebot:#ubuntu-release- Unapproved: linux-firmware (focal-proposed/main) [1.187.17 => 1.187.18] (core, kernel)
[14:02] -queuebot:#ubuntu-release- Unapproved: libcamera (impish-proposed/universe) [0~git20200629+e7aa92a-8 => 0~git20200629+e7aa92a-9] (no packageset)
[14:03] -queuebot:#ubuntu-release- Unapproved: accepted libcamera [source] (impish-proposed) [0~git20200629+e7aa92a-9]
[14:23] -queuebot:#ubuntu-release- New binary: libcamera [amd64] (impish-proposed/universe) [0~git20200629+e7aa92a-9] (no packageset)
[15:27] -queuebot:#ubuntu-release- Unapproved: apertium (impish-proposed/universe) [3.7.1-1 => 3.7.1-1ubuntu1] (no packageset)
[15:28] -queuebot:#ubuntu-release- Unapproved: accepted apertium [source] (impish-proposed) [3.7.1-1ubuntu1]
[15:43] -queuebot:#ubuntu-release- Unapproved: accepted budgie-desktop-environment [source] (impish-proposed) [0.16.3]
[15:46] -queuebot:#ubuntu-release- Unapproved: accepted evolution-ews [source] (impish-proposed) [3.40.4-1ubuntu1]
[16:02] -queuebot:#ubuntu-release- Unapproved: accepted libdrm [sync] (impish-proposed) [2.4.107-8]
[16:09] -queuebot:#ubuntu-release- Unapproved: accepted mesa [source] (impish-proposed) [21.2.2-1ubuntu1]
[16:27] -queuebot:#ubuntu-release- Unapproved: rejected qemu [source] (bionic-proposed) [1:2.11+dfsg-1ubuntu7.38]
[16:27] <vorlon> Eickmeyer[m]: so this is not a release-blocking issue by any means, but I think it's absurd that the ardour Debian release has added lintian overrides for spelling errors in the source code, in the same upload that it has updated a patch called debian/patches/0200-spelling.patch do address additional spelling errors
[16:27] -queuebot:#ubuntu-release- Unapproved: rejected qemu [source] (focal-proposed) [1:4.2-3ubuntu6.18]
[16:27] -queuebot:#ubuntu-release- Unapproved: rejected qemu [source] (hirsute-proposed) [1:5.2+dfsg-9ubuntu3.2]
[16:29] -queuebot:#ubuntu-release- Unapproved: accepted ardour [sync] (impish-proposed) [1:6.9.0+ds0-1]
[16:33] <falcojr> rbasak: cloud-init has an SRU for B, F and H per https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1940871 and https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1939603. If there is time today to review that SRU, testing is complete
[16:33] <falcojr> not sure if the "7 days" requirement is for calendar date or the full amount of time that happened, but the last two 2 commits were uploaded 7 days ago about 3 hours from now :)
[16:34] <falcojr> but the rest of the SRU has been in proposed longer
[16:35] <bdmurray> tjaalton: What's the reasoning behind the linux-firmware update for Impish given that bug 1945227 says it'll be skipped for impish?
[16:36] <rbasak> falcojr: sorry, I won't get to it today. In between qemu and ua-tools I'm out of time.
[16:36] <falcojr> no problem, thanks!
[16:36] <bdmurray> falcojr: I'll add it to my list for the day
[16:37] <falcojr> thanks!
[16:50] <LocutusOfBorg> please accept llvm-toolchain-11, fixes a mesa regression
[16:50] <LocutusOfBorg> debian bug: 989545
[16:52] -queuebot:#ubuntu-release- Unapproved: accepted gst-plugins-ugly1.0 [sync] (impish-proposed) [1.18.5-1]
[16:52] <bdmurray> LocutusOfBorg: which one 0-4 or 0-2?
[17:22] <tjaalton> bdmurray: just that it's available at least on the devel series. looks like I didn't know the fw was upstream when filing the bug :)
[17:25] <LocutusOfBorg> 0-4 bdmurray has also gcc- build failure and autopkgtest fixes
[17:25] <LocutusOfBorg> latter is better :D
[17:25] <tjaalton> and since this hw will release before 22.04, 21.10 will likely be used by enthusiasts with a mainline kernel or such
[17:26] <tjaalton> (dropped impish from the description)
[17:38] -queuebot:#ubuntu-release- Unapproved: accepted linux-firmware [source] (impish-proposed) [1.201]
[17:39] -queuebot:#ubuntu-release- Unapproved: xrdp (impish-proposed/universe) [0.9.15-1 => 0.9.15-1ubuntu1] (no packageset)
[17:40] -queuebot:#ubuntu-release- Unapproved: accepted xrdp [source] (impish-proposed) [0.9.15-1ubuntu1]
[17:44] -queuebot:#ubuntu-release- Unapproved: rejected llvm-toolchain-11 [sync] (impish-proposed) [1:11.1.0-2]
[17:56] <sergiodj> ubuntu-archive: hi there.  I'd like to get https://code.launchpad.net/~sergiodj/britney/+git/hints-ubuntu/+merge/408965 while we don't have a final fix for https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1944004, so that docker.io/containerd can finally migrate
[17:56] <sergiodj> thanks
[17:57] <bdmurray> sergiodj: that's actually something for ubuntu-release
[17:57] <sergiodj> bdmurray: ah, sorry.  I thought "ubuntu-release" in my head, but pinged ubuntu-archive
[17:58] <sergiodj> thanks
[18:05] <bdmurray> sergiodj: That snapd task is fixed does it still need hinting?
[18:06] <sergiodj> bdmurray: there's another ongoing issue with snapd being handled by the CPC team
[18:06] <bdmurray> ah right that sounds familiar
[18:07] <sergiodj> bdmurray: in theory we can wait until everything is solved, but docker.io has been blocked in -proposed for a long time now and I'd like to get it in release "before it's too late" (TM)
[18:28] -queuebot:#ubuntu-release- Unapproved: livecd-rootfs (impish-proposed/main) [2.740 => 2.741] (desktop-core, i386-whitelist)
[19:43] -queuebot:#ubuntu-release- Unapproved: tzdata (impish-proposed/main) [2021a-1ubuntu1 => 2021a-2ubuntu1] (core)
[19:44] <bdmurray> vorlon: do you want to have a look at tzdata?
[19:45] <vorlon> ok
[19:45] -queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (impish-proposed) [2.741]
[19:48] <vorlon> bdmurray: why are there so many changes to the icu data?
[19:49] <vorlon> bdmurray: I guess this is the "update them to 2021a1" referred to; does this mean in 2021a-1ubuntu1 they had not been updated?
[19:51] <vorlon> schopin: LP: #1940077> a bug is filed in Ubuntu referencing the Debian bug asking not to use a uml backend in Ubuntu since it doesn't work; however, the backend options are auto, kvm, and uml, and kvm doesn't work reliably on the autopkgtest runners because the runners are themselves VMs and nested KVM isn't supported.  What do you think we should do to get this package unstuck from -proposed?
[19:56] <bdmurray> vorlon: no, they had been updated to 2021a - I pulled in this update https://github.com/unicode-org/icu-data/commit/b5e34a13cd05e56fea406f597e8f257860f0dad2
[19:56] <vorlon> ok
[19:57] -queuebot:#ubuntu-release- Unapproved: accepted tzdata [source] (impish-proposed) [2021a-2ubuntu1]
[20:53] <Eickmeyer> vorlon: I'm inclined to agree. Would you like me to pass that along to the debian-multimedia team?
[20:54] <vorlon> Eickmeyer: please :)
[21:01] <Eickmeyer> vorlon: Done.
[21:01] <Eickmeyer> As in, email sent.
[21:38] -queuebot:#ubuntu-release- Unapproved: tzdata (hirsute-proposed/main) [2021a-1ubuntu1 => 2021a-2ubuntu0.21.04] (core)
[21:56] -queuebot:#ubuntu-release- Unapproved: indicator-sound (impish-proposed/universe) [12.10.2+18.10.20180612-0ubuntu3 => 12.10.2+18.10.20180612-0ubuntu4] (ubuntu-desktop)
[21:56] -queuebot:#ubuntu-release- Unapproved: tzdata (focal-proposed/main) [2021a-0ubuntu0.20.04 => 2021a-2ubuntu0.20.04] (core)
[22:01] -queuebot:#ubuntu-release- Unapproved: appstream (impish-proposed/main) [0.14.4-1 => 0.14.5-1] (core) (sync)
[22:01] -queuebot:#ubuntu-release- Unapproved: appstream-generator (impish-proposed/universe) [0.8.4-1 => 0.8.5-1] (no packageset) (sync)
[22:02] -queuebot:#ubuntu-release- Unapproved: accepted appstream-generator [sync] (impish-proposed) [0.8.5-1]
[22:02] <vorlon> bdmurray: ^^ the above are a fix for an appstream-generator ftbfs in -proposed that's been stuck there for 153 days; the newer versions in unstable that fix this problem seem like reasonable minor release updates to me, but it's worth having a second opinion from the release team so I haven't self-accepted appstream
[22:19] -queuebot:#ubuntu-release- Unapproved: accepted appstream [sync] (impish-proposed) [0.14.5-1]
[22:27] -queuebot:#ubuntu-release- New binary: appstream [s390x] (impish-proposed/main) [0.14.5-1] (core)
[22:27] -queuebot:#ubuntu-release- New binary: appstream [ppc64el] (impish-proposed/main) [0.14.5-1] (core)
[22:29] -queuebot:#ubuntu-release- New binary: appstream [armhf] (impish-proposed/main) [0.14.5-1] (core)
[22:29] -queuebot:#ubuntu-release- New binary: appstream [arm64] (impish-proposed/main) [0.14.5-1] (core)
[22:31] -queuebot:#ubuntu-release- New: accepted appstream [arm64] (impish-proposed) [0.14.5-1]
[22:31] -queuebot:#ubuntu-release- New: accepted appstream [armhf] (impish-proposed) [0.14.5-1]
[22:31] -queuebot:#ubuntu-release- New: accepted appstream [ppc64el] (impish-proposed) [0.14.5-1]
[22:31] -queuebot:#ubuntu-release- New: accepted appstream [s390x] (impish-proposed) [0.14.5-1]
[22:33] -queuebot:#ubuntu-release- Unapproved: tzdata (bionic-proposed/main) [2021a-0ubuntu0.18.04 => 2021a-2ubuntu0.18.04] (core)
[22:34] -queuebot:#ubuntu-release- New binary: appstream [amd64] (impish-proposed/main) [0.14.5-1] (core)
[22:37] -queuebot:#ubuntu-release- New: accepted appstream [amd64] (impish-proposed) [0.14.5-1]
[22:45] -queuebot:#ubuntu-release- Unapproved: tzdata (xenial-proposed/main) [2021a-0ubuntu0.16.04 => 2021a-2ubuntu0.16.04] (core)


[03:26] <mup> PR snapcraft#2057 opened: tests: extract lifecycle suite from general suite <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2057>
[05:18] <mup> PR snapcraft#2057 closed: tests: extract lifecycle suite from general suite <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2057>
[08:01] <mup> PR snapd#5009 opened: overlord: test fix, address corner case <Created by pedronis> <https://github.com/snapcore/snapd/pull/5009>
[10:40] <mup> PR snapd#5009 closed: overlord: test fix, address corner case <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5009>
[10:44] <mup> PR snapd#5010 opened: overlord: test fix, address corner case (2.32) <Created by pedronis> <https://github.com/snapcore/snapd/pull/5010>
[11:02]  * zyga wonders who is responsible for ubuntu-image
[11:03] <zyga> it doesn't work on 18.04 at all, GLIBC_PRIVATE not defined
[11:27] <mup> PR snapd#5010 closed: overlord: test fix, address corner case (2.32) <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5010>
[11:28] <pedronis> zyga: you mean the snap
[11:28] <pedronis> it's a bit unclear to me if the snap is maintained  (is still in only in beta)
[11:28] <pedronis> it would be foundations though
[11:30] <zyga> yeah, the snap
[11:30] <zyga> the deb seems to work but it's not very user friendly
[11:38] <pedronis> probably bootable bases / core18 work will be a good time to revisit/improve some of that
[13:29] <mup> Issue snapcraft#1674 closed: Add pre-prime/prime/post-prime <Created by sergiusens> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/issue/1674>
[13:29] <mup> PR snapcraft#2052 closed: many: add override-prime scriptlet <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2052>
[13:32] <mup> PR snapcraft#2051 closed: elf: use snapped strip <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2051>
[16:04] <mr_lou> Hello
[16:05] <mr_lou> Can one Snap talk with another Snap? I.e. if someone makes a Snap of a Java Runtime - will other Snaps then be able to utilize that JVM, resulting in Snaps that depend on Java to run?
[16:06] <mr_lou> Currently, there's a Snap of VLC 3.0.1. And normally VLC can play Blu-ray's with full Java menus. But the Snap version can't, because it (obviously) needs Java in order to do that.
[16:08] <om26er> mr_lou: that should be possible, I think there are other snaps that do that already
[16:11] <mr_lou> Neat! Then all we need is a Snap of a Java runtime....
[16:12] <om26er> mr_lou: yeah, if we have one, we can try and reduce the size of Android Studio snap as well
[16:13] <mr_lou> Ah
[16:13] <mr_lou> Makes sense.
[16:13] <mr_lou> Although I gotta admit, I kinda like packages where the JVM is embedded.
[16:13] <mr_lou> Especially in the case of VLC.
[16:14] <mr_lou> Well, I only learned about Snap recently. Will take a while for me to figure out how to create a Snap...  Anyone else up for it? :-)
[16:15] <mr_lou> Obviously, the bit version of the JVM will have to match the bit version of VLC.
[18:21] <doko> are snapd's autopkg test a bit flaky on i386? see http://autopkgtest.ubuntu.com/packages/s/snapd/bionic/i386
[18:41] <vidal72[m]> would snapd gracefully handle situation when system shutdown is trigered during snap refresh?
[18:42] <om26er> mr_lou: if you could start a conversation on forum.snapcraft.io then we can figure out if there are "genuine" use cases for it. I'll probably work on that if there is enough interest.
[18:42] <mr_lou> There's a genuine use case. But probably not many genuine use cases.
[18:43] <mr_lou> I still think an embedded JVM would be best, but I can't convince VLC devs of that.
[18:43] <mr_lou> A JVM to run BD-J would be less than 2 mb.
[18:43] <mr_lou> That's virtually nothing in this age.
[18:44] <mr_lou> I did read that you prefer people to use the forum. Sorry, I won't be doing that.  I can tell. Might as well do it now. ;-)
[18:48] <mr_lou> Ohai r04r :-)
[18:48] <mr_lou> r04r, I do believe this is the channel you were looking for. ;-)
[18:48] <r04r> looks like it
[18:48] <r04r> wonder why i didnt find it with alis
[18:48] <r04r> is it not registered with chanserv or something
[18:48] <mr_lou> Good question. I just did a channel search for snap
[18:48] <r04r> oh
[18:48] <r04r> +n
[18:49] <r04r> no derp i mean -s
[18:49] <r04r> which makes it hidden
[18:53] <mr_lou> It's hidden?
[18:53] <mr_lou> x-chat had no problem finding it.
[20:13] <mup> PR snapcraft#2050 closed: storeapi: properly handle lacking permission for channel <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2050>