[00:55] <mwhudson> tsimonq2: congrats
[08:08] <darkxst> bdmurray infinity, re bug 1751546, what generates the tasks in the archive, is it related to the germinate cron job that was disable last year?
[08:14] <infinity> darkxst: See my follow up.
[08:17] <cpaelzer> when I run the same gcc command on Debian and Ubuntu where does the collect2 gets its args from
[08:17] <cpaelzer> They differ in my case between Debian and Ubuntu causing an issue (for Debian) that I want to resolve/understand
[08:18] <cpaelzer> I moved to the gcc-7 in our proposed so both are 7.3.0-11 based
[08:18] <infinity> cpaelzer: From the gcc spec and/or build options.
[08:18] <cpaelzer> I thought I compared the gcc -v and other parts of a verbose build
[08:18] <infinity> cpaelzer: gcc -dumpspecs will give you a (messy) view of that world.
[08:19] <cpaelzer> infinity: can I let gcc list the build in defaults?
[08:19] <cpaelzer> let me check that infinity
[08:19]  * cpaelzer goes messy
[08:19] <infinity> cpaelzer: But it's probably easier to tear open debian/rules* in the source package and see how the build differs between Ubuntu and Debian.
[08:20] <cpaelzer> infinity: I
[08:20] <cpaelzer> I'm already down toa simple commandline gcc call
[08:20] <cpaelzer> behaving differently
[08:20] <cpaelzer> and the dumpspec seems to prove that
[08:20] <cpaelzer> I found what I assume to be the difference
[08:21] <cpaelzer> Ubuntu has in the *link step "... --hash-style=gnu   --as-needed   %{shared:-shared} ..." while debian lacks the --as-needed in the same
[08:21] <infinity> cpaelzer: Oh, yes.  We've been using as-needed for ages.
[08:21] <infinity> cpaelzer: Have you really never tripped on that before today? :)
[08:22] <cpaelzer> I tripped over it about 5 times I think
[08:22] <cpaelzer> but not that Debian started to differ, because it didn't a while ago
[08:22] <infinity> cpaelzer: If that's causing you issues, the answer is almost always not "the compiler is doing something silly" but "the build system is doing something silly".
[08:22] <infinity> cpaelzer: command-line order matters with as-needed because deps are searched left to right.
[08:23] <infinity> cpaelzer: And no, Debian didn't "start to differ" here, we've been diverged on as-needed for half a decade or so.  Since before you joined Canonical.
[08:23] <cpaelzer> interesting
[08:23] <cpaelzer> infinity: I actually fixed it in the build system of the package a year or so ago
[08:23] <cpaelzer> but our dep8 test needs all that fixed up as well now
[08:23] <cpaelzer> infinity: thanks for the right pointers
[08:24]  * cpaelzer need to check old debian test logs ...
[08:24] <cpaelzer> yep, you are right (as always) the difference was there in the past as well
[08:25] <cpaelzer> it just now became an issue due to other changes
[08:25] <cpaelzer> perfect, I think I can work this out now
[08:28] <infinity> cpaelzer: Assuming you didn't fix it in an obscurely hackish way, you should forward those changes upstream.   as-needed fixes are always technically correct, and we're not the only distro that uses it as a default.
[08:29] <infinity> We should probably reopen that discussion with Debian too, so we don't trip on the bugs first. :/
[08:31] <cpaelzer> infinity: as I said upstream is good (in a non hacky fashion), I just want to fix the dep8 tests now so they work on Debian and Ubuntu without tripping over this
[08:31] <cpaelzer> I think I can plug into the upstream build system on the test, which is actually more correct than a direct gcc call for the test anyway
[08:31] <cpaelzer> needs some checks if it works as I plan it atm
[08:32] <mwhudson> wait --as-needed isn't the default always and forever?
[08:32] <infinity> cpaelzer: Well, fixing the gcc call is likely trivial too.
[08:32] <mwhudson> til
[08:33] <infinity> cpaelzer: You're likely doing something like "gcc -o foo.o -lbar -lfoo bar.o baz.o", just moving the libraries to the end will fix it.
[08:34] <infinity> cpaelzer: The linker evaluates from left to right, and when it sees a library, checks if anything already linked references the library.  If not, it discards it.  Putting the libs at the end makes sure the earlier object references are already in play.
[08:34] <darkxst> infinity, I guess vanilla-gnome-desktop was our attempt to keep the predicted 50% of ubuntu-gnome population that still want a un-modified upstream GNOME package
[08:34] <darkxst> keep them happy
[08:35] <infinity> darkxst: I suspect that 50% is rather high.  Most people don't actually care that deeply about such details.
[08:35] <infinity> darkxst: (See the fuss that nerds make about a vanilla AOSP experience, while 99% of Android users really don't care at all and use whatever came on their phone).
[08:36] <cpaelzer> infinity: it essentially is "gcc test.c -o testl.bin `pkg-config ...` and pkg-config brings in the stuff that then gets a bunch of "-l.." in (at the end which is correct per your comment above)
[08:36] <infinity> darkxst: And I'm not saying the metapackage shouldn't exist.  We have metas for upstream KDE and XFCE (and other) experiences too.  But we don't have them in tasksel.
[08:36] <cpaelzer> infinity: it works to build on both, but it increases the things linked and we checked on some of that
[08:37] <cpaelzer> that is why I mean I want to fix mostly the test
[08:38] <darkxst> infinity, its a hard thing to predict though! how many people used ubuntu-gnome just to get gnome-shell and how many still dislike the ubuntu themes!
[08:40] <darkxst> infinity, if its made into just another generic task, how do we avoid it getting lost in the sea of generic tasks?
[08:41] <infinity> darkxst: s/task/package/?
[08:41] <infinity> darkxst: And we don't avoid it getting lost.  I mean, this is a super nitpicky "power user" thing.  We have no official flavour supporting this.
[08:41] <darkxst> also it still has upload rights attached to the packageset, which the DMB are proposing to expand in order to get rid of desktop-extra
[08:42] <infinity> darkxst: From my POV, it's better to have it difficult enough to find that the picky people have to know where to look.
[08:50] <darkxst> infinity, it didnt really make sense to spin ISO's anymore, with Ubuntu moving to gnome-shell, but we fully intended to maintain the vanilla-desktop session
[08:51] <infinity> darkxst: I mean, sure.  Maybe that's true.  But on the flipside, the supported upgrade path for Ubuntu GNOME is to Ubuntu.
[08:51] <infinity> darkxst: ubuntu-gnome-desktop depends on ubuntu-desktop, and the release-upgrader makes that same assumption.
[08:52] <infinity> darkxst: So vanilla-gnome-desktop is very much a "weird power user" thing, just like any other vanilla DE experience.
[08:53] <infinity> darkxst: xubuntu more or less supports the vanilla xfce experience too (since it happens to land in their packageset), but there's no installer support for it, and it's very much a grey area of "supported, but not recommended, and not the product they focus on".
[08:59] <darkxst> infinity, ok I will change tasksel to use package instead
[09:03] <juliank> I don't understnad the vanilla-gnome stuff. It seems to override stuff in gsettings that's handled by per-session defaults, and work just fine by using the gnome session.
[09:12] <darkxst> juliank, there might still be some overrides in there that are now redundant, with Ubuntu switching to gnome-shell
[09:13] <juliank> Did USB audio break recently? I see my DAC just fine in alsa, but PulseAudio does not detect any sink on it...
[09:15] <juliank> external mic is broken too
[09:50] <cpaelzer> is there a best practise what set of ruby triggers to add on autopkgtests that fail due to the ongoing transition?
[09:53]  * cpaelzer goes lazy and tries locally with all proposed
[10:03] <cpaelzer> bdrung: any time to updates on bug 1753938?
[10:03] <cpaelzer> how is upstreaming the changes going atm?
[10:11] <doko> gcc-6 demoted \o/
[10:15] <cpaelzer> gz doko!
[11:21] <tsimonq2> mwhudson: thanks
[12:05] <enyc> Somebody being assigned to  1601997 1365874  for 18.04 ?
[12:08] <rbasak> bug 1601997
[12:10] <enyc> rbasak: thats the killer,  1365874 wrt e2fsprogs freeze-exception for 18.04 worthy too...  tytso himself encourages!
[12:11] <enyc> Secondarially, backporting e2fsprogs and grub2 in 16.04 and 14.04 would be helpful,  but less urgent if 18.04 (sensibly) rolls back the needless extra filesystem-flags.
[12:12] <rbasak> To save others reading the bug, it's that Debian has enabled metadata checksumming by default, so filesystems created by the installer can no longer be fscked (possibly also not be mounted? Unclear from the report) by older LTS releases.
[12:12] <rbasak> cyphermox perhaps? ^
[12:12] <enyc> some verison can't even mount
[12:12] <enyc> in any case its' a very annoying needless compatibility problem
[12:12] <rbasak> But it looks like Debian have no intention of putting that into stable.
[12:12] <rbasak> Seems like a relatively trivial FFe to undo.
[12:13] <rbasak> (some theoretical risk of installer regression but seems unlikely to me)
[12:13] <enyc> rbasak: undo the extra feature?
[12:13] <enyc> [put back mke2fs.conf from older e2fsprogs, specifically]
[12:13] <rbasak> Yep
[12:14] <rbasak> Seems reasonable to me, but someone closer to the installer packages should decide
[12:14] <rbasak> Or the release team.
[12:14] <enyc> however, on the FFE front, tytso also reccomends we strongly consider e2fsprogs upgrade to 1.44  (though this is separate matter)
[12:14] <enyc> would like support for some (non-default, but useful for some) flags  included from the outset in LTS
[12:15] <rbasak> enyc: do you have references for that recommendation specifically please?
[12:15] <enyc> rbasak: "1365874 wrt e2fsprogs freeze-exception for 18.04 worthy too..."
[12:16] <rbasak> Bug 1365874 seems unrelated to bumping to 1.44 to me.
[12:16] <enyc> rbasak: read comemnts, i check
[12:17] <enyc> See comment #17 onwards
[12:17] <enyc> i can see now there maybe should be many different bugs ;p
[12:17] <rbasak> I see thanks.
[12:19] <rbasak> slangasek, gaughen: ^ worth taking a look IMHO (not recommending we do it, just that it's worth considering).
[12:19] <enyc> NB:   In MY view there are 4 actions in decreasing priority :   (1): revert mke2fs.conf in 18.04   (2): Upgrade e2fsprogs to 1.44.0 while keeping change 1   (3): Backport E2fsprogs [1.44.0 to Xenial] [1.43.9 to Trusty]    (4) Backport Grub2 (at least 2.02beta3) to Xenial and Trusty.
[12:20] <enyc> I have not yet found/created a bug about 4
[12:20] <rbasak> slangasek, gaughen: I tagged 1365874 for you. We don't have a bug specifically on syncing 1.44.0-1 right now, but that's mentioned in https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1365874/comments/17
[12:20] <rbasak> enyc: thank you for drawing attention to this.
[12:20] <rbasak> enyc: backporting is much harder process-wise because of the risk of regressing users of stable releases.
[12:21] <rbasak> enyc: but that can be quite separate as it doesn't have a deadline like Bionic does.
[12:21] <enyc> rbasak: its going to cause all sorts of multi-booting and datacentre lvm/ext4 crap and weird things if not attended to.
[12:21] <enyc> (1) is most important, risk-averse, imho =).
[12:22] <rbasak> IMHO it's inconvenient, but acceptable, if an older release can't read a filesystem created by a newer release. That's the only way to move forwards sometimes. But if we can avoid the inconvenience at little cost, then it can be worth doing. It's a judgement call that needs to be made, and it's not my call.
[12:22] <enyc> rbasak: nodsnods
[12:22] <enyc> so far as I can see  its not really losing anything to revert...  we don't need >16TB support on ALL fs, and the extra csum is nonly if you have bad disk already sort of thing...
[12:23] <enyc> thankyou for understanding and being interested to make "informed choices"[!]
[12:29] <jbicha> juliank: I think it would be useful to drop the gsettings overrides from ubuntu-gnome-default-settings (moving some of them to ubuntu-settings)
[12:29] <jbicha> ran out of time this cycle
[12:48] <cyphermox> rbasak: if you're talking about an e2fsprogs FFe, up to you
[12:51] <cyphermox> I'm fine with a backport of e2fsprogs, but this sounds like it has nothing to do with an "installer bug"
[12:51] <enyc> I Guess a Single FFE could be used, import e2fsprogs AND revert (just for 18.04) the 64bit,metadata_csum change.  I note this makes a 'udeb' for the installer TOO, need to check.
[12:51] <cyphermox> no, that's not the point.
[12:52] <cyphermox> there are two options: either add metadata_csum to old releases by backporting, or reverting everywhere
[12:53] <cyphermox> it's orthogonal to having a newer e2fsprogs in 18.04.
[12:53] <enyc> I noted in bug, canonical partners may have views, onther non-ubunut-systems they support/interoperate w too.
[12:53] <enyc> cyphermox: sure inded, but both (1) (2) go in same package/change/FFE
[12:54] <enyc> backports complex SRU process apparently
[12:54] <rbasak> cyphermox: that's not exactly the reason for my ping. I'm more bothered about whether we want metadata_csum on by default in Bionic, leading to installed filesystems that can't be handled by older releases. Is that something we can avoid by turning it off by default?
[12:55] <cyphermox> enyc: my point is, you're mising up different processes
[12:55] <rbasak> cyphermox: and separately, should we sync e2fsprogs to get the newer upstream release (which is a mostly unrelated question)?
[12:55] <cyphermox> rbasak: I value filesystem integrity. My opinion is that we should keep it on if possible, especially looking forward
[12:56] <enyc> tytso had views on both, he's ONLY JUST introduced metadata_csum by default in e2fsprogs,  he only put it on in debian a while ago to get  "testing exposure"  amongst more-technically-able-community
[12:56] <cyphermox> rbasak: re: newer upstream, I'd say it missed the mark?
[12:56] <rbasak> cyphermox: another way would be to wait an LTS cycle so that it can be brought in but while maintaining the ability of the previous LTS being able to handle the following LTS' filesystems.
[12:57] <cyphermox> rbasak: tbh, I'd backport it, if the kernel in xenial-release supports it.
[12:58] <rbasak> Since my ping, it occurred to me that perhaps messing with filesystems across different releases is a more server-y use case.
[12:58] <rbasak> I'll see what my team thinks.
[12:58] <enyc> think about dual-booters users...
[12:58] <enyc> i've had many cases of older relase, wanting to rewrite/upgrade grub
[12:58] <enyc> which then BREAKS the newer release booting
[12:58] <rbasak> cyphermox: I appreciate your comments. I understand it's a trade-off. IMHO, I'd like us to make some decision and document it, eg. by closing the bug and release noting it.
[12:58] <enyc> unless you go out of your way to  dpkg-reconfigure grub2  and tell it NOT to install grub any more
[12:59] <cyphermox> rbasak: sure
[12:59] <cyphermox> enyc: have you filed bugs about it?
[12:59] <enyc> rbasak: I also don't think its an "either-or" case... its difficult either way.  "-backports" are not installed by default, I thought, too...  My "risk-managed" appreach would be to revert (only) for 18.04 and also start arranging backports afterwards.
[13:00] <cyphermox> rbasak: well, this would be a question for not just the server team, perhaps to bring up on ubuntu-devel@
[13:00] <enyc> cyphermox: its all in those 2 bugs above, but its important to see the history.  if a "please backport grub2 as well" is wanted, i can create another bug there too.
[13:00] <cyphermox> rbasak: arguably you're just making sure e2fsprogs supports the feature, it could be "off by default" in the backport.
[13:01] <enyc> cyphermox: YES thats a godo risk-managed approach
[13:01] <rbasak> Agreed (to both)
[13:01] <enyc> not everybody will install/have the backports, etc etc.  theres' little-adavantage to the feature, so.
[13:01] <cyphermox> enyc: if you're written about a grub issue in the e2fsprogs bug, it's been missed
[13:01] <enyc> cyphermox: menitoned in there
[13:01] <rbasak> There's the separate question of whether the older kernel will mount it. Do we know?
[13:02] <enyc> rbasak: from what i can see, trusty requires HWE kernel, xenial doesn't (i.e. 4.4 is ok)
[13:02] <cyphermox> enyc: please file a separate bug about the issue, then we can decide if it warrants a backport or not (I think most likely not, but I can fix the bugs)
[13:02] <enyc> rbasak: but don't forget about other distros people use about,  its not an ubuntu-only world
[13:02] <rbasak> enyc: that doesn't sound too bad. Thanks.
[13:02] <cyphermox> rbasak: not sure
[13:02] <cyphermox> tbh, I wouldn't backport to trusty?
[13:03] <cyphermox> hrm
[13:03] <enyc> cyphermox: ok it may be this evening i do it, but i'll try to grub2 backport separately, link to the other 2 related bugs.
[13:03] <cyphermox> otoh you "could", and depends on the hwe kernel then
[13:03] <enyc> cyphermox: tytso had comments on that to..  I must stress reading ALL commends on both bugs.
[13:03] <enyc> will do
[13:03] <enyc> thankyou for starting to think, i know its complex
[13:03] <cjwatson> If there's a grub change required in older releases, it should be a small cherry-pick, not a full backport
[13:04] <rbasak> Imagine if we had a policy on this (just hypothetical; I'm not suggesting that we should). That policy might say "mounting/fscking a filesystem created by a future release is not supported", or "we maintain backwards compatibility for filesystem fsck and mount but no further than one LTS" or "we maintain compatilbity to all supported releases".
[13:04] <cjwatson> We normally use the term "backport" for backporting full new releases, rather than cherry-picking individual commits
[13:04] <rbasak> If we were to pick the middle option, then not backporting to Trusty would be reasonable.
[13:04] <enyc> cjwatson: nods!  and it would be easier if that wasn't needed (for now) by 18.04 not using the controversial-to-enable extra-feature.
[13:04] <enyc> rbasak: agreed
[13:06] <cyphermox> rbasak: there's prior art saying it's "supported", at least to some degree
[13:06] <rbasak> OK.
[13:06] <cyphermox> that said, now I think we should backport to trusty too if we do it at all
[13:07] <cyphermox> the metadata_csum change looks to have been made in yakkety
[13:07] <enyc> IMHO if my (1) (2) can be done now, (3) (4) applying to trusty can be decided after-18.04-release if that helps.
[13:07] <rbasak> And to clarify, that means I think there a few ways of getting to "supported" - by disabling metadata_csum by default on Bionic, by having the installer override it to not use it by default, or by backporting the necessary support to older releases.
[13:07] <cjwatson> enyc: However, are you actually sure a GRUB cherry-pick is required?  Your comment is very vague.  64-bit support was added to GRUB's ext2 driver before trusty.
[13:08] <rbasak> (my middle option is technically possible but seems too surprising to users to me to want it)
[13:08] <cyphermox> rbasak: scratch the installer out of that, it's not the issue -- it will just use whatever is default
[13:08] <enyc> cjwatson: im not sure, it would best need testing.  it could be the metadata_csum thats confusing it.   There is a lot of confusion about if  its' 64bit or metadata_csum that causes particular issues or not.
[13:08] <rbasak> Yep
[13:08] <enyc> cjwatson: there is some other grub devel messages about realizing they can just ignore metadata_csum entirely, and not sure when that was commited.
[13:09] <cjwatson> enyc: I think you are mistaken.
[13:09] <cjwatson> Or possibly confusing something.
[13:09] <cjwatson> There's the metadata_csum thread which I started; I don't think anything has been committed for that yet
[13:10] <cjwatson> But that's metadata_csum_seed
[13:10] <enyc> cjwatson: thats what im saying ,there is confusion about between the 2 changes (which tended to come in together).  I'm saying, IMPORTANTLY that its ONLY JUST been turned on in  e2fsprogs by default within DAYS,  tytso also turned in on in debian "to get extra testing amongst more technically skilled".
[13:10] <cjwatson> Which I don't think is what you're talking about here.
[13:11] <enyc> cjwatson: indeed not, csum_seed is another matter
[13:11] <cjwatson> There were no other relevant changes since 2.02~beta2.
[13:11] <cjwatson> (regarding either of the features you mention)
[13:12] <enyc> cjwatson: I am 100% aware facts would need to be double-checked over 64bit vs metadata_csum.  defenitely found anecdotes that 64bit compatibility required 2.02~beta3 ... would need test or investigate.
[13:12] <enyc> which is in part why not posted bug baout that (4) aspect yet
[13:12] <cjwatson> Your anecdotes, my checking the git history ... hmm, I wonder which is more accurate :)
[13:12] <enyc> and what change is marked properly in git
[13:13] <enyc> has some other change, fixed a bug that stopped that case working?
[13:13] <enyc> i don't know
[13:13] <cjwatson> The number of changes to the ext2 driver in GRUB is very small
[13:13] <enyc> https://www.linuxquestions.org/questions/slackware-14/install-grub2-on-current-failed-4175580346/
[13:14] <enyc> I'm well aware that area is uncertain and would need cecking/testing for bug to be raised w/ clear facts.
[13:15] <enyc> Given that upstream e2fsprogs has ONLY JUST turned on 64bit,metadata_csum by default i'm not suprised if there are many issues and confusion lurking.
[13:18] <cjwatson> All I'm saying is that it's unlikely that randomly updating the GRUB source will do anything here, because there are no changes that appear relevant.  (There are changes related to the meta_bg and mmp features, and one or two other bug-fixes.)  That linuxquestions thread is really too vague to be meaningful ...
[13:19] <cyphermox> enyc: have you opened that separate bug report for the grub issues you're seeing?
[13:19] <cjwatson> Filesystem drivers in GRUB are quite well-isolated; for this kind of thing it would be unusual for any change to any file other than grub-core/fs/ext2.c to be relevant.
[13:23] <bigon> https://bugs.launchpad.net/ubuntu/+source/libnative-platform-java/+bug/1683761 https://bugs.launchpad.net/ubuntu/+source/libnative-platform-java/+bug/1754896 << Is anything missing for these bugs?
[13:27] <cyphermox> bigon: I don't think so, looks all bugfixy
[13:29] <cyphermox> tdaitx_: opinions? ^
[13:37] <tdaitx_> cyphermox: bigon: seem all clear, maybe we should bump LP: #1754896 from whishlist to high as it would fix LP: #1683761 for bionic
[13:38] <enyc> cyphermox: as above comments, i've said 2 things -- one would need to fact check to put in a decent grub report, two might be able to do that this evening.
[13:39] <cyphermox> enyc: ok
[13:39] <enyc> cjwatson: noted!  your investigations, suspect that grub2 back to xenial (only?)  what about trusty,  ought to be compatible with 64bit,metadata_csum ?
[13:40] <enyc> one big risk is that a dual-boot installer goes ahead, then  older system (when booted-into, and updated) re-installs its own grub and breaks booting new-system.
[13:40] <cyphermox> bigon: tdaitx_: cool. I will sponsor that then
[13:40] <tdaitx_> tks ;-)
[13:45] <cjwatson> enyc: Your guess about my investigations is wrong; I checked back to 2.02~beta2, which is in trusty.
[13:46] <enyc> cjwatson: i asked you "what about" and a (?) in there, i did not 'guess'
[13:46] <enyc> cjwatson: so, your investigahions suspect both should be ok
[13:47] <enyc> acid-test is to bios-mode install a 14.04, and a 18.04-test dual-boot, then update-grub on the 14.04
[13:47] <cjwatson> enyc: "suspect" = "guess" :-)
[13:47] <cjwatson> enyc: I currently see no reason why trusty's GRUB would be incompatible with 64bit,metadata_csum
[13:48] <cjwatson> enyc: You can also just use grub-fstest from 14.04's GRUB packages (would probably even be doable in a chroot)
[13:48] <cjwatson> enyc: Or indeed grub-probe
[13:48] <enyc> cjwatson: right yes sure,  though given upstream have ONLY JUST turend on the flag-by-default (in days!!!) theres every possibility of not-well-tested/bugs in that regard too,  worthy of some test.
[13:48] <cjwatson> enyc: Basically all GRUB's filesystem code can be run from userspace
[13:49] <cjwatson> enyc: Sure, but in that case 16.04 would be incompatible too.
[13:49] <enyc> cjwatson: yes, assuming any other "seemingly unrelated" chainge doesn't affect it.  acid-test should prefer the older-version.
[13:49] <enyc> noted
[13:50] <enyc> cjwatson: thankyou for the pointer abou grub-probe grub-fstest ...
[13:53] <cjwatson> Bet you a tenner such a seemingly unrelated change doesn't exist. :-)
[13:53] <enyc> haha
[13:53] <cjwatson> (I understand the caution in general; my confidence is based on experience with how GRUB's filesystem code is laid out.)
[13:53] <enyc> sure !
[13:54] <cjwatson> I think it's much more likely that confusion is caused by *different ext[234] features*.
[13:54] <enyc> howso? e.g. the _csum or something else?
[13:54] <cjwatson> That linuxquestions thread you posted had a bunch of changes in mke2fs.conf.
[13:54] <enyc> right yes
[13:55] <cjwatson> So I'm suggesting it's more likely that one of those relates to one of the *known* changes since 2.02~beta2.
[13:55] <enyc> useful feedback, still worthy of test hopefguly this evening,  so I can then post grub2 backport bug as relevant
[13:55] <cjwatson> And that this is probably entirely unrelated to proposed changes in Ubuntu 18.04.
[13:55] <cjwatson> Not backport, please.
[13:55] <cjwatson> Cherry-pick, *if anything*.
[13:55] <enyc> right i see
[13:55] <cjwatson> Saying "backport" invokes quite the wrong set of processes.
[13:55] <enyc> yes i mean  "grub2 needs fixing for compatibility, heres why, heres where it goes wrong"
[13:55] <enyc> agreed
[13:56] <enyc> whereas, e2fsprogs-wise,  tytso reccomends backport  interestingly.
[13:58] <cjwatson> Upstreams nearly always do.
[13:58] <cjwatson> We don't always agree :)
[13:58] <enyc> nodsnods
[13:58] <enyc> yes i was wondering something along those lines
[14:01] <enyc> cjwatson: nonetheless... what do you make of this aspect...  tytso has "only just" turned on  64bit,metadata_csum upstream, 'for everyone',  --  he only turned it on in debian  for extra testing,  talks about " the average technical sophistication of a Debian vs. a Ubuntu user, compatibility constraints with Ubuntu LTS, etc."
[14:01] <enyc> we've ended up with 'decision by default' sofar
[14:01] <enyc> i guess he's also being conservative...   i don't know about  generalizitions  about debian-users vs ubuntu-users...
[14:02] <cjwatson> enyc: I make nothing in particular of that.
[14:02] <cjwatson> enyc: I'm not going to be drawn into the discussion in general beyond GRUB.
[14:02] <enyc> ok =)
[14:58] <doko> jbicha: brotli test failures on armhf, probably alignment issues
[14:59] <jbicha> doko: fascinating that it works on Debian https://buildd.debian.org/status/package.php?p=brotli
[15:00] <Laney> we're stricter on alignment
[15:01] <doko> jbicha: they run 32bit kernels, we 64bit ones
[15:01] <jbicha> I'm no good on endian/other arch issues so feel free to help out there
[15:32] <bdmurray> xnox: Is the u-r-u task in bug 1749199 still valid?
[15:44] <enyc> cjwatson: [have saved image files to setup a test/vm later...]
[15:45] <enyc> cjwatson: from what you say,  does update-grub  detecting other distros/multiboot-entries,  work entirely from userspace reading,  no actual "mounting" of other-filesystems to check?
[15:46] <cjwatson> enyc: a lot of that is done by os-prober, which is an external tool
[15:47] <cjwatson> enyc: os-prober tries to use grub-mount where it can, which uses GRUB's filesystem parsing code rather than doing a normal mount, but it does depend a bit on the version of os-prober and on various other details
[16:13] <slangasek> rbasak: when you say you "tagged" 1365874 for us, what do you mean?
[16:16] <rbasak> slangasek: rls-bb-incoming
[16:16] <rbasak> slangasek: sorry, I might have mentioned the wrong one
[16:17] <rbasak> slangasek: it was bug 1601997 I tagged.
[16:17] <rbasak> slangasek: the other is not really in a triaged state.
[16:17] <rbasak> Though there's a separate request that needs a separate bug that nobody's filed asking for a sync for e2fsprogs.
[16:18] <rbasak> slangasek: following the subsequent discussion with cyphermox above, he suggested that an ubuntu-devel@ thread might be appropriate, so I was going to write one up.
[16:19] <rbasak> slangasek: though if you want to drop the default change by adding a delta, then there's no specific question for the list I think. Really it's just that like enyc said if we don't do anything we'd be making an implicit decision to break compatibility, and that's the part I don't like and would prefer such a decision to be explicit on the ML, bug, release note, etc.
[16:24] <xnox> bdmurray, yes! there is merge proposal too.
[16:24] <xnox> unless merged....
[16:25] <xnox> if i find it
[16:26] <xnox> if i committed it
[16:26] <xnox> if i pushed it
[16:27] <slangasek> rbasak: ok; from my POV, I don't see any reason to be concerned about filesystems created with 18.04 being incompatible with e2fsprogs from older releases by default
[16:30] <xnox> bdmurray, https://code.launchpad.net/~xnox/ubuntu-release-upgrader/lp1749199/+merge/341342
[16:31] <bdmurray> xnox: That should probably go in DistUpgrade.cfg.xenial too
[16:34] <xnox> bdmurray, well... test in bionic first?
[16:35] <xnox> bdmurray, i think i traced this to the right option....
[16:41] <bdmurray> xnox: How do you propose testing it? And the upgrade path from A->B carries the same risk X->B.
[16:51] <xnox> bdmurray, publish bionic-proposed, test upgrade from X->bionic-proposed; if good migrate that to bionic-release.
[16:51] <xnox> bdmurray, rince & repeat same for xenial SRU.
[16:52] <xnox> bdmurray, but i'm not sure how much we care about changing this in upgrades to xenial.
[16:52] <bdmurray> xnox: The release upgrader downloads a tarball for the release to which you are upgrading so no SRU is necessary. Additionally, the upgrade from X->B will read the DistUpgrade.cfg.xenial file.
[16:52] <xnox> and if this goes pear-shaped, i only want to revert/fix-up bionic only; rather than both.
[16:53] <xnox> bdmurray, ok, then i missunderstood the code.
[16:53] <xnox> bdmurray, i thought .xenial file is read in upgrades to xenial (e.g. by trusty)
[16:54] <xnox> i am aware that the target tarball is downloaded. so at the moment i want to change the bionic+ tarball / behaviour only.
[16:59] <coreycb> bdmurray: hi, can you reject horizon 1:2014.1.5-0ubuntu2.2 from the trusty unapproved queue and horizon 2:9.1.2-0ubuntu6 from the xenial unapproved queue?
[16:59] <coreycb> bdmurray: sorry, really need to get in the habit of seeing what's already in the queue before uploading
[17:00] <bdmurray> xnox: The extension is the "from_release" see DistUpgradeConfigParser.py
[17:01] <bdmurray> coreycb: so reject the newer one not the older one?
[17:01] <coreycb> bdmurray: just those specific versions
[17:02] <coreycb> bdmurray: well actually you can also reject horizon 2:9.1.2-0ubuntu5 from xenial as i'll combine that with the new one
[17:06] <coreycb> bdmurray: sorry this one too for trusty: 1:2015.1.4-0ubuntu4
[17:19] <enyc> cjwatson: fwiw, is 32-bit vs 64-bit  OSes likely to make any difference at all  to my  14.04/16.04/18.04  Bios-based multi-boot / ext4-compatibility test I'm going to test-out in a VM later  ??.
[17:25] <cjwatson> enyc: I wouldn't expect so
[20:03] <slangasek> infinity, stgraber: TB meeting?
[21:22]  * hallyn tries to recall....  is feature freeze applicable to universe?
[21:28] <enyc> cjwatson: confirmed, Grub2 14.04 16.04  all happy with 18.04,  but e2fsprogs and kernels still give issues [checking issues there].  TJ- on the case r.e. iscsi host and guest OS..  i'll update bugs when I can, but essentially it doesn't require a grub2/os-prober/etc bug, now actually checked/confirmed!
[21:30] <enyc> cjwatson: thankyou for looking-in/feedback earlier
[21:52] <mwhudson> hallyn: yes
[21:53] <hallyn> k
[21:53] <hallyn> thx
[21:53] <hallyn> wouldve been nice to get tpm-tools up to 3.0.x
[22:16] <xnox> hallyn, hm.... where is that coming from?
[22:16] <xnox> i guess you do not mean https://sourceforge.net/projects/trousers/files/tpm-tools/
[22:16] <xnox> ah https://github.com/tpm2-software/tpm2-tools/releases
[22:46] <hallyn> xnox: yeah - i have it built for artful in ppa:serge-hallyn/tpm
[22:46] <hallyn> (trousers doesn't work with tpm 2.0)
[22:55] <mwhudson> hallyn: FFe's do exist though :)
[22:56] <mwhudson> and are pretty easy to get for universe packages a week after feature freeze begins
[23:18] <hallyn> yeah i'd just do it except i would have to find time for a cleaner fix for the .pc file in tpm2-tss :)
[23:18] <hallyn> if i figure that out i'll pursue ffe.
[23:18] <hallyn> thx


 https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4976/+packages
 PPA for Ubuntu with Qt 5.15.8


[06:07] <bzoltan> akiva-thinkpad: just ping me when you need me :)
[06:07] <akiva-thinkpad> bzoltan, heh sure
[06:09] <akiva-thinkpad> bzoltan, balloons tested out the latest branch yesterday. Seems to be doing well. I did a major rewrite making it resemble more of an api than it does a daisy chain of functions.
[06:09] <bzoltan> akiva-thinkpad:  cool, We will check it with zbenjamin too
[06:48] <dholbach> good morning
[06:48] <akiva-thinkpad> dholbach, moring
[06:49] <dholbach> hi akiva-thinkpad
[08:02] <Saviq> popey, hey, are issues with music app on arale known? (play queue advancing is very flaky)
[08:17] <popey> Saviq: not that I'm aware of, can you file a bug if you can reproduce?
[08:17] <Saviq> popey, yeah, will try to gather as much data as possible
[08:17] <popey> thanks!
[09:05] <dholbach> popey, do you want me to schedule the help app blueprint/session?
[09:06] <popey> yes, I wasn't sure when you wanted that
[09:06] <dholbach> ok, no worries
[09:17] <dholbach> popey, I placed it on the schedule and pinged everyone involved - I might still move it around, but I guess that's OK still
[09:55] <Saviq> popey, fyi: bug #1449460
[09:57] <popey> thanks Saviq
[10:51] <akiva-thinkpad> bzoltan, I forget; what are targets again?
[10:52] <akiva-thinkpad> you got build configs, run configs, kits, and targets
[12:12] <dpm> popey, https://developer.ubuntu.com/en/start/platform/guides/lets-talk-about-performance/
[12:13] <popey> DanChapman: ^^ fyi :)
[12:21] <popey> dpm https://plus.google.com/u/0/116231235687734373591/posts/5EnJQjCFn6E
[12:30] <om26er> Elleo, Hi! do you if Arthur will be working today ?
[13:03] <DS-McGuire> popey, Can we discuss the "Ubuntu Help App Planning"? I want to know if you think it's best I sit in the IRC or participate.
[13:05] <akiva-thinkpad> DS-McGuire, o/
[13:05] <DS-McGuire> akiva-thinkpad, o/ Hello! How are things?
[13:05] <akiva-thinkpad> DS-McGuire, you should definitely participate
[13:06] <akiva-thinkpad> its a lot of fun
[13:06] <akiva-thinkpad> DS-McGuire, oh just learned that !myBool() doesn't give false
[13:06] <DS-McGuire> akiva-thinkpad, ahah! Yeah I will, I just don't know if it's best for me to sit in the IRC instead of going on video or whatever. I don't want to get in the way haha!
[13:07] <DanChapman> popey thanks! :-)
[13:07] <akiva-thinkpad> DS-McGuire, the more the merrier, trust me
[13:07] <akiva-thinkpad> if you get a chance to be on with stuart, that guy is hilarious.
[13:07] <DS-McGuire> akiva-thinkpad, Probably haha! I will wait for a response from popey to see what's best
[13:08] <akiva-thinkpad> bah
[13:08] <akiva-thinkpad> I just sent "nick" my password
[13:08] <akiva-thinkpad> bloody nickserv
[13:09] <popey> DS-McGuire: any reason you think we wouldn't want you there?
[13:09] <popey> :)
[13:11] <DS-McGuire> popey, haha, well I will be there, I am just confused about how it works. Is it a G+ hangout with an IRC or is it just IRC?
[13:11] <popey> G+ hangout + irc for those who can't make the hangout
[13:14] <DS-McGuire> popey, Okay so I will join the hangout then I guess. I am going to put together what I need for the html classes so I design can be added so it might be best if I am in that, if that's okay with you.
[13:28] <Elleo> om26er: yep; we're all at the sprint in Austin at the moment, so we're just starting the day, he should be on soon
[13:34] <Saviq> popey, I'm trying with arale r26, and one wrong thing at least is track length (0:00) of the first track I played, was it correct for you?
[13:34] <popey> hm, i didnt notice
 DS-McGuire, oh just learned that !myBool() doesn't give false -- rather it doesn't when I declare it locally and in the header
