  Hadn't even thought about that.  Much better.
[00:36] <superm1> persia, i sent the collective of our patches to the upstream mailing list. they're pretty slow at responding though, so i wouldnt expect to see them accepted upstream before they're determined at our level
[00:37] <persia> superm1: Thanks!  I'm not worried about when they accept/reject them, but getting them there should make this easier for jaunty.
[00:37] <superm1> persia, ack
[01:39] <Elbrus> I heard people use debdiff to see differences between uploads to mentors...
[01:40] <Elbrus> But if I read the man-page it talks about changed files in the package.. How to see changes in the debian dir with debdiff?
[01:41] <persia> Elbrus: You can use filterdiff to extract only the changes in the debian/ directory.  For packages where patches are applied at build-time, it's a good idea to review changes outside debian/ to make sure there aren't any.  For packages that apply patches at packaging-time, it's important to also inspect the changes outside debian/ to see the effects of these patches.
[01:46] <Elbrus> persia: aren't patches always unapplied (that is reversed) on packaging-time? At least with pdebuild?
[01:46] <persia> Elbrus: Well, sorta, but not necessarily.
[01:47] <persia> Essentially, all the patches live in the diff.gz, so no matter how patches are applied in a package, it is true that patches are applied at build time, just because the package is unpacked.
[01:48] <persia> Some people use something like quilt, or dpatch, or cdbs's simple-patchsys to manage their patches.  In this case, the patches are applied from the diff.gz into debian/patches/* or ./patches/*, and then later applied against the code at build-time.
[01:48] <Elbrus> persia: so I want to see the differences in the diff.gz file, but how to do that in a sensible sense (if it is large)?
[01:49] <persia> Other people use other techniques to manage patches (e.g. layered VCS), and so the patches apply to the sources directly in the diff.gz
[01:49] <superm1> persia, Marcel (whom just commented on that bug) is upstream.  his comment makes this whole problem most curious
[01:49] <Elbrus> persia: the package I am now talking about uses quilt, but I did not come up with it, but I need a bug patched to build my package
[01:50] <persia> Elbrus: lsdiff, debdiff, filterdiff, and similar help, but really it's a matter of either reading all the changes, or determining that you don't have to read some somehow (this is often dangerous)
[01:50] <persia> Elbrus: If it uses quilt, you oughtn't see any changes outside debian/ but also there shouldn't be any changes outside debian/ : if there are, quilt isn't being used in the typical fashion.
[01:51] <Elbrus> persia: I do want to see the difference, to check if I ONLY changed the debian/patches directory
[01:51] <persia> Elbrus: Right.  debdiff foo.dsc bar.dsc | lsdiff will show you the files you changes.
[01:51] <persia> s/s\./d./
[01:52] <persia> superm1: OK.  In that case we simply don't know why it's broken.  Have you heard anything else to indicate any way it could be fixed for 0.28?
[01:53] <superm1> persia, well we've *tried* it with 0.28
[01:53] <superm1> persia, and it didn't work
[01:54] <persia> superm1: Right.  0.28 is broken.  1.5 works.  On the other hand, based on what Marcel says, I'm not sure that we've identified the reason.  It may be possible to write a patch that fixes 0.28.
[01:55] <persia> On the other hand, I think the general state of 1.5 is better than the general state of 0.28 at this point: it's a matter of time to track down the issue (I *much* prefer crashes to this sort of thing: nice map), and fix it vs. the risk of BlueZ 4.x in intrepid.
[01:56] <persia> If you heard something to indicate not only that the problem has nothing to do with btusb, but that the problem is known, or there is a solution, I think 0.28 is the safer choice.  If you've not heard anything, then 1.5 at least has the benefit of working.
[01:56] <superm1> persia, well the question then is what is the risk of bluez 4.x at this point
[01:57] <superm1> that's not elaborated on the bug right now
[01:57] <persia> Well, it's a new version that hasn't gotten much testing, vs a version that has gotten a bunch of testing (and doesn't happen to work).
[01:58] <superm1> persia, well given that i've not seen reports of this failed keyboard pairing - yet we both saw it immediately, i'm not so sure that its gotten a much of testing...
[01:58] <superm1> persia, but "theoretically" has received more testing :)
[01:58] <persia> We don't know what bugs may lurk.  It works better for you and I and crevette and mlind, but that's not exactly widespread testing.
[01:58] <superm1> right
[01:58] <persia> Right :)
[01:59] <persia> Personally, I don't think anyone really tested 3.x in intrepid properly, except for a bunch of us looking at Symbian obex testing back in June.
[01:59]  * Hobbsee waves
[01:59] <superm1> from coming into this late, it looks like the bluetooth stack isn't properly triaged much either
[01:59] <superm1> there's still bugs from feisty marked as "New"
[02:00] <persia> No.  slytherin has been trying to keep track since mid-Hardy, but nobody has really been on top of it.
[02:03] <csilk> superm1, yup, thats a problem with public bug trackers
[02:10] <persia> csilk: No, rather it's an issue when nobody is watching a subsystem.  Having it public doesn't automatically mean people don't track things.
[02:11] <csilk> persia,  having it public means you get alot of reports and there is never enough people to triage effectivelt never mind fix
[02:11] <csilk> *effectively
[02:12] <persia> csilk: I disagree.  Find me open untriaged bugs against wildmidi or freqtweak :)  It's a matter of having someone who cares, not about whether it's public.
[02:19] <csilk> persia, when its public there will always be a report that no one cares about
[02:20] <persia> csilk: I disagree, but it's not worth arguing about.  It's just that some people care for some packages, and when that happens, it works.
[02:21] <csilk> sounds about write, my intention over the next 3 weeks is to get stuck in with some of the less cared about bugs and hack away at some fixes
[02:21] <csilk> university workload is really kicking my arse right now though
[02:21] <csilk> ***right
[02:33] <csilk> persia, quick question, does feature freeze also mean bugfix freeze?
[02:34] <csilk> i'm not talking about system critical bugs here of course, i'm talking about old-ish bugs that havent really been looked at in any detail yet
[02:35] <Hobbsee> csilk: i don't think so?
[02:35] <persia> csilk: Depends on the bugs.  If it's broken, you can fix it.  If it ought to include support for freon collection devices, you'll want to wait for Jaunty.
[02:37] <csilk> ok
[03:18] <Hobbsee> anyone looking for a bug to fix?
[03:48] <superm1> persia, well unfortunately can't test the dist-upgrade still.  update-manager wants to have all it's packages authenticated for some silly reason.  I'll have to poke more in update-manager code to find out how to disable that i think
[04:07] <dholbach> good morning
[04:31] <nhandler> Good morning dholbach
[04:33] <dholbach> hi nhandler
[05:17] <Elbrus> I just filed bug 275688 with patch because it would allow my to build a new package WinFF (bug 172804). Would anybody be interested in syncing with Debian?
[05:19] <Elbrus> WinFF is a graphical user interface for FFmpeg.
[05:36] <nxvl> dholbach: wow, this should be a record, what time is it in berlin? 5 am?
[05:36] <nxvl> dholbach: good morning!
[05:37] <dholbach> nxvl: now it's 6:38
[05:37] <LaserJock> any MOTU Release around?
[05:38] <nxvl> dholbach: but ypu are here since 5
[05:38] <dholbach> nxvl: yeah, didn't sleep so well, so I thought "why not get up early and get some work done?" :)
[05:39] <LaserJock> crazy!
[05:39] <nxvl> heh, i always do the same "why not stay until late and get some work done"
[05:39] <nxvl> but now i use to sleep well
[05:39] <nxvl> :D
[05:40] <nxvl> LaserJock: when you have so much fun at work it starts to be normal
[05:40] <nxvl> :D
[05:41] <LaserJock> does  anybody know what the current FF status is regarding upstream bug fix only releases?
[05:41] <Hobbsee> LaserJock: file a bug and upload it, iirc.
[06:24] <iulian> Good morning.
[06:27] <iulian> james_w: Congratulations!
[07:51] <slytherin> any idea why does an opensuse user reports a problem on launchpad? bug #275699
[07:54] <siretart> james_w: welcome, mate! :)
[08:05] <bobbo> james_w: congratulations!
[08:06] <slytherin> james_w: Congratulations. :-)
[08:21] <RAOF> Hobbsee: I see you've noticed that anjuta needs more than just a rebuild :)
[08:54] <wgrant> RAOF: Are forum people really thick enough to miss three bold requests for their Xorg log, or am I missing something?
[08:54] <Aron_> I wonder who is maintaining the Anjuta IDE package?
[08:55] <wgrant> Nobody in particular, but it is known that it is broken.
[08:55] <RAOF> wgrant: Yes.  Forum people are thick enough to miss three bold requests for their Xorg log.
[08:55] <wgrant> RAOF: Sigh.
[08:56] <wgrant> And then there's that guy complaining that monitors aren't detected properly, and then refusing to report bugs to get quirks added...
[08:56] <wgrant> Lovely, lovely.
[08:56] <RAOF> It seems that many forum denizens are not particularly interested in helping, but much more in bitching.
[08:57] <wgrant> Admittedly it might be a good idea to have an "Add resolution" button in gnome-display-properties, but still...
[08:57] <RAOF> There's perhaps something to those complaints, though; we'll likely never inhabit a world where all monitors report correct DDC values.  Screen Resolution should probably have some sort of 'advanced' tab for adding extra resolutions.
[08:57] <RAOF> Heh.
[08:58] <wgrant> Indeed.
[08:58] <wgrant> xrandr exposes it, so it can't be impossible.
[08:58] <RAOF> It'd actually be pretty easy, I think.
[08:58] <wgrant> As would I.
[08:58] <RAOF> You'd call out to xrd or whatever it is that calculates a modeline, pipe that to xrandr, and hope the monitor doesn't explode.
[08:58] <wgrant> It might also be a good idea to scrape the hwdb data out of LP.
[08:59] <RAOF> Oh, _that's_ where the hardware information database goes?
[08:59] <wgrant> It is.
[08:59] <wgrant> It's also exposed, but the pages aren't linked.
[08:59] <wgrant> http://launchpad.net/~wgrant/+hwdb-submissions
[09:00] <wgrant> I can't work out if there's a full index under /+hwdb, unfortunately...
[09:06] <RAOF> Woah!  Crazy.  There's my laptop.
[09:12] <DKcross> HOla motus!
[09:17] <huats> morning everyone
[09:18] <didrocks> morning huats :)
[09:19] <DKcross> huats,  didrocks  hi !:p
[09:20] <huats> hey DKcross
[09:20] <huats> plop didrocks
[09:20] <huats> :)
[09:20] <DKcross> huats, hey!:p
[09:20] <DKcross> speak spanish ?
[09:21] <huats> just a little
[09:21] <huats> but there are lots of guys here who speak spanish
[09:21] <huats> nxvl, by instance
[09:21] <huats> :)
[09:21] <huats> (and hello by the way nicolas)
[09:32] <DKcross> huats,  sorry
[09:33] <DKcross> i go..:$ my english isnt very well..
[09:33] <DKcross> goodbye man
[09:33] <DKcross> talk soon
[09:33] <huats> james_w: congratulations !!! you really really deserve it :)
[09:34] <james_w> thanks huats
[09:41] <stefanlsd> grats james_w!
[10:01] <Adri2000> bobbo: why did your upload close #273586 ?
[10:05] <james_w> persia: hi, could I be added to u-u-s please?
[10:06] <persia> james_w: Indeed.  Congratulations.
[10:06] <james_w> thank you
[10:28] <directhex> coo, james_w gets to be my personal pet sponsor for universe. neato!
[10:29]  * james_w runs
[10:29] <directhex> if only i worked on packages in universe
[10:29] <RAOF> james_w: Never fear - directhex's main targets are mono, which you can't sponsor.  You're safe!
[10:30] <RAOF> Also, grats.
[10:30] <james_w> thanks
[10:44] <stefanlsd> We can still do FFE's for universe stuff - right?
[10:48] <directhex> aren't we in beta freeze? i forget the timetable
[10:50] <wgrant> Beta freeze doesn't practically affect universe.
[10:58] <RAOF> Except that uploads need a manual shove (which doesn't require any authorisation, just an archive admin to press the button), right?
[11:11] <slytherin> anyone willing to test DVD playing with totem-gstreamer with a fix backported from gstreamer CVS? I don't have access to a DVD drive right now.
[11:11] <slytherin> this is on intrepid
[11:12] <Hobbsee> RAOF: yeah.  damn.
[11:12] <Hobbsee> RAOF: did you want to fix it?  :)
[11:17] <RAOF> Hobbsee: Not particularly; autofoo patching isn't my idea of a good time.
[11:17] <RAOF> :)
[11:17] <RAOF> slytherin: Yeah, I'll bite.
[11:18] <slytherin> RAOF: give me 5 minutes. The build has failed. Trying to debug.
[11:19] <RAOF> slytherin: Cool.  Are you considering updating to the new core & base releases?  Looks like they should be done in a couple of days.
[11:19] <RAOF> slytherin: Or are you just cherrypicking a couple of patches to fix dvd subpicture autoplugging?
[11:20] <slytherin> RAOF: Chery picked a fix so that it will go in beta.
[11:20] <slytherin> RAOF: I am not a core dev. seb128 said he will look into updates after beta
[11:20] <RAOF> Cool.
[11:21] <RAOF> Yeah, seb's likely to be on top of the soon-to-be gstreamer releases, if they're worth breaking freeze for.
[11:23] <slytherin> what is meaning of this - Architecture: @linux@
[11:23] <ScottK> james_w: Congratulations.
[11:23] <james_w> thanks ScottK
[11:23] <RAOF> slytherin: Some context?
[11:23] <RAOF> slytherin: The meaning seems pretty obvious - the architecture is Linux :)
[11:24] <slytherin> RAOF: gst-plugins-base also build alsa plugin. But looks liek @linux@ in control.in file is not getting replaced. And hence build failure.
[11:25] <RAOF> Oh, that's debian/control autogeneration madness?
[11:26] <Hobbsee> huats: but, does it actually work?
[11:26] <slytherin> RAOF: Yes. Any idea how could I fix it?
[11:27] <RAOF> Not really; autogeneration is very much a per-package thing, because it's heavily discouraged in general.
[11:27] <huats> Hobbsee: the fact that the new anjuta does not depend on libgdl-gnome-1-0 is true
[11:27] <Hobbsee> huats: well, even the rebuild did that.  I asked if it ran.
[11:27] <Hobbsee> huats: i added a debian bug to that bug.
[11:28] <huats> Hobbsee: it was working on my computer
[11:28] <Hobbsee> huats: good.
[11:28] <huats> but I still need to work on it
[11:29] <persia> Err..  Beta has affected several parts of universe since hardy.  Please be careful when uploading anything that is a reverse dependency of any of the binary packages of xubuntu-meta, mythbuntu-meta, ubuntustudio-meta, or mobile-meta.
[11:29] <huats> (and I would rather wait on the debian sync, since I have talked with the DM and the next version is about to be available)
[11:30] <Hobbsee> huats: fair enough.  I just saw the grave bug in debian, and didn't know if you'd seen it
[11:30] <huats> :)
[11:30] <huats> no pb :)
[11:32] <huats> right now, the libgdl update had some other side effects... I am trying to work on that and after I ping the DM again...
[11:38] <slytherin> RAOF: it might be the case that debhelper 7.x provides appropriate substitution for @linux@
[11:57] <slytherin> RAOF: ping
[12:18] <sistpoty|work> hi folks
[12:22] <stefanlsd> sistpoty|work: heys!
[12:22] <sistpoty|work> hi stefanlsd
[12:23] <siretart> hey sistpoty|work! how are you?
[12:23] <stefanlsd> sistpoty|work: i wanted to ask, when you have some time to maybe read something I wrote about symbols, and just check i am on the right track...
[12:23] <sistpoty|work> hi siretart.. I'm fine, how about you?
[12:24] <sistpoty|work> stefanlsd: if it's not too long, just show it to me ;)
[12:25] <stefanlsd> sistpoty|work: https://wiki.ubuntu.com/stefanlsd/dpkg-gensymbols
[12:25] <james_w> thanks Laney
[12:25] <Laney> james_w: Hm?
[12:25] <Laney> (and congrats)
[12:26] <siretart> sistpoty|work: I'm doing okay
[12:26] <james_w> Laney: you provided my first upload
[12:26] <Laney> james_w: The Geordi rebuild?
[12:26] <james_w> aye
[12:26] <Laney> \o/
[12:26] <stefanlsd> sistpoty|work: might be a bit long. heh.   seems like the symbol stuff isnt that well known.
[12:26] <james_w> assuming I didn't mess it up :-)
[12:26] <Laney> ;)
[12:27] <Laney> (I don't mind if you accidently stole the credit, apparently that's easy to do if you miss some flag)
[12:28] <james_w> http://paste.ubuntu.com/52058/
[12:28] <stefanlsd> james_w: do you have a work plan for the MOTU school stuff?  Like, how could we get involved etc?
[12:28] <Laney> \o
[12:28]  * Laney high fives james_w
[12:29]  * james_w high fives Laney
[12:29] <james_w> stefanlsd: no, I don't really. You would like to run sessions?
[12:32] <sistpoty|work> stefanlsd: I must admit, that I haven't used dpkg-gensymbols yet myself, but what you've written looks quite good
[12:32] <stefanlsd> james_w: i would like to get involved. just not sure how. i enjoy teaching in general. writing docs about something etc.
[12:33] <sistpoty|work> stefanlsd: however the main use for symbol files afaict is in debian to ease the transition from unstable to testing, so it's not that relevant for ubuntu
[12:34] <persia> sistpoty|work: Don't we gain the same benefit of proper dependency tracking in terms of determining if everything is ready for release?
[12:34] <sistpoty|work> persia: hm?
[12:35] <james_w> stefanlsd: cool, if you have a session you would like to run then we can set it up easily.
[12:35] <persia> sistpoty|work: While we don't have an unstable->testing model, I'd think that the results of the symbol files would still improve the accuracy of our package relationships, so we could presumably better identify packages that needed adjustment prior to release.
[12:36] <geser> Hi
[12:36] <sistpoty|work> hi geser
[12:36] <geser> Hi sistpoty|work
[12:36] <sistpoty|work> persia: well, the only real benefit I can see is that symbol files means that someone touching a library *must* check the abi
[12:37] <sistpoty|work> persia: others than that, I see no real benefit
[12:37] <stefanlsd> sistpoty|work: i guess its also useful to see if the ABI has remove anything, and then upstream can be notified and asked to please not break the ABI
[12:37] <persia> sistpoty|work: Right, which strikes me as a *huge* benefit when it comes to our haphazard manner of syncing some stuff from experimental, some from unstable, some from testing, pulling stuff from upstream, and throwing it all together.
[12:38] <stefanlsd> sistpoty|work: it can also help us determine that we can move the ABI lib forward  (by depends) and we would know that the functionality is actually still there, or why we cant...
[12:39] <stefanlsd> but it seems kinda like the use of symbol files etc is optional, and not many packages do it..
[12:39] <sistpoty|work> stefanlsd: yes, but you should do this when maintaining a library anyway ;)
[12:42] <broonie> stefanlsd: A large part of that is because symbol files are a relatively recent innovation.
[12:43] <stefanlsd> broonie: yeah. do you know if its a debian lib standard now? im not sure.  i think not many people know how to work with them also.  (i didnt at all, and now i know a little).
[12:43] <broonie> It's certainly best practice.
[12:44] <stefanlsd> broonie: ok, cool. so maybe we'll be seeing more of them...
[12:44] <stefanlsd> i guess i'll see if i can link my doc somewhere better so devs / motu's can find it better...
[12:44] <siretart> mr_pouit: you seem to be in charge about ffmpeg in medibuntu. please contact me before you do the next merge.
[12:45] <broonie> sistpoty|work: As well as testing transitions the symbol files are also there to help make upgrades, especially if someone's doing a partial upgrade.
[12:46] <broonie> sistpoty|work: They don't *force* ABI checks, sadly (they only check for changed symbol names, not for anything else).
[12:47] <sistpoty|work> broonie: yeah, that's true, but I must admit that even that alone is s.th. which I've seen a few library maintainers not doing :/
[12:48] <persia> checking for changed symbol names is a big step forward, and may well hit some percentage of ABI changes.  partial upgrades are more of a boon for developers than target users, who are expected to (but may not) upgrade from release to release.
[12:49] <broonie> persia: indeed, but practically speaking the most common partial upgrade case is pulling in some core tools first so that the rest of the upgrade goes more smoothly.
[12:50] <persia> broonie: True.  It's the testing to try to make that never required for Ubuntu Release -> Ubuntu Release that is supposed to obviate that, but there's certainly *lots* of people who track development, or use alphas & betas.
[12:52] <broonie> Plus you have your upgrade manager tool for desktop users which can do things like that with nasty tricks if it has to.
[12:54] <broonie> The other thing symbol files can help spot is unneeded dependencies - if no version is identified then the dep isn't needed.
[12:55] <persia> That's something I'd like to see.  I'm unhappy with the volume of packages some packages pull, and don't need.
[13:44] <RainCT> Hi
[13:44] <RainCT> james_w: congrats!
[13:44] <james_w> thanks RainCT
[13:54] <Laney> RainCT: Do you know of any reason for lines 110-113 in pbuilder-dist.new in u-d-t? They seem to break stuff
[13:57] <RainCT> Laney: that self.base should be a self.proxy o_O
[13:57] <Laney> haha
[13:58] <Laney> RainCT: That doesn't seem to be needed anyway. I'm behind a proxy and with just commenting out those lines it still works fine
[13:59] <RainCT> Laney: I guess pbuilder will already know about your proxy if you created the tgz with the bash pbuilder-dist
[13:59] <Laney> I didn't
[13:59] <Laney> pbuilder seems to detect it fine itself
[14:00] <RainCT> oh, I'll delete it then
[14:00] <RainCT> Laney: is pbuilder-dist.new working fine for you (beside that)?
[14:02] <Laney> RainCT: I nailed another bug (bzr merge lp:~laney/ubuntu-dev-tools/dev)
[14:02] <Laney> With the code in that branch it's running great
[14:04] <Laney> doh, accidently added an unrelated line in my latest commit :(
[14:04] <Laney> (still needed though)
[14:19] <RainCT> Laney: merged, thanks :)
[15:18] <amikrop> Can I tell distutils not to place my data_files in /usr/foo but in /etc/foo?
[15:20] <persia> amikrop: You don't want data_files in /etc.  I forget what things are to be called that go there, but it's a different name.
[15:47] <bobbo> Adri2000: sorry I didnt have time to change the debdiff and it was uploaded earlier. I have re-opened the bug.
[15:47] <bobbo> james_w: thanks for all the sponsoring today :)
[15:47] <james_w> bobbo: no problem, really glad I am able to help :-)
[15:48] <james_w> bobbo: have you had a chance to look at bzr?
[15:49] <bobbo> james_w: not yet, but i'll have a look today or tomorrow. I'll send you an email with a list of things I think look important when I have a look at it
[15:49] <james_w> bobbo: great, thanks
[15:50] <bddebian> james_w: Congrats.  I thought you were MOTU ages ago. :)
[15:50] <james_w> thanks bddebian, I was it's been like 8 hours now, that's ages
[15:54] <fbond> Hi.  Is there any way to install recommends for a package after the package has already been installed (with --no-recommends)?
[15:54] <fbond> Err, --no-install-recommends, rather...
[15:56] <Laney> fbond: sudo apt-get install --fix-policy --install-recommends
[15:56] <Laney> (will get all uninstalled recommends)
[15:56] <fbond> Laney: Hm.  I really only want to install recommends for certain (already installed) packages.
[15:56] <fbond> Maybe if I name those packages for that command?
[15:56] <Laney> possily
[15:56] <Laney> b^
[15:58] <directhex> otherwise known as the "where's my tomboy gone?" fix for lenny
[16:01] <mrooney> hello! is there a guide for making patches in the Ubuntu kosher way? I tried diff -crB but it isn't giving me something comparable to the original patch I was working with
[16:02] <Laney> mrooney: debdiff old.dsc new.dsc
[16:04] <mrooney> Laney: oh my then I am going about it all wrong
[16:04] <mrooney> I was just trying to generate a patch from the source folders
[16:05] <mrooney> that is how the upstream patch was, it seems like I should keep it that way for them to consider it
[16:05] <mrooney> specifically bug 42686
[16:08] <Laney> mrooney: Are you using an SVN copy of rhythmbox?
[16:09] <persia> mrooney: diff -urN is the common way used to generate patches, although the means by which they are applied to packages differs on a per-package basis (but there are only 6 or 7 common ones)
[16:11] <mrooney> Laney: well I am patching based on an apt-get source
[16:11] <mrooney> which I believe is based on an SVN checkout
[16:11] <directhex> mrooney, look in the debian/ folder. if there's a patches folder in there, then that package uses a patch system
[16:11] <directhex> mrooney, svn-maintained packages are VERY unlikely to accept non-patchsys patches
[16:12] <persia> directhex: Note that some packages use ./patches as well.
[16:12] <directhex> persia, really? which patchsys does that?
[16:12] <persia> directhex: dpatch and quilt both support it.  I think it was the recommended default for DBS (but very few people like DBS anymore)
[16:13] <persia> (mind you, "support" in the sense that it works if you fiddle things properly)
[16:14] <directhex> persia, within pkg-mono, *every* package in svn has only a "debian" folder. upstream remains unmolested outside that folder.
[16:14] <persia> directhex: That's a common way to do things in pkg-foo on alioth when using SVN.
[16:15] <directhex> persia, i do pkg-foo on alioth using SVN!
[16:15] <Laney> mrooney: Anyway, if you're wanting to submit a patch to upstream I'd get it applying cleanly and working on a fresh SVN checkout, then use "svn diff [files]" to generate the patch to attach to the bug.
[16:16] <mrooney> well I am trying to do the first part :)
[16:16] <mrooney> I need to generate the patch
[16:16] <persia> directhex: Yep :)
[16:16] <Laney> svn diff will give you the patch
[16:16] <mrooney> ahh ok
[16:17] <mrooney> it seems like, rhythmbox just has rhythmbox_0.11.6svn20080916.orig.tar.gz and rhythmbox_0.11.6svn20080916-0ubuntu1.diff.gz
[16:17] <directhex> persia, apparently my monodoc update is finally uploaded, albeit in UNAPPROVED
[16:17] <mrooney> and then the resulting directory
[16:17] <persia> Excellent.  Now you need approval.
[16:18] <directhex> persia, it's not beta-critical. it's certainly release-embarrassing though should it be missed
[16:18] <persia> directhex: Does it fix a bug?  Is the bug milestoned?
[16:20] <directhex> persia, 256853
[16:21] <persia> directhex: Hmm.  Perhaps I wasn't clear :)  I'm not motu-release or ubuntu-release, so I can't help much.
[16:21] <persia> Essentially, uploads are approved if they fix bugs that in the eyes of the release managers ought to be fixed for beta.
[16:22] <directhex> persia, i'm less stressed about intrepid shipping with an embarrassing mono stack than i was. as long as it's in the release, then i'm not fussy
[16:22] <ScottK> For Universe they are supposed to just shove stuff through.
[16:22] <persia> If your bug is milestoned, this is nearly guaranteed.  If your bug is in universe, this is nearly guaranteed.  If your bug does not match these criteria, it's best to ask.
[16:22] <mrooney> persia: thanks, I think -urN was what I was looking for!
[16:23] <directhex> urNad!
[16:23] <mrooney> I wonder what that means.
[16:24] <directhex>               Output NUM (default 3) lines of unified context.
[16:24] <directhex>               Recursively compare any subdirectories found.
[16:24] <directhex>               Treat absent files as empty.
[16:24] <directhex>               Treat all files as text.
[16:24] <directhex>               Try hard to find a smaller set of changes.
[16:25] <mrooney> thanks :)
[16:25] <mrooney> are you suggesting that is the preferred method?
[16:27] <persia> directhex: That's cleaner, but it's not what debdiff does (last I looked)
[16:28] <directhex> persia, i rarely use debdiff. i contribute upstream to pkg-foo ;)
[16:28] <directhex> infact, dpatch-template is what i use a lot more than anything else ;)
[16:28] <persia> Hrm.  OK.  I use debdiff even when I am committing to pkg-foo on alioth.
[16:28] <persia> Not so much to generate the patches, but to review my work.
[16:44] <Adri2000> bobbo: ok, thanks
[16:52] <persia> superm1|away: That's a pleasing surprise.  I've just gotten a desktop install up for testing, and the updates look great!
[17:08] <superm1> persia, yeah upstream accepted variations of a few of the patches I put together.  they're still on the edge about the hbox patch of yours, but i updated it nonetheless for the new version and more feedback
[17:14] <persia> superm1: Understandably.  Unless you're actually trying to use it at 800x600 on a high-DPI device, it's not clear why being horizontal is better.
[17:14] <superm1> persia, I bounced upstream's latest feedback about the hbox patch to you if you'd like to provide some more input on it
[17:14] <persia> Sure.
[17:14]  * persia first finishes the latest test report.
[17:18] <persia> superm1: Ah.  Looks great for me, but I see the point of the complaint with http://launchpadlibrarian.net/18041980/gnome_bt_too_large.png
[17:19] <superm1> persia, well try with the latest stuff on the PPA though.  upstream took off the labels from those buttons
[17:19] <superm1> did you pair w/ a person not a device btw?
[17:20] <superm1> jdong, ^ robot theories.....
[17:20] <persia> That makes it *much* better for me, but I don't have any currently working low-DPI environments.
[17:20] <brettalton> I'm looking to package two pieces of web software. Kohana, a PHP5 framework and LimeSurvey. I've looked into how to package and have created folders for each module of Kohana (kohanaphp2.2, kohanaphp2.2-modules and kohanaphp2.2-vendor) including the creation of DEBIAN/{control, copyright, postinst, prerm}, but I'm stuck on what to do with postinst and prerm.
[17:20] <brettalton> Can anyone help me?
[17:23] <azeem> what do you mean, what to do?
[17:23] <brettalton> ya, just not sure what to program in there?
[17:23] <azeem> brettalton: also note that DEBIAN/* files usually get autocreated by debhelper scripts
[17:23] <persia> superm1: Which is the communication from upstream?  I still seem not to have it.
[17:23] <brettalton> azeem: oh, then I may be lost in how to actually create .deb files. Can you send me a link to a tutorial by chance?
[17:24] <superm1> persia, I bounced it to your @canonical.com addy from my @dell.com address
[17:24] <superm1> it should have come from Bastien Nocera
[17:24] <persia> Ah.  I'll see if I can find out where it went then.
[17:24] <azeem> brettalton: see https://wiki.ubuntu.com/PackagingGuide/ I guess
[17:25] <geser> !packaging-guide
[17:25] <geser> !packaging guide
[17:25] <superm1> persia, hadess is the suffix to the email
[17:25] <persia> superm1: volume isn't the issue, it's destination.  @ubuntu.com is easy.  Other addresses are harder and less reliable.
[17:26] <superm1> persia, i'll rebounce then to @ubuntu.com
[17:26] <brettalton> ubottu: thank you!
[17:26] <persia> Thanks, as I don't seem to have received it anywhere else.
[17:26] <brettalton> is he a bot?
[17:27] <persia> brettalton: Indeed.
[17:27] <brettalton> hahaha
[17:27] <brettalton> odd. Thank you
[17:27] <brettalton> !backports
[17:27] <persia> It's the u[bot]tu that ought give it away :)
[17:28]  * sistpoty|work heads home... cya
[17:30] <brettalton> persia: that and he didn't pass the Turing test ;)
[17:30] <persia> brettalton: I suspect you'll want to read the turning test.  Assigning gender means that ubottu wins.
[17:31] <persia> s/turning/Turing/
[17:38] <iulian> Hi
[17:42] <geser> Hi iulian
[17:43] <sebner> hi geser :)
[17:44] <geser> Hi sebner
[17:46] <iulian> Hello geser.
[19:44] <mr_pouit> siretart: okay, no pb
[20:04] <Zelut> if I need to find out where a package came from (ie; main, universe, etc) what tool can I use?
[20:05] <superm1> apt-cache policy $PACKAGE
[20:07] <geser> I prefer "apt-cache madison $PKG"
[20:08] <directhex> oh, nice
[20:08] <directhex> didn't know that one
[20:10] <directhex> hm. should i add lpia support to my mono repo, considering the debs are built already?
[20:18] <Zelut> thank you.
[20:27] <directhex> Uploading pool/main/m/mono/mono-runtime_1.9.1+dfsg-3ubuntu2~dhx3_lpia.deb: [....] done.
[20:39] <nxvl> james_w: congratulations!!
[20:41] <directhex> anyone know of a good guide to setting up a buildd?
[21:04] <geser> directhex: IIRC NCommander did setup a buildd, perhaps he knows a good guide for it
[21:05] <directhex> geser, found a slightly old one on debian.org, an associate is hacking on it to make it good for hardy
[21:05] <directhex> geser, stupid xen and lack of powerpc
[21:06] <james_w> thanks nxvl
[21:20] <sebner> james_w: congratulations :D
[21:22] <james_w> thanks sebner
[21:24]  * NCommander wakes up
[21:24] <NCommander> Who has summoned my buildd knowledge
[21:24] <sebner> NCommander: geser ;)
[21:25]  * NCommander pokes geser's beard with the point stick of DOOM
[21:25] <NCommander> hrm
[21:25] <NCommander> my l and y keys are brokend
[21:25] <NCommander> *broken
[21:25] <directhex> well, it was sorta me
[21:26] <NCommander> what do you want to know Mr. Directhex
[21:26] <directhex> well, it was sorta SeveredCross on gimpnet, unless you know a magic way to build ppc packages without a ppc box
[21:26] <NCommander> qemu-builder
[21:29] <directhex> NCommander, apparently not a package in hardy
[21:29] <sebner> directhex: only bleeding edge is TRUE -> intrepid :)
[21:30] <NCommander> directhex, why do you need access to pwoerpc
[21:30] <NCommander> directhex, http://wiki.debian.org/qemubuilder?highlight=(qemu)
[21:31] <directhex> NCommander, someone asked about ppc support for my mono repo. there's about 72 meg of arch-specific packages across the entire repo, per arch
[21:31] <directhex> and most of that is webkit-dbg
[21:31] <NCommander> directhex, I have a PPC box you can use as a porters box
[21:32] <directhex> NCommander, ooh, that could be handy. is it running a buildd?
[21:32] <directhex> or is it manual pbuildering time?
[21:35] <NCommander> it runs hardy
[21:55] <NCommander> hey, its ScottK
[21:56] <ScottK-laptop> Yes, back from vacation off the grid.
[22:03] <NCommander> ScottK, how was vacation?
[22:09] <directhex> cuba, now THAT was an off the grid vacation
[22:09] <directhex> the poshest hotels provide $10-per-30-mins internets at sub-dial-up speeds
[22:10] <highvoltage> g'night motus
[22:10] <slavik> any chance for evolution with openchange in intrepid? gnome roadmap shows gnome 2.26 having openchange
[22:10] <slavik> 2.26 would be in 9.04 though
[22:51] <james_w> anyone familiar with swig?
[22:54]  * directhex swigs some rum
[23:31] <ZehRique> Hello there. Could anyone answer me which package "gtk-engine" I should request for downloading at Rosetta to make the pt_BR upstream?
[23:41] <james_w> gilir: hi, are you around?
[23:41] <james_w> gilir: I just want to check on bug 267479 before uploading
[23:41] <gilir> james_w: yes ?
[23:42] <james_w> please see my comment
[23:47] <kirkland> persia: ping
[23:51] <gilir> james_w: hum yes, just a mistake
[23:51] <james_w> gilir: cool, thanks, I'll fix it
[23:51] <james_w> just testing the packages now


[00:16] <bluesabre> ninetls: it compares the window title and the title defined in the .desktop file
[00:16] <bluesabre> Since it checks when the application first makes a dbus connection, it can usually grab the application title
[00:19] <bluesabre> In any case, it's a last fallback for the silly media players that implement the hard bits of the mpris spec but not the easy one
[00:19] <bluesabre> :D
[12:44] <ochosi> flocculant: yes, trayicon standard doesnt support symbolic icons and no text, so percentage and time and symbolic icon are only in thr pane plugin
[12:45] <ochosi> bluesabre: well, i wouldnt *like* to, but i guess i can take a look
[12:46] <bluesabre> ochosi: you're definiutely more qualified... I tried fixing it, and see how for I made it :D
[12:46] <bluesabre> Typing at an angle guarantees no quality
[12:47] <ochosi> haha
[12:47] <ochosi> neither does typing on a phone ;)
[14:56] <flexiondotorg> bluesabre: All MATE packaging for Ubuntu and conducted in Debian via the pkg-mate team.
[14:57] <flexiondotorg> What changes do you require?


[07:22] <ackk> hi, I'm getting a weird error when testing the maas snap. In logs for various processes I see "mkdir: cannot create directory ‘/var/snap/maas’: Read-only file system"
[07:22] <ackk> I tried both restarting the snap and the whole system
[07:34] <pedronis> mvo: thanks for reviewing again verify-boot, I merged it now
[07:51] <ackk> anyone might have an idea on how to debug this issue?
[07:51] <ackk> I'm using the non-root-user enabled snapd 2.40
[07:57] <mvo> pedronis: cool, thank you!
[08:30] <pedronis> Chipaca: hi
[08:31] <Chipaca> pedronis: hiya
[08:31] <Chipaca> pedronis: not ready for you yet i'm afraid
[08:31] <Chipaca> :-|
[08:32] <pedronis> Chipaca: late today, or are we talking monday?
[08:32] <Chipaca> pedronis: hmm. I might make it for late today, but monday is safer -- what'd you rather?
[08:33] <pedronis> Chipaca: monday is easier
[08:33] <pedronis> Chipaca: can you put an actual meeting in the calendar for monday when it works for you
[08:34] <Chipaca> pedronis: monday it is then
[08:34] <Chipaca> i'll probably sneak in some time on this over the weekend to make up for this week which has been less than productive
[08:34] <Chipaca> hopefully school being out and the boys wanting to spud out for a while will be conducive
[08:36] <Chipaca> pedronis: calendaered
[08:37] <Chipaca> pedronis: you've got Edit, so you can move it if you need/want to
[08:38] <pedronis> Chipaca: you picked the wrong monday I think
[08:38] <pedronis> 29 vs 22
[08:38] <Chipaca> pedronis: augh
[08:38] <Chipaca> moved
[08:38] <Chipaca> oh wait now it conflicts with my 1:1
[08:38] <Chipaca> moving again
[08:39] <Chipaca> done
[08:41] <pedronis> Chipaca: thanks
[08:43] <pedronis> btw my other PRs are ready for reviews,  and 6923 from pawel is unblocked and needs a 2nd review
[09:36] <Chipaca> pedronis: +1 to both of yours, and +1 to pawel's even though I hate «for _, cstrs1 := range cstrs»
[09:36] <Chipaca> casters? coasters? castraters?
[09:38] <Chipaca> and with that, i'm out for a few hours
[09:39] <Chipaca> should be back in ~4h modulo everything
[09:54] <pedronis> mvo: https://forum.snapcraft.io/t/broken-dependency-of-content-snaps-during-seeding/11566/18 you meant (classic) image builds instead of deb packages ?
[09:57] <mvo> pedronis: eh, yes, let me fix htis
[09:57] <mvo> pedronis: thanks
[09:57] <pedronis> np
[09:57] <ogra> gra@pi4:~$ grep PRETTY /etc/os-release
[09:57] <ogra> PRETTY_NAME="Ubuntu Core 18"
[09:57] <ogra> ogra@pi4:~$ ps ax|grep unattended
[09:57] <ogra>  2209 ?        Ssl    0:00 /usr/bin/python3 /usr/share/unattended-upgrades/unattended-upgrade-shutdown --wait-for-signal
[09:57] <ogra> mvo, ^^^^ ??????
[09:58] <mvo> ogra: check with rbalint
[09:58] <mvo> ogra: but it seems thats the only reliable way these days to hook into the shutdown
[09:58] <ogra> mvo, oh, so the name is misleading ?
[10:00] <mvo> ogra: eh, uh - this is on core18
[10:00] <ogra> yes
[10:00] <mvo> ogra: sorry, missed that - that is - unexpected
[10:00] <mvo> ogra: and unwanted :/
[10:01] <mvo> ogra: I wonder when this sneaked in :(
[10:01] <ogra> right ... that package shoundt be there at all
[10:01] <mvo> (and why)
[10:01] <mvo> ogra: totally
[10:01] <mvo> ogra: there should also be a big dependency issue, like apt is removed during the build
[10:02] <ogra> note that i have a few lxd containers running ... i wonder if that makes it sneak in
[10:03] <mvo> ogra: that could be, let me look at the build logs
[10:03] <ogra> ogra@pi4:~$ lxc stop xenial
[10:03] <ogra> ogra@pi4:~$ ps ax|grep unattended
[10:03] <ogra> 16700 pts/0    S+     0:00 grep --color=auto unattended
[10:03] <ogra> there we go !
[10:03] <mvo> ogra: aha, ok
[10:03] <mvo> ogra: thats fine then
[10:03] <ogra> mvo, sorry, false alarm then
[10:03] <ogra> yeah
[10:05] <zyga> pre-last day of driving home, see you all on Monday
[10:08] <mvo> ogra: no worries
[10:56] <ogra> jdstrand, hmm, i'm trying to snap a script that reads /proc/diskstats and blinks one of the RPi LED's based n changes there but i cant seem to find any interface that allows me to write to /sys/class/leds/led1/trigger and /sys/class/leds/led1/brightness
[10:57] <ogra> (seems only display-control allows access to the kbd LED's)
[10:57] <ogra> ... but nothing for generic system ones
[10:57] <abeato> zyga, hey, do you know which is the current status for snaps in yocto?
[10:58] <ogra> abeato, https://forum.snapcraft.io/t/yocto-rocko-core-snap-panic/3261 perhaps ?
[10:59] <ogra> hmm, there are newer threads too ...
[11:00] <ogra> https://forum.snapcraft.io/t/question-about-meta-snappy-layer-for-yocto/10315
[11:00] <abeato> ogra, thanks, I see there are links to intructions in snapd repo
[11:00] <ogra> apparently you want https://github.com/morphis/meta-snappy
[11:02] <abeato> ha, nice
[11:23] <mup> Bug #1837209 opened: Splash screen fails to display on recent pi core18 images <Snappy:New> <https://launchpad.net/bugs/1837209>
[11:27] <mup> PR snapcraft#2632 closed: pluginhandler, repo: find stage-packages from DT_NEEDED on host <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2632>
[12:00] <jdstrand> ogra: hey, bool-file can do leds. you need a gadget like with gpio
[12:01] <ogra> jdstrand, ah, thanks ! will look into that (we should have something by default in the pi gadget then)
[12:02] <jdstrand> ogra: that said, it is quite old and doesn't operate exactly like gpio. it looks like the slot is expected to do the export/unexport
[12:09] <ogra> /usr/share/subiquity/console-conf-wrapper: line 13: snap: command not found
[12:09] <ogra> Press enter to configure.
[12:09] <ogra> HRM !
[12:13] <diddledan> HRM?
[12:13] <ogra> yeah
[12:13] <diddledan> I know not of this acronym
[12:13] <ogra> no snap command on current core18 pi images ... or my SD is screwed up
[12:14] <diddledan> oh dear :-(
[12:15] <diddledan> is it because snapd was originally in core?
[12:15] <ogra> might be .. let me re-try
[12:15]  * ogra flashes afresh
[12:16] <diddledan> need netboot on these pis
[12:16] <diddledan> I don't suppose uboot can do network booting so you can save the root image on a server someplace and just have uboot on the sdcard?
[12:17] <diddledan> might speed up development if you can do that
[12:21] <ogra> ok ... it was the SD ... (i was debugging boot stuff and had pulled it out in former boots so i guess something got corrupted ... fresh flash works fine)
[12:21] <diddledan> oops :-p
[12:21] <diddledan> the sdcard is the main issue I have with pis
[12:22] <ogra> well ... i run my pi4 off an USB3 SSD ...
[12:22] <ogra> a lot more fun !
[12:22] <diddledan> ooh
[12:22] <diddledan> I got one of those that I pulled from my old mac
[12:22] <ogra> still using the SD for the boot partition indeed
[12:22] <diddledan> it's a USB3-SATA enclosure thingy
[12:22] <ogra> yeah, that should work well
[12:23] <ogra> nopw if u-boot would only allow using the full 4GB
[12:23] <diddledan> is that a hardcoded limit in it's pi support that we can reconfigure?
[12:23] <ogra> thats the only missing bit to have an awesom build machine
[12:23] <diddledan> or is it more systemic?
[12:24] <ogra> its missing code in the u-boot port for pi4
[12:24] <ogra> it isnt fully done yet
[12:24] <ogra> the pi4 port is based on pi3 code so it uses whats currently there to init the RAM
[12:58] <diddledan> ogra: if you're working on u-boot https://github.com/raspberrypi/firmware/issues/1191
[12:59] <mup> PR snapd#7125 opened: snapstate: make progress reporting less granular <Created by mvo5> <https://github.com/snapcore/snapd/pull/7125>
[13:00] <diddledan> that might be the same person as wrote the port you're using, https://github.com/agherzan/u-boot
[13:02] <diddledan> (I don't know whether that's the same port you're working with or not)
[13:27] <mup> PR snapd#7126 opened: tests: part3 making tests work on ubuntu-core-18 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7126>
[13:32] <ogra> diddledan, yes, thats the one
[13:40] <diddledan> ogra: it looks like this is calling into videocore rather than relying on the dtb: https://github.com/agherzan/u-boot/blob/ag/rpi4/board/raspberrypi/rpi/rpi.c#L296
[13:40] <diddledan> prolly needs a separate branch for pi4
[13:41] <diddledan> something #ifdef'd
[13:42] <ogra> diddledan, well, u-boot never actually loads the dtb but reads the dtb values from memor ... the proprietary bootloader needs to load the dtb else the overlays and confi.txt stuff for configuring the HW doesnt work
[13:43] <ogra> diddledan, https://github.com/agherzan/u-boot/blob/ag/rpi4/arch/arm/dts/bcm2838-rpi-4-b.dts#L9 is the issue i think
[13:44] <diddledan> aah good find
[13:50] <diddledan> so that's a devicetree file, right? shouldn't the pi firmware be populating the devicetree memory, not uboot?
[13:50] <ogra> uboot needs a small devicetree to know about the HW
[13:50] <ogra> it gets merged into the binary
[13:50] <diddledan> aah ok
[13:51]  * diddledan learning
[13:51] <ogra> hmm, but blindly patching the dts file doesnt help
[13:52] <ogra> still only 1GB
[13:55] <ogra> well, agherzan seems to work on it already ... we'll just need to wait
[14:05] <mup> PR snapd#7127 opened: tests: removing support for ubuntu cosmic on spread test suite <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7127>
[14:30]  * cachio afk
[14:42] <ackk> jdstrand, hi, around?
[14:47] <ackk> mvo, a while ago you merged this https://github.com/snapcore/snapd/pull/6943 to allow adjtimex, but I still see it failing here with the time-control interface
[14:47] <mup> PR #6943: interfaces: add missing adjtimex to time-control <Simple 😃> <Created by mvo5> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/6943>
[14:48] <ackk> Jul 19 14:46:37 maas audit[13116]: SECCOMP auid=4294967295 uid=0 gid=0 ses=4294967295 pid=13116 comm="chronyd" exe="/snap/maas/x1/usr/sbin/chronyd" sig=0 arch=c000003e syscall=159 compat=0 ip=0x7f4eb1d700c7 code=0x50000 is the error I see
[14:56] <popey_> https://forum.snapcraft.io/t/refresh-failing-after-some-days-of-downtime/12384
[14:56] <popey_> :(
[14:59] <ChipAway> popey_: you have a snap named 's'?
[15:00] <popey_> ChipAway: i can't "snap info s" to confirm or deny that
[15:00] <popey_> but it's possible, yes
[15:00] <Chipaca> popey_: can you 'snap list s'?
[15:00] <popey_> no
[15:01] <popey_> no snap commands work
[15:01] <Chipaca> popey_: Jul 19 15:51:43 KinkPad-K450 systemd[1]: snapd.service: Found left-over process 978 (apparmor_parser) in control group while starting unit. Ignoring.
[15:01] <Chipaca> popey_: looks suspicious to me
[15:01] <popey_> i see apparmor_parser eating cpu repeatedly
[15:01] <Chipaca> popey_: can you systemctl stop snapd.*
[15:02] <popey_> and snapd eating 100%
[15:02] <popey_> done
[15:02] <Chipaca> popey_: and now sudo SNAPD_DEBUG=1 /usr/lib/snapd/snapd
[15:04] <popey_> Chipaca: added to thread on forum
[15:04] <Chipaca> popey_: … and then?
[15:05] <popey_> thats it
[15:05] <Chipaca> D:
[15:05] <pedronis> mvo: I have the fix for the download in remodel OTOH I discover we still send ancient headers with downloads
[15:05] <pedronis> but that's a different issue
[15:05] <pedronis> for another time
[15:05] <pedronis> I put some FIXME in though
[15:05] <popey_> ooh, now it moved
[15:06] <mvo> ackk: oh no - I wonder what is going on. is this happening with the core from edge?
[15:06] <mvo> pedronis: thank you \o/
[15:06] <popey_> it seems to be moving now :(
[15:06] <ackk> mvo, no. but ifit's just snapd, I'm using the 2.40-based build jdstrand gave us for the snap_daemon user
[15:06] <mvo> ackk: let me double check 2.40
[15:07] <Chipaca> popey_: can you paste a bit more of the output?
[15:07] <Chipaca> ah
[15:07]  * Chipaca reads
[15:07] <Chipaca> right
[15:07] <Chipaca> so that's the problem
[15:07] <Chipaca> 2+ minutes between starting and done
[15:08] <Chipaca> meaning, probably, systemd started freaking out
[15:08] <mvo> ackk: it should be in the 2.40 branch, do you know what branch jdstrand build your daemon from? maybe he branched before this got merged (his PR was wip for a while)
[15:08] <Chipaca> we need to do something about that
[15:08] <ackk> mvo, version reports 2.40+git227.g5ce5ff1f0
[15:08] <mvo> ackk: you could workaround by just adding "adjtimex" to the seccomp profile and recompile it but I'm not sure that is what you want
[15:08] <popey_> and now yes, i can tell you i do have a snap called 's' installed
[15:08] <Chipaca> popey_: :)
[15:09] <jdstrand> ackk: time-control is connected?
[15:09] <ackk> jdstrand, yes
[15:09] <jdstrand> ackk: note that you will have to stop/start the process after connected with seccomp
[15:10] <jdstrand> ackk: apparmor can reload the policy for a running process, seccomp cannot
[15:11] <jdstrand> ackk: so, if you verify it is connected (grep adjtimex /var/lib/snapd/seccomp/bpf/snap.maas.yourcommand.src) and then stop chrony, then start it, do you see the denial?
[15:11] <Chipaca> popey_: if you stop snapd and start it again in the terminal does it still wait a long time like that?
[15:12] <popey_> will try when this refresh finishes
[15:13] <Chipaca> thank you
[15:13] <mup> PR snapd#7128 opened: overlord: DeviceCtx must find the remodel context for a remodel change <Created by pedronis> <https://github.com/snapcore/snapd/pull/7128>
[15:14] <Chipaca> pedronis: mvo: I suspect we're doing too much initialisation before starting the watchdog, and it's making systemd kill us
[15:15] <pedronis> Chipaca: I suspect is loading the state
[15:15] <pedronis> anyway we can find out now
[15:15] <Chipaca> pedronis: 2+ minutes of it?
[15:16] <pedronis> snap debug timings --startup=load-state
[15:16] <pedronis> snap debug timings --starup=ifacemgr
[15:16] <pedronis> should give some info about that
[15:16] <mvo> Chipaca: are we maybe re-generating security profiles?
[15:16] <Chipaca> mvo: probably
[15:16] <pedronis> that would go under ifacemgr
[15:16] <Chipaca> popey_: can you do those debug commands? ^^
[15:16] <pedronis> there I think
[15:18] <pedronis> Chipaca: mvo: I proposed 7128 (part of remodeling stuff)
[15:18] <pedronis> it will conflict with the kernel branch (less things to do there though)
[15:21] <popey_> Chipaca: seems a little faster to start this time
[15:22] <Chipaca> popey_: can you stop it, and remove the system key, and start it again?
[15:22] <popey_> the second debug command seems malformed
[15:22] <pedronis> yea, is startup, sorry
[15:22] <popey_> i dont know what system key is
[15:22] <popey_> error: cannot find startup: ifacemgr
[15:22] <Chipaca> popey_: the key for the system, DUH
[15:22] <popey_> no, that didnt work either
[15:22] <Chipaca> :-P
[15:22] <pedronis> Chipaca: you can pass --all
[15:22] <pedronis> to those commands
[15:22] <pedronis> it will find all the timings (still kept) instead of the last one
[15:22] <Chipaca> pedronis: /var/lib/snapd/system-key
[15:23] <pedronis> only
[15:23] <Chipaca> er
[15:23] <Chipaca> popey_: /var/lib/snapd/system-key
[15:23] <pedronis> Chipaca: :)
[15:23] <popey_> sorry, to be clear, snap debug timings --startup=ifacemgr is not valid
[15:24] <pedronis> mmh,
[15:24] <Chipaca> popey_: 'cannot find'?
[15:24] <pedronis> maybe it's only in 2.41
[15:24] <ackk> jdstrand, ok that's weird. I grepp'd, it was there. stopped and started the snap, now it works
[15:24] <Chipaca> popey_: "cannot find" means it doesn't have any
[15:24] <popey_> i am on 2.40
[15:24] <Chipaca> popey_: if it's wrong it says "ALlowed values are: ..."
[15:24] <popey_> your error messages are weird
[15:24] <pedronis> it might be that systemd is killing us too fast
[15:24]  * Chipaca covers his error messages' ears
[15:25] <pedronis> we would need to increase the timeout in the service file
[15:25] <pedronis> and try again
[15:25] <popey_> so am i safe to remove /var/lib/snapd/system-key ?
[15:25] <Chipaca> pedronis: or we can tell systemd what's going on so we're not playing whack-a-mole with it
[15:25] <pedronis> ?
[15:25] <Chipaca> popey_: if you could stop snapd, remove that file, and start it again, that'd be good
[15:25] <pedronis> Chipaca: you mean the real fix?
[15:25] <Chipaca> pedronis: yeah
[15:26] <pedronis> we still don't know where we are spending time
[15:26] <Chipaca> pedronis: i mean there's a protocol to tell systemd to wait a bit more afaik
[15:26] <pedronis> yes
[15:26] <pedronis> there is
[15:26] <pedronis> doesn't make it a fix
[15:26] <pedronis> I mean I suspect this is not trivial to fix
[15:26] <pedronis> without shuffling things around
[15:26] <pedronis> somewhat
[15:27] <popey_> ok
[15:29] <popey_> yes, 2 mins delay
[15:29] <popey_> see forum
[15:30] <Chipaca> popey_: nice
[15:30] <Chipaca> popey_: and now do you have ahnything in the ifacestate timings?
[15:30] <Chipaca> ifacemgr*
[15:30] <ackk> jdstrand, could it be that for some reason that profile didn't get applied right way?
[15:32] <pedronis> Chipaca: anyway I think the issue is that we should reorg things so that we don't do slow things inside a New function, it's a bit misleading
[15:32] <Chipaca> pedronis: mhmm
[15:32] <Chipaca> pedronis: but even if we did it in Init or Start it'd still be before the watchdog started
[15:32] <pedronis> Chipaca: ?
[15:33] <pedronis> we decide when to do what
[15:33] <Chipaca> pedronis: snapd does d := daemon.New(); d.Init(); d.Start(); runWatchdog()
[15:33] <pedronis> anyway my main point is that this is not a 5 line fix
[15:33] <Chipaca> ok
[15:35] <Chipaca> popey_: so you should be ok to let systemd start snapd again, at least until you run some development version again
[15:35] <Chipaca> popey_: as long as it's not re-doing the system key (which happens on upgrade)
[15:35] <jdstrand> ackk: yes, that was what I was trying to say. with a snap declaration, the interface is not auto-connected. therefore on install, chronyd starts with the interface disconnected and has the denial. you connect the interface. it will continue to get a denial until you restart it
[15:35] <Chipaca> popey_: as a workaround until we sort this you can bump the start timeout in a config file snippet
[15:35] <ackk> jdstrand, well chrony is not started on install
[15:36] <ackk> jdstrand, I install the snap, connect  the interfaces, then run maas init which configures stuff and starts everythin
[15:36] <ackk> jdstrand, at least it shuoldn't be, lemme confirm :)
[15:36] <jdstrand> ackk: you could use connection hook to deal with that
[15:37] <jdstrand> ackk: (not your last two comments, the fact that something is starting before a connection)
[15:37] <popey_> Chipaca: added timings to forum
[15:37] <popey_> Chipaca: thanks for the help
[15:37] <ackk> jdstrand, yeah it's a bit tricky at the moment as we only have one service, which is supervisord, which manages everything else
[15:37] <Chipaca> popey_: i'll try to reproduce your issue here so we don't have to guinea pig you
[15:38] <jdstrand> ackk: it can take a little while for snapd to compile the new security policies (work is planned this cycle to make that faster), so it is possible you connected, then ran maas init before it was done connecting
[15:38]  * jdstrand shrugs
[15:38] <ackk> jdstrand, so I guess the reason is that supervisord is started before connections are made, so children inherit the profile without connections?
[15:39] <jdstrand> ackk: I can say that snapd will not restart services when connecting interfaces, but on install won't start services until everything is connected
[15:39] <jdstrand> ackk: yes
[15:39] <ackk> jdstrand, so if the service starts before connecting and spawns other processes, they won't get the connection right?
[15:40] <jdstrand> mvo: fyi ^ tldr; chronyd started before the interface was connected
[15:40] <jdstrand> ackk: that is correct
[15:40] <ackk> jdstrand, would autoconnect fix this?
[15:40] <jdstrand> ackk: yes
[15:40] <jdstrand> ac
[15:40] <jdstrand> ackk: so would be smart wrt a connection hook
[15:40] <jdstrand> being*
[15:42] <jdstrand> supervisord (or something else) could detect that the interface isn't connected. I believe there is a mechanism to restart a service on interface connection
[15:42] <ackk> jdstrand, yeah but if you connect 5/6 interfaces one after another then you get a restart storm
[15:43] <jdstrand> if maas is known to break if all interfaces aren't connected, you probably want some smarts to make sure everything is connected and fail to start if not (with some appropriate log message that tells the user what to do)
[15:43] <ackk> jdstrand, is there a way to get interfaces status in snapctl?
[15:44] <jdstrand> ackk: I thought so, I'm not the best to answer that. perhaps ask in #snapcraft? these are the sorts of things snap publishers deal with all the time...
[15:44] <jdstrand> ackk: they may be able to advise on your storm comment, etc
[15:50] <pedronis> no, it's a request but we haven't worked on it yet
[16:33] <mup> PR core-build#47 opened: initramfs: restore wait-for-root calls <Created by cmatsuoka> <https://github.com/snapcore/core-build/pull/47>
[16:57] <cachio> mvo, any idea about how to create a fat fs on core 18?
[16:57] <cachio> I need it for the assertrions disk
[16:58] <cachio> do you know if that could work using a differet fs?
[16:59] <mvo> cachio: we could create a snap with mtools
[16:59] <cachio> mvo, seems to work using ext3
[17:00] <mvo> cachio: yes it does
[17:00] <cachio> mvo, is any special reason why we use vfat  on the tests?
[17:00] <cachio> mkfs.vfat
[17:04] <mvo> cachio: not really, just to test if it works with that, its the most common format on usb sticks
[17:05] <cachio> mvo, ah ok, I'll leave some tests using vfat and others using ext3
[17:05] <cachio> so we can test also core18
[17:06] <cachio> mvo, should be ok?
[17:06] <mvo> cachio: should be ok, yes
[17:07] <cachio> mvo, tx
[17:10] <mup> PR snapcraft#2635 opened: Legacy errors <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2635>
[17:49]  * mvo declares victory over swtpm
[18:10] <mup> PR snapd#7129 opened: Allow setting default-url-scheme-handler <Created by jwheare> <https://github.com/snapcore/snapd/pull/7129>
[20:04] <mup> PR snapcraft#2633 closed: remote-build: increase number of launchpad start_build request attempts <Created by cjp256> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/2633>