[13:34] <akiva-thinkpad> doh
[13:35] <DS-McGuire> akiva-thinkpad, Oh dear haha!
[13:35] <ahayzen> Saviq, was the track length 00:00 for the first track before/after you started playing it?
[13:37] <Saviq> ahayzen, where do I look?
[13:37] <Saviq> ahayzen, it started at 0:00 straight awa
[13:37] <Saviq> y
[13:38] <Saviq> nowhere else does it show time I think
[13:38] <ahayzen> What i see is when you start the app, it restores you queue, then if you tap the toolbar it displays 00:00 as the position *and* duration...then when you tap play it then gets the correct duration
[13:38] <Saviq> ahayzen, I launched the app, got to an album and went "play all"
[13:39] <Saviq> seems to reproduce reliably
[13:39] <ahayzen> that seems to work for me on mako
[13:39] <Saviq> but only the first time after launching the app
[13:39] <ahayzen> let me try again ... what exactly happens?
[13:41] <ahayzen> Saviq, seems to be fine for me .. but sounds a bit like bug 1438115 which randomly happens on mh2 i'm hoping mh3 has fixed this
[13:42] <ahayzen> popey, do you see what Saviq is describing on arale?
[13:43] <Saviq> ahayzen, popey, https://owncloud.sawicz.net/index.php/s/0afe9e8a599ef8fef2f2a105e9db357d#
[13:44] <popey> Saviq: what format is that file?
[13:44] <Saviq> popey, whatever Cheese records ;)
[13:44] <ahayzen> Saviq, magic :) that is like bug 1438115 ... but reproducible
[13:44] <popey> no, i mean the music
[13:44] <Saviq> popey, ah, mp3
[13:44] <popey> i never see that. can you send me the mp3 (or full album) ?
[13:45] <popey> or send it to ahayzen :)
[13:45] <ahayzen> yeah that would be useful
[13:46]  * ahayzen wonders if the person who reported that bug would have been on arale as well ...
[13:50] <popey> its possible
[13:59] <Saviq> popey, ahayzen, put it under the same link, you can download the whole dir with a link on the right that shows on hover
[13:59] <ahayzen> thanks :)
[14:02] <ahayzen> seems to work for me on mako, popey can you try on arale ?
[14:02] <popey> ok
[14:03] <Saviq> it's likely a race
[14:03] <Saviq> but 100% reproducible here
[14:03] <Saviq> with different albums, too
[14:03] <ahayzen> weird
[14:03] <ahayzen> oooo
[14:03] <ahayzen> you guys have trunk music...i have a slightly 'newer' one ;)
[14:04] <Saviq> gimme
[14:04] <Saviq> ;)
[14:04] <popey> uh
[14:04] <popey> yeah, same here
[14:05] <mcphail> ahayzen: does the newer music app still hang if you feed it a faulty mp3 file? I was going to investigate further but won't bother if it is fixed already
[14:05] <ahayzen> haha no ;) ... i'm on the /refactor branch with some other prototype code...but i don't think that should affect this looking at the code as we backported fixes to that
[14:05] <popey> ahayzen: http://people.canonical.com/~alan/screenshots/device-2015-04-28-150511.png
[14:05] <ahayzen> popey, :(
[14:05] <ahayzen> mcphail, faulty mp3? it would probably be an issue in media-hub not the music-app .. have you reported this issue?
[14:05] <Saviq> launching a song from scope causes the same
[14:06] <ahayzen> to me sounds like a media-hub issue on arale ... maybe
[14:06] <mcphail> ahayzen: not yet. Was going to investigate/search bugs at the weekend to see if it has been reported already
[14:06] <ahayzen> mcphail, it could be bug 1436110
[14:07] <mcphail> ahayzen: I think the mp3 files are blank alotogether: mtp crashed during transfer. I'm not going to have access to a device to have a proper look until the weekend
[14:07] <ahayzen> mcphail, ah i see
[14:08] <mcphail> ahayzen: for a start, I'm going to have to hunt through a couple of thousand mp3s to find the dodgy ones :)
[14:08] <ahayzen> mcphail, hah ;) you may want to look at the mediascanner2 log and see if that helps
[14:09] <mcphail> ahayzen: good tip. thanks
[14:10] <ahayzen> popey, Saviq, i just tried trunk on mako and it is fine as well... can you try krillin/mako and see if you can get it?
[14:10] <Saviq> ahayzen, yeah, flashing mako now
[14:10] <ahayzen> thanks
[14:10] <popey> ok
[14:11] <popey> ahayzen: Saviq fine on a retail bq phone
[14:11] <popey> http://people.canonical.com/~alan/screenshots/device-2015-04-28-151156.png
[14:12] <Saviq> popey, yeah, likely a race that arale wins (or loses, depends how you define the target here)
[14:13]  * ahayzen wonders if jhodapp has an arale to try/debug on ?
[14:13] <popey> also fine on vivid krillin 198
[14:13] <jhodapp> ahayzen, I do :)
[14:13] <jhodapp> ahayzen, what's up?
[14:13]  * popey updates krillin as it's 3 days out
[14:13] <popey> nice song btw Saviq
[14:13] <ahayzen> jhodapp, basically the first track that is played ends up looking like the screenshot here https://owncloud.sawicz.net/index.php/s/0afe9e8a599ef8fef2f2a105e9db357d#
[14:13] <ahayzen> (no duration)
[14:14] <ahayzen> but is fine on mako/krillin
[14:15] <Saviq> popey, yeah, that album is real cool
[14:15] <jhodapp> ahayzen, local music?
[14:15] <ahayzen> jhodapp, yeah mp3s
[14:15] <Saviq> jhodapp, yeah, you can grab the album from the same link
[14:15] <jhodapp> ahayzen, ok I can take a look
[14:16] <popey> yeah, i can't reproduce on vivid proposed on krillin, only on vivid-proposed on arale
[14:16] <ahayzen> thanks jhodapp
[14:17] <jhodapp> ahayzen, who's arale is that in the video?
[14:17] <ahayzen> jhodapp, Saviq's
[14:17] <jhodapp> cool
[14:36] <jhodapp> Saviq, popey were you using the latest image one Arale, the one from today?
[14:37] <Saviq> jhodapp, #26 yes
[14:37] <jhodapp> Saviq, thanks
[14:38] <popey> yes
[15:05] <mhall119> bzoltan: beuno: is the new APP_ID format developer.project or project.developer?
[15:07] <mhall119> because on a new project, manifest.json uses project.developer, but the Makefile uses developer.project
[15:09] <beuno> mhall119, package.developer
[15:10] <mhall119> then the Makefile from the template is wrong
[15:10] <mhall119> bzoltan: zbenjamin: what's the correct project for filing bugs against hte SDK templates?
[15:18] <zbenjamin> mhall119: qtcreator-plugin-ubuntu
[15:18] <mhall119> thanks zbenjamin
[15:21] <zbenjamin> mhall119: whats the problem?
[15:25] <mhall119> zbenjamin: APP_ID in the Makefile is backwards
[15:25] <zbenjamin> mhall119: what project type?
[15:27] <mhall119> qmlproject
[15:27] <zbenjamin> mhall119: ah in the Makefile, that should be fixed already
[15:27] <mhall119> zbenjamin: https://bugs.launchpad.net/ubuntu/+source/qtcreator-plugin-ubuntu/+bug/1449622
[15:27] <zbenjamin> mhall119: are you sure you have the most recent version
[15:27] <mhall119> no
[15:27] <mhall119> I'm upgrading everything now and will try agian
[15:36] <zyrox> Is a scope similar to a daemon, like running in the background as long as the phone is on?
[15:42] <balloons> morning akiva-thinkpad :-)
[16:00] <akiva-thinkpad> balloons, morning
[16:00] <akiva-thinkpad> I tossed the runconfig in, its sort of working
[16:00] <balloons> it's live q and a time, but then I have an idea to chat about with you
[16:00] <balloons> akiva-thinkpad, ^
[16:00] <akiva-thinkpad> balloons, well do
[17:12] <akiva-thinkpad> balloons, you said you wanted a quick discussion?
[17:13] <balloons> akiva-thinkpad, yea let's/
[17:13] <akiva-thinkpad> i'll create a todo list on the lp page
[17:13] <balloons> so, is it possible to not lock the UI when you spawn a test now? (since you use the sandbox)
[17:13] <akiva-thinkpad> balloons, needs more testing, but it appears that way
[17:14] <balloons> 2) Did you give adt a try?
[17:14] <akiva-thinkpad> was busy
[17:14] <akiva-thinkpad> so no
[17:14] <balloons> 3) Could we have a separate 'testing' tab on the sidebar, like debug and projects?
[17:14] <akiva-thinkpad> A mode... needs discussion with bzoltan and zbenjamin
[17:15] <balloons> inside the page, it would be nice to have a dashboard of what tests passed / failed
[17:15] <akiva-thinkpad> that might be what the Run Configuration should be for
[17:15] <akiva-thinkpad> balloons, yes agreed
[17:15] <balloons> awesome!
[17:15] <akiva-thinkpad> I'll need to impliment memory, which will be complicated.
[17:15] <balloons> that's really everything I could want / ask for
[17:15] <akiva-thinkpad> cool, I was also thinking of your other suggestiong
[17:15] <akiva-thinkpad> -g
[17:16] <akiva-thinkpad> Adding a menu action where you can enter a string such as "test_happy*", and have it run all those tests
[17:21] <balloons> right
[17:28] <imnichol> Is there an official tutorial for creating a static list in an Ubuntu app?
[17:36] <imnichol> Hm, I think I found what I'm looking for here: https://developer.ubuntu.com/api/qml/sdk-14.10/Ubuntu.Components.ListItems.Caption/
[17:42] <mhall119> zbenjamin: updated to the latest SDK and still have the same bug
[17:42] <keshav> hello :)
[17:42] <dpm> akiva-thinkpad, nice work with the QtCreator testing plugin!
[17:44] <keshav> hi everybody , i made a qml music player named kmusicplay , its toally done in qml , i want publish it, anyone know what dependencies i need to add to control file ??? i added qmlscence etc ..
[17:45] <keshav> am also using ubuntu components as qml components in my project
[17:47] <popey> keshav: you want to publish it where?
[17:48] <keshav> popey:  i want distribute it to ubuntu users i want upload it to ubuntu software center too
[17:48] <popey> keshav: so maybe put it in a ppa?
[17:49] <keshav> popey:  am able to upload it to ppa but what about if it will give dependencies error when the required dependencies are not installed in user's system ?
[17:51] <keshav> popey:  how can i know what my app require to able to run ??? like qmlsence it require to interprete the main.qml
[17:51] <keshav> popey:  any idea ??
[17:51] <akiva-thinkpad> dpm thanks
[17:51] <popey> keshav: maybe look at the music app, that's pure qml and builds to deb.. http://launchpad.net/music-app
[17:51] <popey> you could look and learn from the debian/ folder in there :)
[17:52] <keshav> popey: thanks for the suggestions :)
[17:52] <keshav> popey:  checked the link u gave they are using cmake to build app and making binary ....
[17:53] <ahayzen> keshav, http://bazaar.launchpad.net/~music-app-dev/music-app/remix/view/head:/debian/control
[17:53] <keshav> ahayzen:  thanks
[17:54] <keshav> thanks i got it :)
[17:54] <keshav> ahayzen:  thanks for pointing me to the exact file :) :P
[17:55] <ahayzen> no problem :)
[17:55] <keshav> popey:  thanks for help man much appreciated
[17:59] <popey> np
[19:11] <bzoltan> mhall119:  sorry, what bug was it?
[19:17] <mhall119> bzoltan: https://bugs.launchpad.net/ubuntu/+source/qtcreator-plugin-ubuntu/+bug/1449622
[20:35] <akiva-thinkpad> Hummmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm how am I gonna do this...
[23:40] <nik90> ahayzen: hey do you still have the bug where sortfiltermodel doesn't work with u1db models?
[23:41] <ahayzen> nik90, there still is a bug for it...i would need to deep search as i've got a new FF profile lol
[23:41] <nik90> ahayzen: no worries, I am just wanted to know that such a bug exists..because I remember you bringing it up during the malta trip if I remember
[23:41] <nik90> s/am/
[23:42] <ahayzen> nik90, yeah it was for like multiple levels IIRC
[23:42] <ahayzen> nik90, if you only had 1 level i thought it might work? or maybe not
[23:42] <nik90> ahayzen: it didnt work for me some time back..ironic that it works with localstorage models but not our own u1db
[23:43] <ahayzen> nik90, bug 1266529
[23:43] <ahayzen> nik90, i've been wanting to move to u1db for nearly a year lol
[23:44] <nik90> ahayzen: yeah I am slightly regretting not staying with localstorage since afaik there isnt a upgrade db option in u1db which I kinda need for the clock app
[23:45] <ahayzen> uh oh... a manual version field?
[23:46] <nik90> yeah I suppose I could do that and then go through every item and add a column
[23:48] <ahayzen> :'(
[23:48] <ahayzen> nik90, you should see our playlist upgrade code ;)
[23:49] <nik90> ahayzen: I did see your localstorage db upgrade code and tbh that looks cleanly done based on the db version of the user. In fact I used that to help me upgrade the db in podbird
[23:50] <ahayzen> hehe :)
[23:50] <ahayzen> nik90, btw when lifting code for podbird you are lifting from lp:music-app/refactor not remix right?
[23:51] <nik90> ahayzen: well I took it from trunk whichever that is
[23:51] <ahayzen> ah the 'old' code ;)
[23:51] <nik90> woops
[23:51] <ahayzen> no worries the refactor is mainly restructuring at the moment
[23:51] <nik90> ahayzen: so far I took only upgrade db and the card view stuff from music app
[23:52] <ahayzen> nik90, you may notice the folder layout is much nicer ;) http://bazaar.launchpad.net/~music-app-dev/music-app/refactor/files
[23:52] <ahayzen> nik90, ah cool that hasn't changed or stuff has been backported
[23:52] <nik90> ahayzen: oh wow that looks clean!
[23:52] <nik90> ahayzen: btw why do you still have a qmlproject file and a cmakelist file?
[23:52] <nik90> just a cmakelist file should suffice
[23:53] <ahayzen> because reasons
[23:53] <ahayzen> idk actually
[23:53] <ahayzen> maybe victor uses it :) haha
[23:53] <nik90> :)
[23:54] <nik90> but yeah this layout is soooooo much organized and easier to understand
[23:54] <ahayzen> it is and files are slowly being abstracted
[23:55] <ahayzen> so you don't have a few single files that 1000L+ lol
[23:55] <ahayzen> nik90, Victor says "ha, because cmake was a pain in the ass and wasn't very well supported in qtcreator so the qmlproj file never got deleted"
[23:55] <nik90> I wanted to tell you guys about that after looking at the music-app.qml..but glad you got time to get to that by yourself
[23:56] <nik90> oh lol
[23:56] <ahayzen> nik90, yeah we are slowly working to improve things...without breaking things :)